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