[OpenAFS-devel] Towards a better PAM setup

[Russ Allbery]

I've been pondering this a great deal since the AFS Hackathon and since
starting to look at what it will take to get the AFS PAM situation fully
up to snuff.  My conclusion after a fair bit of pondering is that I think
it's going to be best to maintain an AFS PAM module that's independent of
the OpenAFS tree, but that can use support libraries provided by OpenAFS
as needed.

Here's my reasoning:

 * I need a PAM module that I can deploy by the end of the year, and I'm
   not sure that I can get the work I did during the Hackathon into an
   OpenAFS release on that timescale since I built on top of a general
   restructing of the build system and added a new shared library.  I
   really needed a good PAM module that I could deploy a couple of months
   ago.  We're using Sam's libpam-openafs-session for right now, and it
   works as far as it goes, but it has some serious problems since it
   relies on aklog -setpag.  In particular, an AFS PAM module needs to put
   every session in a separate PAG regardless of whether it was
   authenticated with Kerberos and can get tokens or not.

 * I've since had a very positive experience with releasing pam-krb5 for
   general use, in particular with using the same code to support both MIT
   Kerberos and Heimdal.  I think we're going to want something similar
   here that supports the entire community in a single source base.  There
   are a lot of subtle bits to a PAM module that only turn up when using
   it with real-world applications, and I'd rather fix all those
   portability issues in only one place.

 * As a matter of practicality, a simple and quick win for Linux is very
   useful provided that it doesn't prevent support for other platforms.
   The hard part of the PAM module is the kernel interface to create PAGs,
   and on Linux with a modern client the system call interface via
   /proc/fs/openafs/afs_ioctl is dead-simple and requires no supporting
   libraries or special signal handling.

So, here's my current plan:  Starting with the first-draft module that's
currently in the OpenAFS head, I'm going to create a new separate package
and then add Autoconf machinery to select at build time between libkafs,
libkopenafs (when it's available), libafsauthent, and as a fallback, a
native implementation of the Linux proc interface.

For creating PAGs, it will use either k_setpag() and k_unlog() if
available, lsetpag() and lpioctl(VIOCUNLOG) for libafsauthent, or the
native Linux implementation, whatever is available.

For obtaining tokens, it will use either krb5_afslog() if libkafs was
detected or will fork an external program, with an option to have it fork
an external program even if built with krb5_afslog().

I have no intent of supporting K4; I think that there are other PAM
modules that can support K4 if anyone cares, and adding K4 support adds
considerable complexity to the module.

I think this should be fairly straightforward; most of the work is going
to be catching the edge cases in PAM rather than the logic of getting PAGs
and tokens.  This decouples the PAM work from OpenAFS, while still using
the libkopenafs work once it's out the door.  (And in the long run, we can
potentially embed aklog in libkopenafs and then export the same API as
libkafs and everyone is happy.)  And having the native Linux proc API
support means that I can start using this approach in Debian right now
without having to wait for a stable library API.  I also think it's
important to support everyone's favorite API, since it means that the PAM
module won't have to care exactly what's inside libkafs or libkopenafs
going forward.

Thoughts?

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>