[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Transition: new PAM config file handling in unstable

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
- 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
- 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

Reply to: