Daniel D. Arrasjid wrote:
> 
> We're interested in how sites are approaching long running/batch jobs.
> In our environment, we allow users to submit long running batch jobs to
> certain machines.   These processes often involve computations over
> large datasets with I/O to data storage.    We need a way to ensure
> that their batch jobs have access to the data storage without the
> credential expiring.
> 
> We think this is a generic batch job problem to k4/k5 and/or AFS/DFS
> services.  What have people been doing in the k4/k5/AFS/DFS space to
> deal with this problem?
> 
> Outside of keytabs.  We're looking at creating a batch job wrapper
> which requires the username/password of the user, obtains the
> credential, and refreshes it for the duration of the process.  Any
> thoughts?
> 

Many of the schemes proposed violate the basic Kerberos principals
of not exposing your password. As reported by Jim Doyle <[EMAIL PROTECTED]>:

> Transarc has a tool that does this... Its called 'dce_refresh'. You can
> feed it a cleartext password, or point it at a keytab. It establishes 
> a new context & PAG, and keeps the password in memory... A thread runs
> in the parent process that refreshes the DCE login context before
> it expires.

How did you give the job your password? Over the net in cleartext? 
In a file? Not a good idea to give away your password. 

-----------------------------------------------------------------------

You should be able to use the K5/DCE renewable ticket options,
which will let you get a ticket for an extreamly long time,
but it has to be renewed every so often. 

For example using the DCE kinit and asking for a 30 day renewable
time, an 8 hour lifetime and forwardable ticket: 

/usr/bin/kinit -r 30d -l 8h -f 

The K5 klist then shows:

Ticket cache: /opt/dcelocal/var/security/creds/dcecred_6534fa08
Default principal: [EMAIL PROTECTED]

Valid starting      Expires             Service principal
22 Apr 98 16:37:59  23 Apr 98 00:37:47  [EMAIL PROTECTED]
        renew until 20 May 98 16:37:59, Flags: FRIA

This can be used to get an AFS token using: 
/krb5/sbin/ak5log 
 
klist then shows:

Ticket cache: /opt/dcelocal/var/security/creds/dcecred_6534fa08
Default principal: [EMAIL PROTECTED]

Valid starting      Expires             Service principal
22 Apr 98 16:37:59  23 Apr 98 00:37:47  [EMAIL PROTECTED]
        renew until 20 May 98 16:37:59, Flags: FRIA
22 Apr 98 16:38:53  23 Apr 98 00:37:47  [EMAIL PROTECTED]
        renew until 20 May 98 16:37:59, Flags: FRA

And if access DFS I get new DFS service tickets as well:

Ticket cache: /opt/dcelocal/var/security/creds/dcecred_6534fa08
Default principal: [EMAIL PROTECTED]

Valid starting      Expires             Service principal
22 Apr 98 16:37:59  23 Apr 98 00:37:47  [EMAIL PROTECTED]
        renew until 20 May 98 16:37:59, Flags: FRIA
22 Apr 98 16:38:53  23 Apr 98 00:37:47  [EMAIL PROTECTED]
        renew until 20 May 98 16:37:59, Flags: FRA
22 Apr 98 16:39:43  23 Apr 98 00:37:47 
[EMAIL PROTECTED]
        renew until 20 May 98 16:37:59, Flags: FRA
22 Apr 98 16:50:35  22 Apr 98 18:50:35  [EMAIL PROTECTED]
        renew until 20 May 98 16:37:59, Flags: FRA
22 Apr 98 16:50:35  22 Apr 98 18:50:35  [EMAIL PROTECTED]
        for client [EMAIL PROTECTED]
22 Apr 98 16:50:35  22 Apr 98 18:50:35  [EMAIL PROTECTED]
        for client [EMAIL PROTECTED]
22 Apr 98 16:51:23  22 Apr 98 18:50:35 
[EMAIL PROTECTED]
        for client [EMAIL PROTECTED]

Note I also did a K5 rlogin to apollo as well, and forwarded a ticket
which had all the same properties. 

-------------------------------------------------

The upshot of this is that you should be able to 
get a renewable ticket, and use a script with the job
to refresh it within the lifetime, without having to expose
your password. If you have AFS the script could
then use the renewed ticket to get a new AFS token too. 


If you have a real batch schedular, you may also want to
look at postdated tickets too. Before it can be used,
it needs to be "renewed" before it can be used.  

For more info on using K5 with DCE and/or AFS see:
ftp://achilles.ctd.anl.gov/pub/kerberos.v5/README.txt 




> I will summarize the responses.
> 
>             Daniel
> 
> --
> Daniel D. Arrasjid                   Computing and Information Technology
> Voice: (716) 645-6153                State University of New York at Buffalo
> Fax:   (716) 645-5972                301 Computing Center, Buffalo, NY 14260
> E-Mail: [EMAIL PROTECTED]      WWW: http://www.acsu.buffalo.edu/~daniel
> PGP public key: http://www.acsu.buffalo.edu/~daniel/key.html

-- 

 Douglas E. Engert  <[EMAIL PROTECTED]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444

Reply via email to