[GE users] Any reason not to have all user's workstations as submit hosts?

fx d.love at liverpool.ac.uk
Fri Apr 16 12:29:14 BST 2010

    [ The following text is in the "utf-8" character set. ]
    [ Your display is set for the "ISO-8859-10" character set.  ]
    [ Some characters may be displayed incorrectly. ]

prentice <prentice at ias.edu> writes:

>> Is there any current work on Kerberos integration which would be
>> preferable for several reasons (see, e.g., Friebel's talk at the 2007
>> workshop)?
> Kerberos is good for many reasons. However, when would the kerberos
> authentication take place? If it takes place only when the job us
> submitted to the queuing system - no problem. However, if the user needs
> to be authenticated when the job actually starts execution on the host
> in addition to submission time, you run the risk of the kerberos tickets
> expiring before the job starts executing.

Indeed.  See Friebel's talk, for instance, and what I said elsewhere in
this thread.  The problems may be mitigated if you have control of all
the relevant security realms, but you typically don't (e.g. AFS or KDCs
operated by other people, often highly qualified MCSEs in the case of
KDCs, unfortunately).  GSSAPI authentication for job submission and
credential management mechanisms would still be useful, and not
necessarily confined to Kerberos if one must use GSI, for instance.

> In a previous life, I set up an SGE 5.x system where SSH authentication
> was handled by GSSAPI (Kerberos) for just this reason. Then I realized
> that if a job is queued longer than the lifetime of a kerberos ticket's
> lifetime, this wouldn't work.

What threat does doing that internally address?  Incidentally, for
anything like this there's a non-trivial issue with distributing keytabs
(or private keys generally, such as CSP ones) securely to nodes during
startup of a stateless system.

> So SGE/SSH/Kerberos wouldn't work. Since now SGE has it's own mechanism
> for launching jobs that doesn't use SSH, it's possible depending on
> when/where the authentication occurs.

What's "it"?  As far as I know, the internal mechanism currently doesn't
do credential forwarding, for instance.

Dave Love
?E-Science?, Computing Services Department, University of Liverpool
AKA fx at gnu.org


To unsubscribe from this discussion, e-mail: [users-unsubscribe at gridengine.sunsource.net].

More information about the gridengine-users mailing list