Subject: bug#52533: guix deploy breaks SSH access with a PAM error

From: Ludovic Courtès <[email-masked]>
Date: Mon, 17 Jan 2022 14:25:24 +0100

Hi,

Maxim Cournoyer <[email-masked]> skribis:

>>> I was just kicked out of my own server due to this PAM/SSH issue. It
>>> happens quite frequently here. Time for a fix :).
>
> Not a meaningful contribution to the discussion, but my workaround is to
> disable PAM; as it is not enabled in OpenSSH by default, perhaps we
> should also leave it off unless requested?  What are the advantages of
> having it on?

Consistency: authentication had rather work consistently across all
system services that depend on it.

[...]

>> The crux of the problem rather is the global /etc/pam.d: it’s valid for
>> pre-glibc upgrade programs, or for post-glibc upgrade programs, but not
>> both.
>>
>> FHS distros have a similar problem though; how do they handle it?  Do
>> they force services to be restarted when glibc is upgraded, or something
>> along these lines?
>
> I just asked this question in Debian's OFTC channel:
>
> "how does debian handle glibc updates?  are services restarted when it
> happens?  Or does it postpone updating glibc until the next reboot?"
>
> And got for answer: "there is no magic postponing of updates"; the
> external needrestart [0] program was also mentioned.
>
> Researching some more, it seems this may be handled on Debian by the use
> of postinst scripts (which is an arbitrary shell script run after a
> package is installed); so the libc package of Debian for example
> restarts the postgres service to avoid problems:
>
> [0]  https://github.com/liske/needrestart
> [1]  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=710275

Yeah.  My recollection is that apt is interactive by default, and it
would typically pop up a dialog telling you that services X and Y need
to be restarted, and asking whether you want to restart them now.

The difference compared to what we have (a message at then telling that
you “may need” to run ‘herd restart X’), the benefit IIRC is that it
tells you which services need to be restarted.

[...]

>> We could maybe sidestep the issue altogether with socket-activated
>> services: they’d be started on-demand, so the second scenario above
>> would be unlikely.  But getting there is quite a bit of work…
>
> I fail to see how this would be a solution for openssh, which would
> typically already be running unless you've never login ounce since the
> machine was up (or am I missing something?).

sshd could also be started via socket activation; ‘sshd’ subprocesses
corresponding to existing logins would be unaffected.

> Also, it seems to me inetd can already do "socket activation", if this
> was somehow useful.

Yes, inetd can do that.  It would be nicer though to have it all
integrated in the Shepherd.

(Basically, it’s a choice we could make right away: do we move all
network daemons, plus things like guix-daemon, dbus-daemon, etc. etc. to
inetd services, or do we instead extend the Shepherd to support socket
activation?  I’m rather in favor of the latter, but if in Guix System we
build an abstraction that can equally well target inetd or a future
Shepherd version, that’s even better.)

Ludo’.