One of my projects is now unleashed in the tree: pambase is now being keyworded by all arch teams so that all ~arch users can make use of it.
I’m also preparing some documentation about it, but it might take a bit more time before it is available, unfortunately the time is what it is, and tomorrow I have to go to the hospital again.
One thing that pambase is supposed to do is to make it easier for me to handle the different PAM configuration files for Linux and FreeBSD, as I can just make stuff conditional in a single configuration file rather than in multiple ones sparse on the tree.
Today I hit the first two issues where this is really important.
The first was with pam_nologin: the Linux-PAM implementation supports running it in the account chain (as needed by OpenSSH’s sshd), the OpenPAM one supports it only on auth chain. So it has to be conditional. To have the conditional inside net-misc/openssh it would be an overhead.
The second was to finally add pam_passwdqc to the default system auth stack. As it is now, by enabling the passwdqc USE flag, you add to the default passwd chain the pam_passwdqc module developed by OpenWall, which is a different analysis module from the one that you most likely got by default (pam_cracklib). It is used by default in FreeBSD, but it wasn’t present in Gentoo/FreeBSD up to now. With pambase, it will soon be present by default in Gentoo/FreeBSD, reducing a bit the difference between FreeBSD and Gentoo/FreeBSD.
You should get used to a lot of USE flags in pambase as that is what I thought it for, you can tweak most of the default configuration simply by switching around the USE flags. More will follow in the future.
Talking about PAM, I also added one more possible project to the SoC page (as well as adding a column for the contact). The new project is:
Gentoo supports already two PAM implementations, but they are tied to one operating system only: Linux-PAM (sys-libs/pam) on Linux and OpenPAM (sy-auth/openpam, plus sys-freebsd/freebsd-pam-modules) on FreeBSD. Being able to choose between either implementation on either operating system is one of the long term goals of the PAM team. The first step would be to produce a set of single PAM modules compatible with both Linux and OpenPAM that could replace Linux-PAM and its default set of PAM modules.
As it says, I’d like to be able to provide users with a choice, on whether to go with Linux-PAM or OpenPAM. OpenPAM is more lightweight. And by splitting the modules up in a number of packages, it should be more flexible for different configurations.
Other than adding modules, it would be nice to implement libpam_misc in a OpenPAM-compatible way, so that all the software that use libpam_misc could finally be used without Linux-PAM. An alternative would be to port the software that uses it not to use libpam_misc.
So if you’re interested in learning how Linux (and other Unix) authentication support works, and you’d like to be part of something entirely new, feel free to contact me to flesh out details for your application with SoC!
I admire your efforts to make both PAM implementations as widely available as possible. Most Unix users don’t even know what PAM is, much less know which flavor does what.