On Wed, 03 Jul 2024 23:10:30 +0100 Luca Boccassi <bl...@debian.org>
wrote:
> On Wed, 03 Jul 2024 22:58:33 +0100 Luca Boccassi <bl...@debian.org>
> wrote:
> > On Wed, 3 Jul 2024 21:26:36 +0200 Michael Biebl <bi...@debian.org>
> > wrote:
> > > Am 03.07.24 um 21:00 schrieb Lionel Élie Mamane:
> > > > On Wed, Jul 03, 2024 at 07:25:15PM +0200, Michael Biebl wrote:
> > > > 
> > > >>>>> connect(5, {sa_family=AF_UNIX,
> > sun_path="/run/systemd/userdb/io.systemd.DynamicUser"}, 45) = -1
> > ECONNREFUSED (Connection refused)
> > > > 
> > > >> systemd should be listening on this socket
> > > > 
> > > > Well, on no less than four different Debian machines, it does
> not.
> > > > 
> > > >> $ sudo lsof /run/systemd/userdb/io.systemd.DynamicUser
> > > >> COMMAND PID USER   FD   TYPE             DEVICE SIZE/OFF NODE
> NAME
> > > >> systemd   1 root   28u  unix 0x0000000073ac41e2      0t0 8696
> > > >> /run/systemd/userdb/io.systemd.DynamicUser type=STREAM
(LISTEN)
> > > > 
> > > > Isn't that on a machine where systemd-userdb is installed
maybe?
> > The
> > > > installation of that package triggers the systemd binary to
> listen?
> > > 
> > > No, systemd-userdb is not installed and as you can see from the
> above
> > > output it's actually systemd which listens on that socket.
> > 
> > I can reproduce it by mounting a tmpfs on /run/systemd/userdb/
_and_
> > creating an empty io.systemd.DynamicUser file on it. Maybe it
should
> > not abort like that, however, if you have the directory in /run/
> _and_
> > the socket file exists _but_ nothing is listening on it, then your
> > machine is broken in some way. If the directory/socket are missing
> they
> > are just skipped gracefully.
> 
> I'm not sure what's the alternative here - if consulting NSS fails
for
> some local reasons because the machine is broken/misconfigured, I am
> not sure if it should just ignore it and continue it. If NSS is
> configured and is supposed to work, but doesn't for some
> temporary/local reason, you might end up creating a duplicated
> user/group, and I am not really sure that's better than bailing out
> without touching anything.

Consensus seems to be that in this bad situation it's slightly better
to complain loudly and continue, so the next point release will contain
a fix to this effect. You should still figure out how you ended up with
a dead af_unix socket in the first place, as that's a sign of something
seriously wrong on that machine.

-- 
Kind regards,
Luca Boccassi

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to