[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Condor-users] writable access to a shared file system

On Thu, May 04, 2006 at 11:04:47AM -0400, Olga Kornievskaia wrote:
> Thank you for your explanation. I used AFS as an example so I'm not
> disappointed. My actual goal is to have writable access to NFSv4.
> I was wondering if you can point me to more info or elaborate about the 
> "support
> for delegating X509 certificates" in Condor. 

It's not in any released version, so I don't know much about it yet,

> Also, you mention a solution that uses gssklog. How does that work? I 
> must be missing
> something but the way I understand it, in order for this to work, every 
> application has to be
> modified such that it runs gssklog (AFS tokens are process specific). 

No, AFS tokens can be shared by more than one process (they live in a
"Process Authentication Gruop" in the kernel, so the AFS token can
be shared by more than one process) (if all apps had to be modified,
nothing would work in AFS).

gssklog is just like klog, but instead of using your password to get a
kerberos ticket and AFS token, it uses your X509 certificate to get a

> Furthermore, since
> Condor doesn't say where it stores user's credentials, then I don't see 
> how gssklog would
> find user's credentials. Can you point me to some docs? I've read the 
> security parts of the
> condor manuals and haven't encountered an explanation...

Again, I don't know how the new code will work. My guess is Condor
delegates an X509 proxy to the job while it's starting up (ie the execute
machine generates a new keypair, then gets the public key signed by
the submit side's proxy, so the private key never has to travel over
the network). As for finding the proxy, I imagine Condor just sets the
X509_USER_PROXY environment variable before it execs the job.