[OpenAFS] Changes for Mosaic's AFS cell...

[Christopher Allen Wing]

Rodney:

> 2.  I'm curious as to why no one responded to the problem with xlock and
> xscreensavers relating to PAM, K5 tickets, and tokens.  Is this some kind
> of state secret, or are we the only ones with the problem?  To summarize
> again...
>
>       On Linux the xscreensaver runs as the user but appears to be started
> by init.  When the screen is locked, then unlocked, the PAM module
> generates a new Kerberos 5 ticket, but doesn't use the correct ticket
> cache.  It seems to always create a new ticket cache.

This is entirely dependent on which "Linux" you are using.  Various linux 
distributions include different PAM modules, and different versions of 
xscreensaver as well.

xscreensaver is not started by init, it just has no parent process.  This 
is because the GUI environments used on Linux (GNOME, KDE, etc.) generally 
don't have a single process that looks after everything.  When 
xscreensaver starts up it forks and runs in the background, which is why 
it shows up with a parent process ID of 1 (init).


All I can say is that in my experience, the PAM module which is developed 
by Red Hat (which they call pam_krb5) works properly and does the right 
thing with xscreensaver.  When you unlock the screen, it does the 
equivalent of a 'kinit', replacing the existing ticket cache (from 
$KRB5CCNAME) with a fresh ticket, and obtains new tokens.  RHEL4 seems to 
work properly, and I assume that recent versions of Fedora should also 
work.

If you are using a recent Red Hat distribution and pam_krb5 doesn't work, 
then something must be broken and I can probably help you debug it.  If 
you are using an old (obsolete) distribution, then your PAM module might 
be bad.

If you are using a non-Red Hat distribution, you could try compiling the 
pam_krb5 code (which you can download from the Fedora site, etc.) and it 
should work.


> 4.  I gather from the responses that we need a "special" AKLOG to remove
> the need for the 5 to 4 daemon in a pure K5 environment.  I'm unsure what
> is meant here by "special".  I mean the OpenAFS Windows client ships with
> AKLOG.  Is it special?  Is the Linux version "special"?

The aklog which comes with the 'afs-krb5 migration kit' only supports 
using the krb524 service.  In the past, Derek Atkins's OpenAFS RPMs (e.g, 
the 1.2.x RPMs on the openafs.org web site) included a version of this 
aklog.  So if you are using those (older) packages on Linux, or if you 
compiled aklog yourself from the afs-krb5 kit then you would be using the 
524 service.

As of OpenAFS 1.4.x, the openafs source code includes its own version of 
aklog, which does not require the 524 service (however, it can optionally 
make use of it with a command line flag).  The 1.4.0 RPMs that you can 
download from openafs.org do not use this aklog, they use the older one 
from the afs-krb4 kit; however, when the 1.4.1 RPM comes out, it will use 
the built-in aklog which does not require krb524.


So the short answer is, if you build OpenAFS 1.4.x yourself from source, 
and if you properly configure so that the included aklog is built, then 
you will have an aklog which does not require krb524 to function.  Or, if 
you wait until the official 1.4.1 release (or if you use the most recent 
1.4.1rc prerelease RPMs), then the RPMs from openafs.org should include a 
precompiled binary of this aklog.


The way to tell which aklog you have is to run it with the '-help' option:

 	% aklog -help

 	Usage: aklog [-d] [[-cell | -c] cell [-k krb_realm]] [[-p | -path] pathname]
 	    [-zsubs] [-hosts] [-noauth] [-noprdb] [-force] [-setpag]
 	    [-linked] [-524]
 	...
 	...
 	-524 means use the 524 converter instead of V5 directly


If you see '-524' listed as one of the options, that means that you have 
the new aklog that does not use the 524 service by default.  (you need to 
run it with the -524 flag to force it to use 524)


On the other hand, an 'old' aklog looks like this:

 	% aklog -help

 	Usage: aklog [-d] [[-cell | -c] cell [-k krb_realm]] [[-p | -path] pathname]
 	    [-zsubs] [-hosts] [-noauth] [-noprdb] [-force] [-setpag] [-linked]



I am not familiar with the Windows and Mac packages, so I don't know what 
type of 'aklog' program is included or how it behaves.  (sorry, I'm too 
busy to browse the openafs source right now and figure this out, but if 
you take a look, the Windows aklog is in its own directory apart from the 
one used on Unix)


>       a.  We need a special AKLOG.  Ok, is there one for
> Windows?  Linux?  Solaris?, OSX?, etc?

For Unix, if you build using OpenAFS 1.4.x from source, then the included 
aklog does not require krb524, and indeed, it does not use it by default. 
Note that when compiling, you generally need to tell it the location of 
your kerberos libraries and include files via a configure option.

I don't know which aklog is included with the 1.4.x packages for Solaris 
or OS X- someone else can fill you in, or else you can just download the 
binaries and take a look for yourself.

>       b.  Do all the PAMs for various OSs support this "special"
> feature?  Or do the PAMs just system out to an existing AKLOG?

There are many different PAM modules out there and they all behave 
differently.  The OpenAFS source code does not include a Kerberos 5 PAM 
module.

The Red Hat developed PAM module, which they call pam_krb5, does support 
getting AFS tokens without the krb524 service (provided you are using a 
recent version; old, obsolete distributions will have an older pam_krb5 
module that can't do this).

It's also possible to write a 'universal' PAM module that does nothing but 
fork off an aklog process.


-Chris Wing
wingc@engin.umich.edu