PAM release status

[Sam Hartman <hartmans@debian.org>]

[Hi.  Copies on replies appreciated.]

I've just upgraded three bugs that have been languishing for a while  to
RC status on the PAM package.

I'd like to explain to the community what's going on with these issues
and what I plan to do about them.  Comments are welcome, but unless
there is a strong consensus I'll move forward as described here.  I'd
appreciate confirmation of my direction on the first issue from the
community.

1)  PAM upgrades from woody force users to answer a dpkg conffile
    question.

Whether md5 passwords are used is stored in /etc/pam.d/common-passwd
on sarge systems.  Under woody, it was stored in the individual
*conffiles*  in /etc/pam.d.  

Under woody, base-config asked the user whether they wanted md5
passwords and then modified the conffiles to reflect the user's
preference.  That's unfortunate, because it guarantees that  users
will see a confusing dpkg warning about a conffile they have changed
when they upgrade from woody to sarge.  In sarge, the conffile
includes /etc/pam.d/common-passwd instead of specifying the  module
directly.  

I believe it is unacceptable for an upgrade of a default install of
woody to sarge to ask dpkg conffile questions.  My current proposal is
to detect this situation in the preinst of libpam-runtime by noticing
if we are upgrading from the woody version of PAM and if the md5sum of
/etc/pam.d/other matches one with md5 passwords.  If so, then I will
modify the file back to the state woody ships with in the preinst.
I'll submit similar patches to shadow.

The down side of this proposal is that if  the user somehow aborts the
upgrade between running the preinst and the  upgrade completing, they
will have md5 passwords disabled.  I think that's acceptable, because
when they do eventually upgrade to sarge, the md5 passwords will be
enabled again.

I've considered and rejected other options including accepting the
dpkg prompt and  making /etc/pam.d/other be a configuration file
rather than a conffile.

2)  Installations that end up with a null root password prevent root
    from logging in.

Under woody, the PAM configuration of login allowed null passwords.
Sarge consolidates all PAM configurations for authentication.  I don't
think you want default behavior to allow null passwords for ssh or
other remote services.  So the current default is to not allow null
passwords.  But really you do want to allow them on the console
especially after the install.

Steve Langasek, Karl Ramm and I discussed this issue.  The proposal is
to add functionality to pam_unix to allow null passwords from devices
listed in /etc/securetty and to make this behavior be the default for
Debian.  Steve wanted to make this be the default behavior for
pam_unix and was going to talk to upstream about making this the case.
I haven't heard back from him in a few weeks, so I'm going to add an
option rather than making this be the default.  If upstream eventually
accepts making this be the default, then the option can become a noop.


3) Sarge disables password quality checks.

When creating /etc/pam.d/common-password, we we managed to lose the
minimum length and other checks for password quality.  Oops.  This
should be fixed.  It's somewhat annoying to fix because I need to
implement conffile-like behavior even though /etc/pam.d/common-* are
not conffiles. But I can do that.


			      Time Line

I hope to get at least two of these issues dealt with today and to
have an upload containing all three fixes by next weekend.