Package: passwd
Version: 1:4.0.3-7
Priority: grave
Justification: Policy section 11.7.4 (configuration file sharing)
Tags: sarge, sid
First off, this bug is related to bug #186011, #97548, #110228, #159487,
#171808, #182506 (at least that I know of) and is present in many upgrade
paths (from potato to woody, from woody to testing or sid). IMHO it's worth
being a RC bug and I'm CCing: -devel since recent discussion (see below) on
how to implement a consistent PAM behaviour could help fix this bug.
The problem resides in the way a user defined configuration (debconf's
passwd/md5) is handled. Currently, the passwd packages uses this
information to change many configuration files from other packages
(all under /etc/pam.d/)
The culprit code is in passwd's maintainer configuration script (lines
113-131 which enable MD5 support):
1.- it modifies _all_ configuration files under /etc/pam.d/ which do not
necesarily belong to passwd. Including: cron, gdm, kdebase-bin, kdelibs3,
kdebase, login, libpam-runtime, ppp, ssh, login, sudo, and xdm (in my sid
system)
2.- it even modifies files which are not used by packages (conffiles moved
by dpkg, i.e *.dpkg-old), since no name checking is being done there.
3.- also, it modifies files which have been changed _not_ to use
pam_unix.so. Although the changes involve only sedding them and moving a
new file over the previous one this might have unexpected problems (see bug
#182506 for example). My system has none of those but I believe some admins
might have changed their PAM authentication method and do not expect this
to happen.
It is is worth noting that the passwd configuration script won't run when
doing an install or upgrade. Due to this:
# Check to see if the package is being reconfigured.
# I don't want to bother on an initial install or on upgrade, because
# some of the password stuff below could mess with a perfectly working
# system when passwd was just harmlessly upgraded (that has happened
# in the past).
if [ "$1" != reconfigure ]; then
exit 0
fi
However this introduces a new bug: when a user configures his system to use
md5 configuration right after installation and upgrades, this configuration
is not carried over when packages providing /etc/pam.d/ files are upgraded.
Which causes bugs #186011, #97548, #110228 and #159487
Passwd should never modify other package's configuration files, as per
policy section 11.7.4. If passwd is going to modify them it should be
through a consistent interface which is used during installation _and_
upgrades.
The current situation, in which all pam.d files are marked as conffiles and
modified blisfully by passwd on installation/reconfiguration is completely
against policy and should be fixed.
The recent discussion on debian-devel [1] might be relevant. If
passwd (or a pam-common package) provided a default pam configuration used
by all packages, then all the upgrade and shared configuration file issues
would (possibly) disappear.
I.e. have a package (passwd? pam-common?) put an /etc/pam.d/default
configuration (used by the others, maybe through @include). And have this
package responsible for changing configuration of all PAM modules (like MD5
support) through debconf.
Best regards
Javier Fernandez-Sanguino
[1]
http://lists.debian.org/debian-devel/2003/debian-devel-200303/msg00804.html
Attachment:
pgpnvshge9PY1.pgp
Description: PGP signature