[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#32182: Login fail after core-update without reboot
From: |
Ludovic Courtès |
Subject: |
bug#32182: Login fail after core-update without reboot |
Date: |
Mon, 23 Jul 2018 15:17:07 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) |
Hello!
Pierre-Antoine Rouby <address@hidden> skribis:
> I think login try to use glibc-2.27 but it's still configured to use
> glib-2.26. It's possible this issue come from '/etc/pam.d/login'.
Indeed. The problem here is that ‘reconfigure’ updates /etc/pam.d, but
does not change the service definition of ‘login’, etc. Thus, when
‘login’ restarts, it reads the new /etc/pam.d/login, which contains a
line like:
session required /gnu/store/…-elogind-232.4/lib/security/pam_elogind.so
Consequently, ‘login’ dlopens pam_elogind.so, which is linked against
the new libc, which eventually causes it to crash.
It’s a real issue on headless servers because you could lock yourself
out (‘sshd’ could have the same problem.)
I can think of several solutions:
1. Arrange for services to refer to /gnu/store/…-pam.d instead of
/etc/pam.d. This can maybe be achieved by modifying PAM such that
these applications honor $PAM_DIRECTORY or something like that.
2. Add support for “service chain-loading” in the Shepherd and/or
GuixSD. The idea is that, for services that cannot be restarted
right away because they are currently running, register code to
upgrade the service next time it is restarted (see
<https://bugs.gnu.org/30706>). That way, when ‘login’ restarts
after ‘reconfigure’, it’s the new ‘login’ service that would be
restarted.
Thoughts?
Ludo’.