[GE users] reserved ports in SGE 6.0
agrajag at dragaera.net
Tue Nov 23 15:09:57 GMT 2004
On Tue, 2004-11-23 at 04:13, Andy Schwierskott wrote:
> 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.
Lets suppose that the cluster has a physically secure LAN (such as I
have). Someone putting a rogue machine on the network becomes less of a
concern (and that's the main disadvantage I see of reserved ports). At
that point the only way for someone to break the security is for them to
gain root privileges on a machine. However, even with AFS, all someone
has to do is become root, wait for you to login, then a few environment
variable changes and they have access to all your files in AFS. As
such, I'm not sure that AFS with CSP is any more secure than reserved
ports, in what I consider to be the common case of having a physically
As a somewhat related question, if users kept their tickets on local
harddrives, what systems would they have to be on? Just the submit and
admin hosts? Or the compute nodes as well?
> 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.
Right, reserved ports aren't prefect, but they are better than nothing.
Especially considering that with the default (non-CSP) install of SGE
6.0u1, its relatively easy for a knowledgeable user to to gain root
access on a compute node. (If you're not sure how they would do this,
email and I will answer privately) As such, I'd like to see reserved
ports as the minimum security for SGE instead of the current minimum of
essentially no security.
> 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)!
I'm not sure about the other systems you support (especially with the
upcoming NT compute node support), however Linux has something called
capabilities that should help with this. They should allow a setuid
program to keep certain bits of root privileges (ie opening a reserved
port), but drop the rest.
I'm a little surprised to heard that qsub is threaded. I can understand
sge_qmaster being threaded, but not sure I see why qsub needs to be.
Along those lines, do you know why sge_qmaster needs to open any
outgoing ports? I thought all the execd's opened ports to sge_qmaster.
So, sge_qmaster should be able to send jobs/etc over those connections.
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