Bug#1116563: gdm3: version 49 doesn't start if libnss-systemd is only partially configured in nsswitch.conf

[Simon McVittie]

Control: reopen -1 49.0.1-1
Control: retitle -1 gdm3: version 49 doesn't start if libnss-systemd is only partially configured in nsswitch.conf
Control: tags -1 + experimental help
Control: severity -1 serious
Control: affects -1 + libnss-systemd

I'm reopening this because even though Dmitry's immediate issue has been 
resolved, it is something that needs to be resolved one way or another 
before we can have a working GNOME 49 in unstable, either via a fix or a 
workaround in gdm, or by reassigning to some other related package and 
fixing it or working around it there.

For context, gdm 48 and older used a single system user, for historical 
reasons named Debian-gdm, to run all instances of the "greeter" (login 
prompt). On a simple laptop/desktop there is only one greeter, but on 
multiseat or with remote logins there can be more than one. This sharing 
is done even though conceptually each greeter ought to be 
privilege-separated from all other greeters, and also they each need 
their own private D-Bus session bus (therefore the greeter cannot use 
D-Bus in the preferred dbus-user-session/"user bus" mode, and must start 
a separate dbus-daemon instance for each greeter).

In gdm 49 and up, it has switched to generating and using a separate, 
dynamic, temporary system user for each greeter instance, using 
systemd's dynamic users functionality. This provides privilege 
separation between greeters (reducing the risk that one user's password 
might somehow leak into another user's greeter), allows them all to 
have a separate XDG_RUNTIME_DIR and use dbus-user-session/the "user 
bus", and allows them to use `systemd --user` for session startup.

However, this does rely on systemd dynamic users working as intended, 
and it seems we can't rely on that right now.

I have this configuration in my nsswitch.conf on a relatively 
recently-installed laptop (originally installed with bookworm), and gdm 
works as it should:

On Sun, 28 Sep 2025 at 20:47:50 +0300, Dmitry Shachnev wrote:
>On Sun, Sep 28, 2025 at 06:21:32PM +0100, Simon McVittie wrote:
>> passwd:         files systemd
>> group:          files systemd
>> shadow:         files systemd
>> gshadow:        files systemd

but Dmitry had this (presumably either manually configured, or left 
there by an older version of libnss-systemd?) and gdm 49 was unable to 
start:

>passwd:         files systemd
>group:          files systemd
>shadow:         files
>gshadow:        files
>
>I found a related dh-nss bug #1113745, but it was marked as wontfix by the
>dh-nss maintainer.

I can understand the dh-nss maintainer's reluctance to override sysadmin 
configuration; but at the same time, the new gdm version relies on 
systemd's dynamic user creation feature, so it does need some package 
that it can depend on that will have the meaning "dynamic users work as 
intended".

(I don't know why specifically gdm needs the greeter user to be 
available in the shadow "database", but apparently it does. According to 
the equivalent Ubuntu bug 
https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/2121017, 
passwd/group/shadow is enough and gshadow is not strictly required, 
which makes sense because all dynamic gdm greeter users are members of 
one statically-allocated group.)

The ideal solution would be for glibc to support a nsswitch.conf.d 
(https://bugzilla.suse.com/show_bug.cgi?id=1215487) but there doesn't 
seem to be an upstream feature request or implementation for that in 
glibc yet.

The workaround that Ubuntu has used for their upcoming 25.10 release is 
to patch their libnss-systemd so that it removes prior configuration in 
its preinst during upgrades, and also creates the flag file that makes 
the upgrade appear to be a new installation of libnss-systemd, so that 
the postinst will redo the nss_systemd configuration, this time using 
the current setup. This seems non-ideal, but perhaps not the worst thing 
either.

Or perhaps libnss-systemd's maintainer scripts (or even gdm's maintainer 
scripts?) could add code in some new version V that does a one-time 
migration step, ensuring that systemd is present in all relevant 
"databases" (notably including shadow) in upgrades from version (<< V) 
to (>= V)?

If we can't solve this in libnss-systemd or an adjacent package, perhaps 
a possible mitigation would be to teach gdm to go back to using the 
statically-allocated Debian-gdm user for local logins on seat0, so that 
it's only completely reliant on systemd dynamic users for remote and 
multi-seat use-cases? Or perhaps it could detect (somehow) that the 
dynamic user is unusable, and fall back to Debian-gdm in that situation?

Comments in daemon/gdm-dynamic-user-store.c suggest that maybe we could 
behave as though we were a non-systemd distro like Devuan, disable 
systemd-userdb support in gdm, and preallocate "enough" user IDs, 
"gdm-greeter", "gdm-greeter-2", "gdm-greeter-3" and so on. But that 
doesn't seem great: there's no point in having all these nice features 
in systemd if we can't use them.

Maybe a possible route would be to teach gdm to fall back from the 
userdb code path to the static allocation code path at runtime, rather 
than just at build-time, and then statically allocate a single greeter 
user, "gdm-greeter", to make at least local logins work as expected?

We can't just not upgrade gdm3, because the new gnome-session Breaks older 
versions due to some restructuring. Similarly we can't not upgrade 
gnome-session, because the new gnome-shell Breaks it. I think we also 
can't completely revert gdm3's use of systemd's dynamic users, because one 
of the reasons cited for using those was that they were what allowed 
gnome-session's built-in not-very-good service manager to be replaced by 
relying on `systemd --user`.

     smcv