On Tue, May 27, 2025 at 12:50 PM Pramod V U via devel
<devel@lists.fedoraproject.org> wrote:
>
> I am extremely sorry if I am posting to the wrong mailing list, kindly point
> that out to me if that's the case.
>
> I'll be referring to /etc/{passwd,group,shadow,gshadow} as "legacy file
> bundle" or "legacy bundle" or "legacy file(s)"
>
> systemd-userdbd.service is a service included in systemd, which:
> - Dynamically creates records for "root" and "nobody" users, and these
> needn't be in any of legacy files.
> - Reads drop-ins from {/usr/lib,/etc}/userdb for "static" user and group
> records with pre-defined ids (for now). This is appropriate for most of the
> system users.
> - Under /run/systemd/userdb, each provider of users and groups will provide a
> varlink socket with a standard interface for querying for users and groups.
> - All references to users and groups regarding membership of users into
> groups, whenever/if a user/group doesn't exist in any of the providers, is
> silently ignored.
> - One of the services is meant as a compatibility mechanism for glibc NSS
> modules.
> - nss-systemd is a module which looks up user and group records via
> systemd-userdbd.service interfaces.
> - Care is taken to avoid recursion between nss-systemd and the glibc
> compatibility hook.
> - Drop-ins are supported to incrementally modify a user/group record (For
> example add user "root" to groups without overriding systemd-userdbd's
> records).
>
> For human users like you and me, there is systemd-homed.service
> - It exposes the human users via systemd-userdbd.service interfaces.
> - It supports many conveniences like per-user encryption (not openable just
> with root)
> - It is (almost) portable across systems.
> - Much more
> - Although minor SElinux issues exist...
>
> The only thing I know which still uses the legacy bundle is systemd-sysusers,
> it's random UID/GID allocation. It could use /etc/userdb or (preferably)
> another /var/lib/systemd/userdb where sysusers will put the systemd-userdb
> records (and remove them when sysusers.d entries are removed).
>
> These tools overcome the problems of the legacy file bundle. (For example, on
> fedora atomic desktops, the legacy file bundle is under /usr/lib instead of
> /etc for packaged users and groups, in order to facilitate a hermetic /usr,
> and then adding yourself to groups like incus or libvirt needs you to copy
> the group line to the /etc bundle. This isn't an issue fo systemd-homed
> users, where the record is dynamically synthesized and the user is in the
> correct group.)
>
> In conclusion, the systemd suite contains tools to improve user and group
> management. With the exception of systemd-sysusers, everything can replace
> the legacy file bundle with a more modern suite of integrated and extensible
> tools.
The usage of the systemd user management suite has been discussed many
times over the past several years. Unfortunately, it has been designed
in such a way that it is impossible to square with central login
services (like AD/IPA/krb5 logins).
Without a way to handle centralized login, we cannot consider any of
it. On both Fedora KDE and Fedora Workstation, there are requirements
to support GWS/Entra ID and AD/FreeIPA-based logins with local user
storage. We discussed this in the Workstation WG several years ago[1]
and it was even discussed here in devel@ last year[2] (with an LWN
article to summarize it[3]).
Right now, it's dead in the water without being able to handle the
use-cases we need. So, we're likely to stick with the "legacy"
file-based backend as our default until that situation is resolved.
[1]: https://pagure.io/fedora-workstation/issue/82
[2]:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/5TAHXMX4CJJHKSBM4XN73JG7SVGPR7WV/
[3]: https://lwn.net/Articles/995915/
--
真実はいつも一つ！/ Always, there's only one truth!
--
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
