On Срд, 28 мая 2025, Lennart Poettering wrote:
On Mi, 28.05.25 16:51, Alexander Bokovoy (aboko...@redhat.com) wrote:
> > socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 4
> > connect(4, {sa_family=AF_UNIX,
sun_path="/run/systemd/userdb/io.systemd.DynamicUser"}, 45) = 0
> > socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 7
> > connect(7, {sa_family=AF_UNIX,
sun_path="/run/systemd/userdb/io.systemd.NamespaceResource"}, 51) = 0
> > socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 8
> > connect(8, {sa_family=AF_UNIX,
sun_path="/run/systemd/userdb/io.systemd.DropIn"}, 40) = 0
> > socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 9
> > connect(9, {sa_family=AF_UNIX,
sun_path="/run/systemd/userdb/io.systemd.Home"}, 38) = 0
> > socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 10
> > connect(10, {sa_family=AF_UNIX,
sun_path="/run/systemd/userdb/io.systemd.Machine"}, 41) = 0
>
> Note sure I follow? This trace shows only systemd's own five userdb
> implementations, none provided by sssd? And you used "-s systemd" on
> the getent cmdline, hence you prohibit NSS to ever query anything else
> but systemd's userdb.
I limited communication to what is not working.
>
> hence of course you are not getting any sssd records, because you
> don't have the userdb socket for it around, and you don't want the NSS
> logic to talk to anything but userbd either?
I think you are missing my point, indeed. What I am trying to say is that
$ userdbctl groups-of-user --with-dropin=yes --multiplexer=yes --with-nss=yes
abokovoy
No memberships.
is not expected behavior.
So are that "abokovoy" user, by what is it backed? by a native userdb
service? or by NSS?
NSS.
I presume this has a native userdb api, because that's what we are
talking about here, no? Is that API implementing GetMemberships()
properly? What does "strace -s500 -y" of "userdbctl groups-of-user
--multiplexer=no abokovoy" actually show?
Group memberships of a user coming from an NSS source that is not
nss_files seems to be handled incorrectly by the userdb API
implementation in systemd.
It is reproducible very easily with nss_sss on a system enrolled into an
enterprise domain like FreeIPA or Samba AD.
You can test that trivially on a systemd-enabled Fedora container, for
example. Here is a simple instruction with FreeIPA server and client as
such podman containers:
https://github.com/freeipa/freeipa-local-tests/tree/main/ipalab-config/minimal
But it will work the same way for any setup where you'd enroll a client
system into a centrally managed environment and use nss_sss or any other
NSS module that does retrieval of remote identities.
In FreeIPA case you have 'admin' user pre-created in the central system
and it will be visible through SSSD (nss_sss/pam_sss) on the enrolled
system. It will not exist on the system otherwise, e.g. in /etc/passwd
or similar.
E.g. `id admin` would give you some result while `userdbctl
groups-of-user admin' will fail.
The output below is from an ephemeral environment I created using the
above instructions:
# id admin
uid=61000(admin) gid=61000(admins) groups=61000(admins)
# userdbctl user admin
User name: admin
Disposition: regular
Login OK: yes
Password OK: no (none set)
UID: 61000
GID: 61000 (admins)
Real Name: Administrator
Directory: /home/admin
Storage: classic
Shell: /bin/bash
Passwords: none
Service: io.systemd.NameServiceSwitch
Self Modify: realName
emailAddress
iconName
location
shell
umask
environment
timeZone
preferredLanguage
additionalLanguages
preferredSessionLauncher
preferredSessionType
pkcs11TokenUri
fido2HmacCredential
recoveryKeyType
lastChangeUSec
lastPasswordChangeUSec
(Blobs) avatar
login-background
(Privileged) passwordHint
hashedPassword
pkcs11EncryptedKey
fido2HmacSalt
recoveryKey
sshAuthorizedKeys
# userdbctl group admins
Group name: admins
Disposition: regular
GID: 61000
Members: admin
Service: io.systemd.NameServiceSwitch
# userdbctl groups-of-user admin
No memberships.
This behavior exists for years. It would be great if you'd fix this.
Sure, we'll work on making possible to expose SSSD-provided information
over userdb API natively, but we need to start with something compatible
to existing code first.
Regardless what I try, userdbctl cannot see groups that I otherwise a
member of via user lookup. This makes userdb API useless in the context
I have and I want to understand what is not working here. Are you
implying that something is incorrect in my usage of userdb API?
I still do not understand what your setup actually is, i.e. whether
the issue you are seeing is supposedly an issue with the synthesis of
userdb records from NSS records and your service only provides NSS, or
if your service implements the native userdb stuff and the memberships
are not listed properly.
See above. My understanding is that a group membership (initgroups?)
handling in systemd's NSS synthesizing code in userdb has a bug. Perhaps
this is in the code that attempts to prevent a recursion between NSS
iteration and nss_systemd, I don't know. I tried to investigate it
myself but had to drop this idea and worked on making it is easier for
you to have a repeatable reproducer that can be plugged into a github
actions run so that systemd project could test it -- that's why we neded
up with the project referenced above.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
_______________________________________________
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
