pam-auth-update can fail during raring -> saucy upgrade leading you to a broken session

[Didier Roche-Tolomelli]

Context: a year ago, I added fingerprint support to my pam configuration (and then removed it)

During the raring -> saucy upgrade /usr/sbin/pam-auth-update failed (it needs --force), running it manually was telling me:
pam-auth-update: Local modifications to /etc/pam.d/common-*, not updating.
pam-auth-update: Run pam-auth-update --force to override.

The consequence is that as I have no system-logind support after it, I have my user not added in any group:
- no hw accel (as not in the video group)
- no sound (no audio/pulse group)
- no nm-applet showing…

I'm attaching the old common-session pam configuration, before forcing the update. I have also some .pam-old files
After forcing it, I have:
+sessio noptional pam_winbind.so
+session optional pam_systemd.so
and everything is back to normal (my user is now dynamically added to the relevant groups)

ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: libpam-runtime 1.1.3-8ubuntu2
ProcVersionSignature: Ubuntu 3.9.0-0.4-generic 3.9.0
Uname: Linux 3.9.0-0-generic x86_64
ApportVersion: 2.10-0ubuntu1
Architecture: amd64
Date: Mon May 6 15:40:22 2013
EcryptfsInUse: Yes
InstallationDate: Installed on 2012-05-28 (342 days ago)
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Release amd64 (20120425)
MarkForUpload: True
PackageArchitecture: all
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=fr_FR.UTF-8
 SHELL=/bin/bash
SourcePackage: pam
UpgradeStatus: No upgrade log present (probably fresh install)

[Steve Langasek (vorlon)]

Sorry, but this is fundamentally unfixable. If you have edited your pam configs by hand rather than using pam-auth-update, and p-a-u on upgrade is not able to automatically reconcile the differences it is because there is no "safe" path for doing so. Failing to activate important new modules on upgrade is suboptimal, but any attempt to do so carries with it risks of other regressions. So the only thing we can do here is notify the user that it wasn't updated, and let them use --force if they determine it's appropriate.

[Martin Pitt (pitti)]

What does it do to determine whether the config was user-modified? I can edit it by hand, and yet p-a-u updates the file correctly here. Does it store some md5s somewhere, or use the .pam-old files?

[Steve Langasek (vorlon)]

It uses checksums of the scaffolding for the file, plus information about the configured modules stored under /var/lib/pam.