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 ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
