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.
Dear Diego, here is a summary of what looks weitd to me in your plans. I should probably mention that the setup I rolled out at work runs on RHEL-like systems which are set up so that the only user with password which is in /etc/{passwd,shadow} is root, system accounts are in passwd, too, but real people are menaged by LDAP, their account data is not present on any box.First of all, it’s been a good habit to being able to change your passwords by simply typing `passwd`. I’m perfectly aware of the fact that certain setups have a well kwnown way to change passwords by completely different means, like a web application, but I have yet to encounter a setup which involves calling ldappasswd by hand.Let’s compare the ease of use of a simple call to `passwd` without any arguments to `ldappasswd` — using the latter, you have to specify the base DN of your LDAP tree, the DN of the user to bind to and a DN of the user to modify. There’s probably a default option for specifying that modifier = modifee, and I’m sure you can set a default base DN, too, but entering even a single DN is one too many in my opinion. The user is *alread* logged in to a box, so why should he explicitly mention under which DN to bind to LDAP?I realize that this is just a one user case to you, but to be honest, what do you think is more widesparead, having one user in two places (that’s the case you mentioned on IRC, a user in passwd/shadow and an extra copy in Kerberos), or a failry trivial LDAP setup?Finally, as a suggestion for further blog posts — I realize you go to great lengths trying to express yourself correctly, and I can tell you spent quite a lot of time in polishing this text. I appreciate that. I’d, however, also like to point out that I didn’t get what exactly you want to do with the M4, in which context it is going to be used — is that going to be a compile-time option intended for reducing PAM maintaners time (go for it!), or something that is going to be visible to the sysadmin (which would be a bad thing in my book, making Gentoo completely different to any other shipping distro using PAM, to the best of my knowledge). It’d help me much if you elaborated more on what exactly you were about to do here.I appreciate the time you put into doing Gentoo work, I’m merely pointing out flaws that I perceive. These could be desirable features for other people, perhaps for you. I’m simply trying to share my opinion, which is based on real-life work as a unix sysadmin with real users from the flesh :).Anyway, have fun doing whatever you do.
Let’s start with the first obvious thing: what pambase provides is, as the name says, *a base*. Nobody is forcing you to keep using what it provides, you can just set it up as you wish; I’m pretty sure I’m going soon to add Eray’s suggestion for Kerberos parameters that _I_ will be the first one disabling; why? Because I have a non-common setup, and I don’t see why my use-case would have to prevaricate what makes sense.For what concerns password, as I said I should draw a flowchart to provide a good idea of how stupid the only ways PAM allows you to do it are. While you can argue that if there is _only_ the LDAP user you can only change its password, LDAP is *not* the only system that pambase will be supporting. If anything it is the _latest_ system it is supporting. The fact that “LDAP works that way on RHEL” doesn’t really tell me much; you could have argued more strongly with “that’s what Gentoo infra does”, but you haven’t even started with that. In the context of the other systems, special-casing LDAP is _too much work_ given I’m still doing it almost single-handedly (as I said, I’m glad Constanze and Eray are now developers), and “unpaid”:https://blog.flameeyes.eu/2… even though the workload is heavier than that of most of my paid jobs.If your setup requires @passwd@ to change LDAP password, if anything, with pambase you’ll just have to edit _one_ file and be done with that, especially after the audit is complete. Right now you have to edit many files to actually have it working.As for “telling what I want to do with M4”, you could have looked it up easily; I have a search box in the top-right corner, using it brings you to “another post”:https://blog.flameeyes.eu/2… which provides a few more details about the situation; I also talked about an m4 branch, which is “in the pambase repository”:http://git.overlays.gentoo…. in turn available to the public. Doesn’t look difficult to track down.
Diego,As you mentioned before it is difficult to find good solution for pam authentication, especially in disconnected mode for laptops.I just found something, that could be useful and hopefully solve many problems you encounter:https://fedorahosted.org/sssd/And the last, but not least, thank you for great job.