On Срд, 28 мая 2025, Lennart Poettering wrote:
On Mi, 28.05.25 09:43, Alexander Bokovoy (aboko...@redhat.com) wrote:
On Аўт, 27 мая 2025, Lennart Poettering wrote:
> On Di, 27.05.25 14:32, Neal Gompa (ngomp...@gmail.com) wrote:
>
> > 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).
>
> systemd-userdbd and systemd-homed are two distinct things. Do not mix
> them up.
>
> samba merged supprt for the former 3 months ago:
>
> https://gitlab.com/samba-team/samba/-/merge_requests/2928
We currently do not plan to use that in real deployments, though. There
are few issues with userdb API implementation. For example, there is an
assumption only one responder knows the information about the account
being requested. In real deployments we have to do group membership
merges across multiple nss backends. userdb right now fails to provide a
complete group membership for FreeIPA users, for example. This is not
unique to FreeIPA, though, it would do the same for any non-static
backend in a default configuration.
That's a misunderstanding. userdb user/group memberships are
implemented via the GetMemberships() IPC call, and *of* *course* it's
assumed that multiple backends provide these, and the results of all
backends are combined. After all, it's pretty much the default case
that a regular user for example managed by homed, is part of a
system-specific group (such as "wheel") which is managed via
/etc/passwd.
In fact, it's even possible to put together a userdb backend that
doesn't provide any user or group records, but does provide membership
relationships for users of other backends.
When doing NSS emulation nss-systemd understands this: when returning
a group record it will combine a specific userdb group record from one
backend with the results of a matching GetMemberships() of *all*
backends and return that as one "struct group" NSS record. Or in other
words: .gr_name, .gr_passwd, .gr_gid are initialized from the group
record JSON object, but .gr_mem is initialized from the combination of
the results of all GetMemberships() IPC calls.
That was my expectation as well, but the result you see in my email is
what I get on Fedora enrolled into IPA.
In addition to that, `getent -s systemd initgroups abokovoy` does not return
any group membership at all:
$ strace -f -s 1024 -e trace=%net getent -s systemd initgroups abokovoy
...
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
sendto(4,
"{\"method\":\"io.systemd.UserDatabase.GetMemberships\",\"parameters\":{\"userName\":\"abokovoy\",\"service\":\"io.systemd.DynamicUser\"},\"more\":true}\0",
136, MSG_DONTWAIT|MSG_NOSIGNAL, NULL, 0) = 136
sendto(7,
"{\"method\":\"io.systemd.UserDatabase.GetMemberships\",\"parameters\":{\"userName\":\"abokovoy\",\"service\":\"io.systemd.NamespaceResource\"},\"more\":true}\0",
142, MSG_DONTWAIT|MSG_NOSIGNAL, NULL, 0) = 142
sendto(9,
"{\"method\":\"io.systemd.UserDatabase.GetMemberships\",\"parameters\":{\"userName\":\"abokovoy\",\"service\":\"io.systemd.Home\"},\"more\":true}\0",
129, MSG_DONTWAIT|MSG_NOSIGNAL, NULL, 0) = 129
recvfrom(4,
"{\"error\":\"io.systemd.UserDatabase.NoRecordFound\",\"parameters\":{}}\0",
135152, MSG_DONTWAIT, NULL, NULL) = 66
recvfrom(7,
"{\"error\":\"io.systemd.UserDatabase.NoRecordFound\",\"parameters\":{}}\0",
131080, MSG_DONTWAIT, NULL, NULL) = 66
recvfrom(9,
"{\"error\":\"io.systemd.UserDatabase.NoRecordFound\",\"parameters\":{}}\0",
131080, MSG_DONTWAIT, NULL, NULL) = 66
sendto(10,
"{\"method\":\"io.systemd.UserDatabase.GetMemberships\",\"parameters\":{\"userName\":\"abokovoy\",\"service\":\"io.systemd.Machine\"},\"more\":true}\0",
132, MSG_DONTWAIT|MSG_NOSIGNAL, NULL, 0) = 132
sendto(8,
"{\"method\":\"io.systemd.UserDatabase.GetMemberships\",\"parameters\":{\"userName\":\"abokovoy\",\"service\":\"io.systemd.DropIn\"},\"more\":true}\0",
131, MSG_DONTWAIT|MSG_NOSIGNAL, NULL, 0) = 131
recvfrom(10,
"{\"error\":\"io.systemd.UserDatabase.NoRecordFound\",\"parameters\":{}}\0",
131080, MSG_DONTWAIT, NULL, NULL) = 66
recvfrom(8,
"{\"error\":\"io.systemd.UserDatabase.NoRecordFound\",\"parameters\":{}}\0",
131080, MSG_DONTWAIT, NULL, NULL) = 66
abokovoy
+++ exited with 0 +++
Compare that with SSSD backend:
...
openat(AT_FDCWD, "/lib64/libnss_sss.so.2", O_RDONLY|O_CLOEXEC) = 3
read(3,
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\0\0\0\0\0\0\0@\0\0\0\0\0\0\0\260\311\0\0\0\0\0\0\0\0\0\0@\08\0\f\0@\0!\0
\0\1\0\0\0\4\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\314\3\0\0\0\0\0\0\314\3\0\0\0\0\0\0\0\20\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\20\0\0\0\0\0\0\0\20\0\0\0\0\0\0\0\20\0\0\0\0\0\0Iw\0\0\0\0\0\0Iw\0\0\0\0\0\0\0\20\0\0\0\0\0\0\1\0\0\0\4\0\0\0\0\220\0\0\0\0\0\0\0\220\0\0\0\0\0\0\0\220\0\0\0\0\0\0x\"\0\0\0\0\0\0x\"\0\0\0\0\0\0\0\20\0\0\0\0\0\0\1\0\0\0\6\0\0\0\240\273\0\0\0\0\0\0\240\313\0\0\0\0\0\0\240\313\0\0\0\0\0\0\240\5\0\0\0\0\0\0\270\6\0\0\0\0\0\0\0\20\0\0\0\0\0\0\2\0\0\0\6\0\0\0\300\273\0\0\0\0\0\0\300\313\0\0\0\0\0\0\300\313\0\0\0\0\0\0@\2\0\0\0\0\0\0@\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0\340\2\0\0\0\0\0\0\340\2\0\0\0\0\0\0\340\2\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0
\3\0\0\0\0\0\0 \3\0\0\0\0\0\0
\3\0\0\0\0\0\0\254\0\0\0\0\0\0\0\254\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0\240\273\0\0\0\0\0\0\240\313\0\0\0\0\0\0\240\313\0\0\0\0\0\0\0\0\0\0\0\0\0\0\270\0\0\0\0\0\0\0\20\0\0\0\0\0\0\0S\345td\4\0\0\0\340\2\0\0\0\0\0\0\340\2\0\0\0\0\0\0\340\2\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\0\0\0\30\245\0\0\0\0\0\0\30\245\0\0\0\0\0\0\30\245\0\0\0\0\0\0\4\2\0\0\0\0\0\0\4\2\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\20\0\0\0\0\0\0\0R\345td\4\0\0\0\240\273\0\0\0\0\0\0\240\313\0\0\0\0\0\0\240\313\0\0\0\0\0\0`\4\0\0\0\0\0\0`\4\0\0\0\0\0\0\1\0\0\0\0\0\0\0\4\0\0\0000\0\0\0\5\0\0\0GNU\0\2\0\0\300\4\0\0\0\3\0\0\0\0\0\0\0\1\0\1\300\4\0\0\0\t\0\0\0\0\0\0\0\2\0\1\300\4\0\0\0\1\0\0\0\0\0\0\0\4\0\0\0\24\0\0\0\3\0\0\0GNU\0w3r\272\334\337\361\31V\250Z\213\244\t@\302",
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=53744, ...}) = 0
mmap(NULL, 53848, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f68bf1d7000
mmap(0x7f68bf1d8000, 32768, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1000) = 0x7f68bf1d8000
mmap(0x7f68bf1e0000, 12288, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3,
0x9000) = 0x7f68bf1e0000
mmap(0x7f68bf1e3000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xb000) = 0x7f68bf1e3000
close(3) = 0
mprotect(0x7f68bf1e3000, 4096, PROT_READ) = 0
munmap(0x7f68bf1e5000, 37031) = 0
openat(AT_FDCWD, "/var/lib/sss/mc/initgroups", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0664, st_size=11567160, ...}) = 0
mmap(NULL, 11567160, PROT_READ, MAP_SHARED, 3, 0) = 0x7f68be200000
fstat(3, {st_mode=S_IFREG|0664, st_size=11567160, ...}) = 0
fstat(3, {st_mode=S_IFREG|0664, st_size=11567160, ...}) = 0
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0), ...}) = 0
write(1, "abokovoy 1792600075 1792600006 1792600007 1792600073 964
1792600000 63 1792600084 1792600077 1792600060 1000\n", 122abokovoy
1792600075 1792600006 1792600007 1792600073 964 1792600000 63 1792600084 1792600077
1792600060 1000
) = 122
exit_group(0) = ?
+++ exited with 0 +++
--
/ 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
