An NMU of the core PAM packages has just been uploaded to unstable with the maintainer's permission, and is currently available at http://incoming.debian.org. The upload addresses the longstanding issue of central management of PAM authentication/password services in Debian. This message is an appeal for further testing, and an attempt to document what needs to be done in other PAM-using packages to take advantage of these exciting new features.
From the changelog: * Add three new config files (/etc/pam.d/common-{auth,account,session}) to libpam-runtime. Other packages which depend on libpam-runtime can now @include these files from their own PAM configs. * Convert /etc/pam.d/other from a conffile to a non-conffile config file. Closes: #186011. What this means: - It will now be possible to choose md5 vs. crypt passwords at install time without violating policy. (Currently, a number of conffiles are being modified by maintainer scripts in order to enable md5 passwords.) Actually making this process policy-compliant will require changes to a number of other packages prior to release. - As packages switch to this new config file scheme, administrators will have a central set of files (four) they can edit to set a system-wide policy for authentication to services, including services from not-yet-installed packages; while packagers can continue shipping their per-package default settings as conffiles. - At a later date, it will be possible to support tools for debconf-based management of the authentication subsystem so that administrators can seamlessly integrate workstations into (e.g.) Kerberos, LDAP, or Windows NT authentication realms. No work has been done yet to develop these tools, and they are unlikely to be ready in time for sarge; but this is a realistic goal for sarge+1, or for customized installers based on sarge. I believe that, with your help, we can convert most PAM-enabled packages in Debian in time for Sarge's release, following the guidelines below. - Per-package /etc/pam.d/ configuration files should not include explicit 'password' blocks. Instead, services should use the builtin libpam fallback to /etc/pam.d/other for their password changing policy. - Configuration files should be modified to no longer reference pam_unix directly. For auth, account, and session blocks, such references should be replaced with these lines: @include common-auth @include common-account @include common-session These @include lines are handled as literal includes by libpam, so packages that currently use other modules besides pam_unix (or offer commented-out examples) need only leave those surrounding module lines intact. - A versioned dependency on libpam-runtime (>= 0.76-13.1) must be added to each PAM-using package. In addition, packages that don't already depend on the libpam-modules package must do so. (Transitive circular dependencies prevent libpam-modules from being pulled in automatically for you.) - Essential packages which currently pre-depend on libpam0g (read: login) will also need a versioned Pre-Depends on libpam-runtime before adopting this scheme, so that they are usable in an unconfigured state. Please consider this an introduction to the debian-devel discussion as mandated by Policy section 3.5. This concludes the roadmap for sane PAM handling in sarge. Should be straightforward, right? It's only 100 packages or so... One final comment: I know how excited everyone will be about this revolutionary breakthrough, but owing to the newness of this change, I would ask that you *not* avail yourselves of the 0-day policy to start NMUing packages as part of this transition. A partial transition for sarge is much better than locking users out of their systems, so there's no need to be impatient with maintainers before we've even put the code through its paces in unstable. Happy Hacking, -- Steve Langasek postmodern programmer
pgp2ZJtPRfxv8.pgp
Description: PGP signature