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
Attachment:
pgprQRM8qQKp9.pgp
Description: PGP signature