On Fri, Mar 14, 2003 at 12:45:59AM +0100, Sebastian Rittau wrote: > * With the current setup, an administrator who wishes to use a separate > setup or different modules, has to change all the PAM files in > /etc/pam.d by hand, looking for possible pitfalls. After installing a > new package that uses PAM authentication, another PAM file must be > configured. (If the admin knows that the package contains a PAM file, > that is.) Yes. Unfortunately, to fix this by default for Debian, someone has to go through all the PAM files in /etc/pam.d by hand, looking for all possible pitfalls. :) > * The way it's currently done might even be harmful. Consider a system > that gets its users information from LDAP, but only a selected group > the users in the database is allowed access. This is configured using > a custom module and works fine. Now the administrator decides to > install the ssh package. SSH will put another default PAM into > /etc/pam.d, allowing *every* user to connect, by means of the > pam_unix.so module. > The solution to this is quite simple: Every package that comes with PAM > support should not install a valid PAM file in /etc/pam.d. Instead it > should come with an example file, maybe called /etc/pam.d/<package>.ex. > If the administrator wishes to use a custom configuration for this > package, he can edit this file and rename it properly. Otherwise the > default configuration in /etc/pam.d/other will get used automatically. > This would allow administrator to edit only one file, which will get > used by all PAM using packages. > Opinions? Attached is a quick proof of concept for using the @include (not $include, sorry) syntax in /etc/pam.d for a Kerberos/Unix site. A significant amount of work is required to massage this into something that Debian could ship, but it should provide a starting point for someone with the time and ambition to take this on. Using this approach, some apps will still need to provide their own configs (ssh and su being two examples -- login is left as an exercise for the reader), though greatly simplified, and others don't necessarily need separate config files at all (passwd is a good example here, I think), in which case a .ex file seems reasonable. The ideal solution has common-* as debconf-managed non-conffile config files. Under NO circumstances should they be made conffiles, since the entire reason for the existence of these files is to make the system more *friendly* for admins who don't use the defaults. ;) -- Steve Langasek postmodern programmer
Attachment:
pam-revamp.tgz
Description: GNU Unix tar archive
Attachment:
pgpEkzepjzRJi.pgp
Description: PGP signature