You probably know that I’m the PAM maintainer of Gentoo Linux, for good or bad (mostly bad, given that I don’t use most of its features, which I have to maintain nonetheless,). To ease my own work when trying to track down what users have been up to during bug triage, I created a package called pambase providing USE flags to enable standard configurations for particular, commonly used, modules.
This package got even more useful when we started having the need for particular features to integrate with our default stacks, for the users to be able to properly use them, like ConsoleKit and Gnome-Keyring, and to upgrade the hashing function to something less broken than MD5.
Now, all in all, I’m pretty happy to how pambase shaped up, it’s quite usable and I can easily make use of it to handle things like blowfish via xcrypt if wanted. Today I, indeed, received a request for pam_abl integration — well, the request was misdirected toward OpenSSH and the provided patch was totally bogus as it only added a nasty dependency, but the idea behind it is quite reasonable.
Now, we get back to the title: “pambase is not that free” does not have to do with the licenses related to pambase (which as far as I know are all well compatible) but rather with the work that goes behind it, for me and – much more – for the arch teams.
Adding support for a new (optional) module into the pambase package makes that module enter the system set; this is why, for instance, a good part of GNOME can now be considered part of the system set. You have to understand that even if it might not be in your system set, or in the default system set for what matters, the packages have to be carefully considered to not break if they are part of the possible system set, via optional USE flags as well. Adding gnome-keyring to that possible system set added a whole lot of branches in there.
Packages in the possible system set tree have to be paid special attention to: you cannot assume the presence of the entire system set for them, so things like zlib and bison have to be added to the dependencies of the ebuild (this is needed for the depgraph to be drawn correctly). Also, packages that are added to pambase need to be ready to go stable: if I were to add xcrypt or pam_abl to the possible dependencies of pambase, we got to be able to mark those two stable at some point in time.
This also adds quite a bit of burden to the maintainers of those packages, as the package will now be scrutinized much more deeply, and used by many more users (since they won’t need to know how to configure PAM to enable them).
Am I just ranting here? No I don’t think so; I just think I might have taken the wrong approach with pambase, and I’d like to see if other users have suggestion on which alternatives we could have. I guess something similar to what is done to fontconfig could be useful: get each module to provide some configuration files in, say, /usr/share/pambase/ and then have an eselect module to turn on and off the configurations.
The problem with this approach is that you have to cope with quite a few situations, which should probably be identified, modeled, considered and designed before implementation:
- should the generated files in
/etc/pam.d/considered to be user-editable? or should they just be generated and the user is responsible for using the application to deal with them? - should the module packages enable themselves by default? or should they leave to the user to enable them? and at unmerge time, should they disable themselves? (I guess so, otherwise the system would be left in an unusable state);
- if they get enabled at first merge, should something record that the user explicitly disabled them, so that they won’t re-enable themselves automatically the next time?
- should other services be set in such a way that they can be edited, so that you can configure e.g. the mail servers to look into a particular file, while the FTP servers in another?
Given there is so much stuff to be considered, I ask everybody who has a non-default PAM setup to please let me know about it, explain me how you use PAM in Gentoo so I can judge how to proceed in the future! Either comment here or, if you have privacy concern regarding your setup, send me an email: CC pam-bugs@g.o (g.o being our distribution’s domain, obviously!) if you care or, if you really don’t want details about your setup to be read by anyone else, send it directly to me and encode it so only I can read it.
Again, thanks, and please try to get this post around so I can gather as much details as possible on what we need.
First off, please don’t have *anything* enable itself automatically when merged. That’s not the Gentoo way; on Debian, when I install postfix, it’ll go right ahead and start a mail server for me. I hate that. Nothing else in Gentoo works like that, PAM shouldn’t either. If “enabling” consists only of “trying to install a file in a CONFIG_PROTECTed directory”, then I’ll just use dispatch-conf to permanently reject they change, so that’s OK. Disabling something on uninstall is a much better idea as the configuration is known-to-be-wrong.My PAM setup:- pam_unix for authentication on laptops- pam_krb5 for optional tickets on laptops- pam_krb5 for authentication on servers/desktops- pam_unix for accounts on laptops- pam_ldap for accounts on servers/desktops- krb5 and AFS session items where necessary- agents like gpg-agent and keyring started in my .zshrc along with a screen session; I don’t do any of this in PAM.When using multiple fallback methods the pam.d files can be non-trivial. I don’t want a lack of network access to prevent root logons, I do want kerberos credentials when they’re available, etc etc. If you’re making the pam.d files non-user-editable you’d better have a very, very powerful configuration tool to replace them.About pointing different services to different files: can’t you do this already? Dovecot uses /etc/pam.d/imap, etc. I think this is necessary, but it’d be nice if there were an easier way to view and change which service uses which PAM file.
Bryan, at a minimum, I’d never rewrite the files during or after @emerge@… an option as you noted is to use the CONFIG_PROTECT method of just creating a file to be accepted or rejected. I guess that should cover for most cases indeed.Dovecot is actually a good example of what I’d like to *avoid* right now: it uses @/etc/pam.d/imap@, while I think it should use @/etc/pam.d/dovecot@ with an include of the imap stack, so that you can have multiple IMAP daemons differently configured.But the idea about different services is mostly to have an easy way to edit all of them with a single configuration tool…If you could let me see your pam.d files for optional and mandatory Kerberos, that’s something that I would like to have an idea of to decide how to structure the future configurations, thanks!
I firmly believe the pam.d files should be user editable (and I do edit them). The entire concept of PAM is to be able to customize in a centralized way to meet your AAA needs.I am a long time user of pam_abl and pam_ldap. I’ve also used in the past the NIS/YP maps. I definitely don’t want an emerge -uDN world to muck with my PAM configs as I have already thoughtfully constructed them.Now I am an IT Security Engineer so I may have a colored perspective, but one of the reasons I run Gentoo is that I can mix/match and have it my way to as little or much as I want.Also just a note of appreciation for your work with pambase. Please keep up the excellent work!Wayne
It’s difficult to get the words right for me, so please excuse typos et al.I installed my first gentoo only last january and naturally fell in love. Handbook, Howtos, Forums of great help. In this way it has been possible for me to considerably improve performance of my hardware as compared to other distros.I followed all the steps and pieces of advice (worst vice) and took the time to understand the philosophy behind it. I knew a long time ago that gentoo would be a major event for me as soon as I’d be proficient enough.Still learning, but here I am:1. I asolutely need jack to work realtime. But for this specific topic, different docs seem of contradictory and anachronistic nature. So jack needs pam_limits. You’re doc on Sound/Realtime is appreciated, but the kernel config options have since then changed. So I feel like I could write down the steps of getting it to work as soon as it works.2. I feel like (I’m only learning PAM now) using pam for different auth processes based on USB-key, WiiMote or other bluetooth devices (phones) amongst others and setting limits and daytimes for specific services and users. (I also have requests from parents with skilled kids…). I may be concerned with RFID-badge authentication…So this looks like:pam_echo, pam_exec, pam_ldap, pam_limits, pam_securetty, pam_tally, pam_timestamp, and yes pam_unix and pam_wheelSorry if this may sound a little naïve. And yes please make pam behave, many users might not be aware of the power of pam.Thanks for the regular info on the progress of your work.May this message encourage other shy users to express themselves…
I do not customise PAM much on my machines (LDAP/PKCS#11 hacking, but no real need to industrialise something and it was more than a year ago), so my opinion has probably less value than the ones of more experimented people, but I will try to answer your questions, and with what matters more than short answers, _arguments_.Should pam.d/* files be considered user editable ? Definitely : YES. UNIX is about customisation, and customisation is through files. There are two things in a UNIX : files and processes. Processes are not meant to be written into. Win32 VirtualAllocEx, WriteProcessMemory and CreateRemoteThread[Ex] have no equivalent here, and that is for a reason : they are totally unnecessary (processes hierarchic relationships often help on that), since the customisation is not to be made on that level. But to remain unnecessary, all that can be possibly configured in the way a process works should be (ideally hot-)configurable in text files. That is how I see UNIX philosophy. That is how I think PAM should work.Should the module packages enable themselves by default…? Well… Auto-enabling is handy, but totally disposable. And probably not desirable in a security context like PAM, where paranoia can be seen as a quality. So my answer is a moderate but clear “no”. A /etc/pam.available_modules.d/ and even maybe a /etc/pam.default.d directories and only symlinks to /etc/pam.available_modules.d/ in /etc/pam.d/ may be a good way of doing things (think about Apache modules configuration : Apache, while extremely configurable and while its code is far from perfect, is close to a masterwork when it comes to administration). I have no Linux machine here to check but a similar model should be applicable. I recommand that no symlinks are created by default, or only if a special “pam-modules-symlinks” USE flag is active, like the “symlink” flag for linux kernel sources. And if there are two directories, if the filename exists, only the “default” version should be rewritten, not the “available” one. Except maybe when a version change occurs, with an update of pam.d files format, but we are not at that point right now.”should other services be set in such a way that they can be edited”…? I’m not sure I understand what you are thinking about. Services run under special “simple user” credentials. If authorisations are granted by PAM, it is made through a pam.d file, that of course can be edited, as explained above. And is it even a “feature” and not a misconception to consider that any service must absolutely run out of the box and without any user configuration ? ebuild * –config may help for configuration, if you really wish to do your user’s security work, as it works for PostgreSQL or MySQL, but even that is disposable. Gentoo users are no kids or, at worst, should not be considered like kids. And ENOTICE, EWARN or friends (I am no ebuild expert !)… have their use here, and should be enough.A.