Package: libpam-modules
Version: 1.1.8-4
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
While on initial install there is a defined ordering between
libpam-modules and libpam-runtime, these two packages may be upgraded in
any order.
I noticed this bug because piuparts complained on some stretch->buster
upgrade paths that /var/lib/pam/seen was not matching the reference
chroot. Looking in depth the "mkhomedir" entry was missing.
This is the upgrade order for some libpam* packages, the first block is
for creating the reference chroot, the second one for the actual test
that failed:
$ grep -E 'starting over|(Setting up|Unpacking) libpam' /tmp/pamlog.bad.log
Unpacking libpam0g:amd64 (1.1.8-4) over (1.1.8-3.6) ...
Setting up libpam0g:amd64 (1.1.8-4) ...
Unpacking libpam-modules-bin (1.1.8-4) over (1.1.8-3.6) ...
Setting up libpam-modules-bin (1.1.8-4) ...
Unpacking libpam-modules:amd64 (1.1.8-4) over (1.1.8-3.6) ...
Setting up libpam-modules:amd64 (1.1.8-4) ...
Unpacking libpam-runtime (1.1.8-4) over (1.1.8-3.6) ...
Setting up libpam-runtime (1.1.8-4) ...
1m19.2s INFO: Notice: package selections and meta data from target distro
saved, now starting over from source distro. See the description of
--save-end-meta and --end-meta to learn why this is neccessary and how to
possibly avoid it.
Unpacking libpam-runtime (1.1.8-4) over (1.1.8-3.6) ...
Setting up libpam-runtime (1.1.8-4) ...
Unpacking libpam0g:amd64 (1.1.8-4) over (1.1.8-3.6) ...
Setting up libpam0g:amd64 (1.1.8-4) ...
Unpacking libpam-modules-bin (1.1.8-4) over (1.1.8-3.6) ...
Setting up libpam-modules-bin (1.1.8-4) ...
Unpacking libpam-modules:amd64 (1.1.8-4) over (1.1.8-3.6) ...
Setting up libpam-modules:amd64 (1.1.8-4) ...
So pam-auth-upgrade got called with all the old packages installed.
Only thereafter libpam-modules got unpacked that brought a new
pam-config: /usr/share/pam-configs/mkhomedir
This may be harmless in this case (the new module is disabled by
default), but in general libpam-modules should ensure that any updated
configuration it delivers gets processed by pam-auth-update.
One option would be to have libpam-runtime
Depends: libpam-modules (>= ${source:Version})
but that would still allow partial upgrades of libpam-modules over an
old libpam-runtime version (that does not get updated).
Another option could be to add trigger support to libpam-runtime and
have libpam-modules.postinst trigger libpam-runtime.
The full log from the failing case is attached.
The only difference between success and failure is the way the upgrade
is performed, which changes the order of upgrading the packages:
GOOD: apt-get dist-upgrade
BAD: apt-get upgrade && apt-get dist-upgrade
Andreas
pamlog.bad.log.gz
Description: application/gzip
