Globus and AFS

Francesco Prelz - INFN Milano
Bologna, January 11, 2001

How to access AFS space now in a quick, dirty, unsafe, bad and grid-unfriendly way:

The globus gatekeeper is able to execute an arbitrary "login" command immediately after starting. This done via the globus-k5 program, which is invoked when the gatekeeper is started with the -k option. The "login" command is associated to a Globus user ID (X509 DN) via yet another mapping file, the "globuskmap" file. The name of the globuskmap file needs to be specified as a gatekeeper option as well (-globuskmap filename).
In the standard Globus installation the options have to be added to the deploy_dir/etc/globus-gatekeeper.conf file:
-k -globuskmap /etc/globus/etc/globus-kmapfile.
When access to protected AFS areas is needed and an AFS token needs to be obtained, one can naively add the appropriate command to the kmapfile. For instance:

"/C=IT/O=INFN/L=Milano/CN=Francesco Prelz/Email=francesco.prelz@mi.infn.it" /usr/afsws/bin/klog -principal prelz -password ******* -cell infn.it

The password needs to be specified in cleartext. The file can be made only readable by root, but even this way this is obviously not an acceptable solution.
The token lifetime can be specified with the -lifetime option once for all only by the remote system administrator. There's no provision for reissuing tokens (the Kerberos V4 token validity cannot be "extended").

Another caveat: even if the system is able to obtain an AFS token, it's up to the user to issue the approriate unlog command to remove valid tokens from the executing machine cache.

This (extremely bad) way of accessing AFS was tested with the current Globus toolkit and works.

'Correct' ways to obtain an AFS (Kerberos V4) token.

Kerberos V5 provides ways to transfer and extend tickets, plus a GSSAPI implementation that could be used in place of the Globus GSSAPI. The trouble is that Transarc (commercial AFS) has no plans to adopt Kerberos V5, and nobody knows whether OpenAFS will ever get there. There is a rather makeshift tool, derived from MIT work (ak5log) that can build a Kerberos V4 AFS token based on Kerberos V5 authentication information. This assumes there's a Kerberos V5 authentication infrastructure in place, and we don't have one.
We could however use another Globus tool (sslk5) that provides a client/server pair where the server generates Kerberos V5 tickets based on Globus (X509) credentials. If access to the user information AND to the AFS/Kerberos private key is available, one could in principle generate a V5 ticket based on the AFS private key, then convert it to a V4 AFS token. Roberto Gomezel will try to understand whether it is possible/feasible to access to these AFS internals.

The most 'correct' way of them all...

Kerberos and GSI are actually two solutions to the same problem. In an ideal world we should have just one of them. The grid "should" provide the same level of delocalized file access that AFS provides.