Your message dated Mon, 11 Feb 2019 20:55:09 -0800
with message-id <20190212045509.gb9...@virgil.dodds.net>
and subject line Re: Bug#920760: libpam-modules: does not ensure that
pam-auth-update gets called after the package was configured
has caused the Debian Bug report #920760,
regarding libpam-modules: does not ensure that pam-auth-update gets called
after the package was configured
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
920760: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=920760
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
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
--- End Message ---
--- Begin Message ---
Hi Andreas,
Thank you for the report.
On Mon, Jan 28, 2019 at 08:37:47PM +0100, Andreas Beckmann wrote:
> 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.
I disagree that this meets the definition of a serious bug, and therefore I
disagree that it is a bug at all. /var/lib/ is a package-owned data dir,
and I do not think there is any requirement in policy that files under this
directory be bytewise identical between 'apt-get dist-upgrade', 'apt-get
upgrade && apt-get dist-upgrade', and a clean install.
Because mkhomedir is not enabled by default, the net impact on the user of
having it in /var/lib/pam/seen or not is nil. This is only a problem for
the piuparts tooling, which I think should be relaxed to not consider this
an error.
I considered various options for resolving this - either moving the config
from the libpam-modules package to libpam-runtime; or bumping the versioned
dependency of libpam-runtime on libpam-modules; or having libpam-modules
call pam-auth-update itself - and I don't think that any of these changes
are per se correct, they are only workarounds to make /var/lib/pam/seen
"clean".
> 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.
If this config were meant to be enabled by default, I would agree. Since it
isn't, I don't think there's any requirement that the package present this
to the user on upgrade.
> Another option could be to add trigger support to libpam-runtime and
> have libpam-modules.postinst trigger libpam-runtime.
This seems like the most correct of the possible options, but I think it's a
big change for small benefit.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: PGP signature
--- End Message ---
