Re: PAM release status
On Sun, Apr 04, 2004 at 04:28:51PM -0400, Sam Hartman wrote:
> 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.
This sounds appropriate, assuming that it will receive sufficient testing
before any kind of base system freeze.
> 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.
If the user has broken or unconfigured packages on the system, I think it is
understood that things may be temporarily inconsistent. As long as you can
ensure that when the package is completely installed and configured,
everything is as it should be, then I don't see a problem.
The appropriate error unwind facilities should be used to ensure that the
package is restored to a sane state; I think that will cover most of the
> 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.
This has caused a lot of headaches with UML and rootstrap as well, and I
would be grateful if whatever facility is provided is suitable for automated
installations. I intend to provide a facility to allow for a default
password to be set, but it is surely less confusing for there to be none at
all (otherwise the user must search the documentation to find out what the
default password is).
> 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.
ucf may be of some use here.