GNU bug report logs - #32182
Login fail after core-update without reboot

Previous Next

Full log

Message #8 received at 32182 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Pierre-Antoine Rouby <pierre-antoine.rouby <at> inria.fr>
Cc: 32182 <at> debbugs.gnu.org
Subject: Re: bug#32182: Login fail after core-update without reboot
Date: Mon, 23 Jul 2018 15:17:07 +0200

Hello!

Pierre-Antoine Rouby <pierre-antoine.rouby <at> inria.fr> 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’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.