probably not a huge deal, but bigger implications [LWN.net]

probably not a huge deal, but bigger implications

Posted Jun 24, 2025 6:35 UTC (Tue) by joib (subscriber, #8541)
In reply to: probably not a huge deal, but bigger implications by mjg59
Parent article: GNOME deepens systemd dependencies

There was also some effort by the sssd people some years ago to provide a dbus service to query also local users in some unified way and provide more info than possible with NSS&PAM, but seems it never went anywhere and support was eventually ripped out from the codebase.

So now systemd is trying the same. Will it allow some unification and simplification, or the opposite if applications will need to support that in addition to classical NSS&PAM along with some ad-hoc kludge to provide more info if necessary, and the sssd thing if that was ever supported? I guess one can only try and hope it gains more or less universal adoption, but there's a risk this will just increase complexity rather than reduce it.

to post comments

probably not a huge deal, but bigger implications

Posted Jun 24, 2025 7:43 UTC (Tue) by smurf (subscriber, #17840) [Link]

> provide a dbus service

The problem with dbus is (a) its access rights model, which is surprisingly complex and a source of subtle security errors, (b) libdbus isn't exactly easy to integrate, (c) hey now your passwords pass through yet another daemon what could possibly go wrong.

systemd has a plugin for PAM, so your the legacy(-ish) tooling will continue to work. The other way 'round, there's the io.systemd.Machine provider.

probably not a huge deal, but bigger implications

Posted Jun 24, 2025 14:20 UTC (Tue) by rjones (guest, #159862) [Link] (2 responses)

I've always just used 'getent' to look up users and groups.

This leverages nss and thus works regardless of what service is sourcing the id numbers for these things. This includes the systemd dynamic uids, which is also exposed via nss with the nss-systemd module.

Cat your /etc/nsswitch.conf to confirm. You should see 'systemd' listed there after files, etc

I don't think there is anything special that applications need to do to support anything at this point. Even if /etc/passwd was to magically disappear.

probably not a huge deal, but bigger implications

Posted Jun 24, 2025 14:53 UTC (Tue) by joib (subscriber, #8541) [Link] (1 responses)

NSS, despite its architectural shortcomings, roughly does what it was designed for, and support for it is indeed near universal, from things like getent to the various user/group querying APIs in libc that applications use to look up info.

Problem here seems to be a desire to associate additional info to a user, not possible in the NSS data model. Like a picture of the user, email address, fully qualified username (name@DOMAIN), etc. Sssd having a go at this failed, remains to be seen whether the systemd approach will turn out to be more successful.

probably not a huge deal, but bigger implications

Posted Jun 25, 2025 11:07 UTC (Wed) by rjones (guest, #159862) [Link]

Oh, well that make sense.

Took a quick look at JSON Group Record and JSON User record from Systemd's documentation it all seems very reasonable and not any different then what people have already been doing for decades with LDAP.

It would be nice to have a nice way for users to set their picture, email address, timezone, default language, security keys, etc. in a saner manner. None of that seems crazy or undesirable.

And since systemd-userdb provides support for multiple backends then it can provide a unified interface for retrieving and interacting with LDAP and other sources of user information people already use and rely on while systemd-homed provides feature parity for people not using any of those services.

If it all works out then it should represent a nice improvement and simplification of the OS over the status quo.