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
