[GE users] reserved ports in SGE 6.0

Andy Schwierskott andy.schwierskott at sun.com
Tue Nov 23 09:13:34 GMT 2004


if you don't have a secure filesystem (like AFS) of course it means your
certificates needs to be on a local filesystem to have the full security
needs addressed. That not different to a setup where you use ssh/scp without
the needs to provide a password.

As many sites regards that reserved port security of the r* commands as
insecure the same applies to the SGE binaries being using a reserved port.
It's not perfect but it may fullfill certain minimum security requiremements
for some sites.

In 5.3 all communication (including daemons and commd-commd communication)
used the reserved port. Any of the SGE commands which can run in a
multithreaded context could not use this feature in 6.0 - this also may
include qsub (not sure - needs to be confirmed by a devleoper)!


> On Mon, 2004-11-22 at 05:22, Andy Schwierskott wrote:
>> I agree - there an overhead but I think in terms of additional security you
>> can achieve it should be worth the effort for any site which needs to
>> address security related challenges.
>> From what I saw reading through the docs, with CSP each user has to have
> access to their certificates.  Which means that unless you're using a
> filesystem such as NFSv4, all someone has to do after becoming root is
> su to the user and have access as them on the SGE system.  Or with the
> reserve port system, used their hacked binaries.  In this case, CSP
> almost seems simpler to hack.
> Since there is no good NFSv4 client support that I know of right now,
> that means  the only thing CSP seems to be protecting against is if
> someone brought a different machine onto your private LAN (although if
> you're using NFSv3, they could then hijack an IP and still get access to
> the needed files).
> I may be missing something, but right now I'm not seeing CSP as having
> large benefits over reserved ports.
>> On our mid-term (hopefully not long term) roadmap we want to have a better
>> integration with existing security infrastructures (based on LDAP). This
>> will allow a site to reuse the certificates without the need for setting up
>> a "shadow" certificate infrastructure which onyl can be uses by Grid Engine.
> That is interesting.  Although as you do that, I'd ask that you please
> keep in mind that many users don't have "outside" network access for
> their compute nodes.  This already causes a problem because SGE likes to
> email users from compute nodes instead of the head node, and I'd hate to
> see another SGE feature where this setup causes a problem.

To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
For additional commands, e-mail: users-help at gridengine.sunsource.net

More information about the gridengine-users mailing list