I’ve been spending the past ten days/two weeks handling two full-time job at once; one was Windows-related so it won’t have any direct effect in what I’d be posting on the blog, the other involved Amazon EC2, so you’ll be seeing more rants sorry I meant posts on the topic soon. But first, …
Thanks to Constanze who became a full-fledged developer (congratulations!), I’ve been able to breath a bit more widely for what concerns PAM; another positive note comes from Eray becoming developer as well, which means I can get someone looking at pam_krb5 package. Which means I can get back to work on the M4-powered pambase package so that hopefully before end of the year we’re going to get it in testing at least. Additionally, user prometheanfire on #gentoo-hardened provided me with a sample configuration for LDAP that should make it much easier to implement it on pambase.
But the situation starts to become much more complicated; for instance, the ConsoleKit situation is so intricated that making it behave as intended is actually quite difficult: the invocation of the module is different whether we’re going to authenticate a text login or an X11 login session; some time ago we also found the hard way that some graphical login managers fail badly when you print too much information on the PAM output channel (such as Messages of the Day, the last login data, and mail status). This all results in having to have different sessions for local text and local graphical logins. I have a huge headache already when I start to think about XDMCP already.
This turn of events also makes me think that I should simply drop the system-login service that I’ve used in the previous iterations. The reason to use and include this service was to avoid duplication, but with M4, duplication is avoided during build time, not after install. This should make available only the three “leaf” services: system-remote-login (with optional ABL support), system-local-login (not renamed for compatibility reasons) with text-based login, and (by default) mail/motd/lastlogin modules; system-graphical-login with support for X11-based ConsoleKit sessions as well as without the extra verbose modules.
A note here: somebody asked me why of the minimal USE flag for pambase; the reason is relatively simple: even though the output of those can easily be discarded, they will be kept loaded in memory by processes such as sshd and fcron; dropping the modules from the services mean also reducing the memory usage of those process, minimally, but it does.
After the login process is sorted out there is another problem here and it has to do with changing passwords; I’ve said that before, but I’ll repeat it here. When the new pambase will be put in place, software that is able to change password will have to be updated to use a different service to do so; this will hinder the changing of password through sshd that was noted in the comments of one of my previous posts, but it is necessary if we want to have proper restriction among login methods.
The problem is that with PAM design, for what concern changing passwords, you end up with either you have to know all the currently in-use authentication methods or you have to know only one of the authentication methods and then you change all the authentication method to the new value or you change only one authentication method to the new value.
The end result is that I can’t think of any way to do what would make sense: change the token only for the systems that actually use the current password provided. Lacking this the situation is that we cannot have a single tool to do everything, so we’re going to have to stick with many different password-changing tools: passwd, chpasswd and their cousins will only require the Unix password and will only change the Unix password. You’re going to use separate tools for Kerberos, LDAP, SSH keys, PKCS#11 tokens, …
While it might sound as suboptimal it’s a compromise that actually make pambase manageable without having to resort to actual custom Linux-PAM implementations. I hope you can all agree on that.
Anyway, this only acts as a braindump; I hope I’ll be able to set up real documentation about the pambase system at one point or another, including some simple drawing to show how the authentication flow actually happens. Unfortunately if you remember, I noted that OpenOffice is the only decent software I can find to write flowcharts; unfortunately that is both cumbersome to add to a GIT repository, cumbersome to auto-produce results (when what it exports is what you wanted), and finally quite expensive in term of dependencies. I should probably try Inkscape back, possibly tied with rsvg (now that gdk-pixbuf works without X) would be a decent choice.