Hi,
I have my user account listed in both /etc/passwd, /etc/shadow and the LDAP tree. However, only the LDAP tree has the supplementary group list info.
In sssd-1.8.3 and earlier, issuing `getent passwd jengelh` would return me all the (primary and) secondary groups I am a mamber of. Something like
uid=25121(jengelh) gid=100(users) groups=100(users),399(abuild),56485(friends), 27072(netitwork),31327(rdesktop)
In sssd-1.8.93, this is no longer the case, and instead I get:
uid=25121(jengelh) gid=100(users) groups=100(users),33(video)
`getent group 31327` has to say:
rdesktop:*:31327:fz,mm,mk
`ldapsearch -x cn=rdesktop`:
dn: cn=rdesktop,ou=groups,o=borg objectClass: posixGroup objectClass: top objectClass: groupOfNames objectClass: sambaGroupMapping objectClass: zarafa-group cn: rdesktop description: Remote Desktop Users member: uid=jengelh,ou=users,o=company member: uid=fz,ou=users,o=company member: uid=mm,ou=users,o=company member: uid=mk,ou=users,o=company sambaGroupType: 2 displayName: Remote Desktop gidNumber: 31327 zarafaHidden: 1 sambaSID: S-1-5-21-2434340325-2384729352-2357823451-12387
If I comment about my entry in /etc/passwd, I do receive the groups from LDAP again, but naturally I am missing out on the local groups:
uid=25121(jengelh) gid=27072(netitwork) groups=27072(netitwork),33(video),56485(friends), 31327(rdesktop),399(abuild)
It seems like if the user entry is satisfiable from /etc/passwd, group lookup is also only limited to passwd. This breaks with behavior of all previously seen implementations (pam_ldap,..) which strictly separated user and group lookups like NSS's design set forth a handful of decades ago.
Side-note supplement:
And then there is the cache coming into play, which provided for a handful of surprises on its own. Removing the comment hash mark # from my entry in /etc/passwd again after the previous lookup, I then get *all* memberships from both local and LDAP:
uid=25121(jengelh) gid=100(users) groups=100(users),33(video),56485(friends),31327(rdesktop), 27072(netitwork),399(abuild)
so the look-in-passwd-only "misfeature" is not even consistent :)
On Fri, 2012-06-29 at 20:47 +0200, Jan Engelhardt wrote:
Hi,
I have my user account listed in both /etc/passwd, /etc/shadow and the LDAP tree. However, only the LDAP tree has the supplementary group list info.
In sssd-1.8.3 and earlier, issuing `getent passwd jengelh` would return me all the (primary and) secondary groups I am a mamber of. Something like
uid=25121(jengelh) gid=100(users) groups=100(users),399(abuild),56485(friends), 27072(netitwork),31327(rdesktop)
In sssd-1.8.93, this is no longer the case, and instead I get:
uid=25121(jengelh) gid=100(users) groups=100(users),33(video)
`getent group 31327` has to say:
rdesktop:*:31327:fz,mm,mk
`ldapsearch -x cn=rdesktop`:
dn: cn=rdesktop,ou=groups,o=borg objectClass: posixGroup objectClass: top objectClass: groupOfNames objectClass: sambaGroupMapping objectClass: zarafa-group cn: rdesktop description: Remote Desktop Users member: uid=jengelh,ou=users,o=company member: uid=fz,ou=users,o=company member: uid=mm,ou=users,o=company member: uid=mk,ou=users,o=company sambaGroupType: 2 displayName: Remote Desktop gidNumber: 31327 zarafaHidden: 1 sambaSID: S-1-5-21-2434340325-2384729352-2357823451-12387
If I comment about my entry in /etc/passwd, I do receive the groups from LDAP again, but naturally I am missing out on the local groups:
uid=25121(jengelh) gid=27072(netitwork) groups=27072(netitwork),33(video),56485(friends), 31327(rdesktop),399(abuild)
It seems like if the user entry is satisfiable from /etc/passwd, group lookup is also only limited to passwd. This breaks with behavior of all previously seen implementations (pam_ldap,..) which strictly separated user and group lookups like NSS's design set forth a handful of decades ago.
Side-note supplement:
And then there is the cache coming into play, which provided for a handful of surprises on its own. Removing the comment hash mark # from my entry in /etc/passwd again after the previous lookup, I then get *all* memberships from both local and LDAP:
uid=25121(jengelh) gid=100(users) groups=100(users),33(video),56485(friends),31327(rdesktop), 27072(netitwork),399(abuild)
so the look-in-passwd-only "misfeature" is not even consistent :)
Remove the "initgroups: " line from /etc/nsswitch.conf, then try the above commands again.
The Glibc people decided to push an interface break out the door without giving anyone a heads-up. The default behavior of initgroups() has changed to matching the first entry in the initgroups: line that has results, instead of the old behavior of checking every entry in the line.
See https://bugzilla.redhat.com/show_bug.cgi?id=835612 for more details.
On Tuesday 2012-07-03 13:58, Stephen Gallagher wrote:
In sssd-1.8.3 and earlier, issuing `getent passwd jengelh` would return me all the (primary and) secondary groups I am a mamber of. Something like uid=25121(jengelh) gid=100(users) groups=100(users),399(abuild),56485(friends), 27072(netitwork),31327(rdesktop)
In sssd-1.8.93, this is no longer the case, and instead I get: uid=25121(jengelh) gid=100(users) groups=100(users),33(video)
`getent group 31327` has to say: rdesktop:*:31327:fz,mm,mk
`ldapsearch -x cn=rdesktop`: [...] member: uid=jengelh,ou=users,o=company
Remove the "initgroups: " line from /etc/nsswitch.conf, then try the above commands again.
The version I am on uses glibc-2.15-725b8ee08aff.tar.xz as source. This tarball ships an nsswitch.conf with the questionable initgroups: line in its default nsswitch.conf (so I am in fact on a susceptible version). However, openSUSE never ships that and instead its own nsswitch.conf, so I never have had any initgroups: line and don't do so to this day. So all commands I executed already were without initgroups:.
On Tue, 2012-07-03 at 14:17 +0200, Jan Engelhardt wrote:
On Tuesday 2012-07-03 13:58, Stephen Gallagher wrote:
In sssd-1.8.3 and earlier, issuing `getent passwd jengelh` would return me all the (primary and) secondary groups I am a mamber of. Something like uid=25121(jengelh) gid=100(users) groups=100(users),399(abuild),56485(friends), 27072(netitwork),31327(rdesktop)
In sssd-1.8.93, this is no longer the case, and instead I get: uid=25121(jengelh) gid=100(users) groups=100(users),33(video)
`getent group 31327` has to say: rdesktop:*:31327:fz,mm,mk
`ldapsearch -x cn=rdesktop`: [...] member: uid=jengelh,ou=users,o=company
Remove the "initgroups: " line from /etc/nsswitch.conf, then try the above commands again.
The version I am on uses glibc-2.15-725b8ee08aff.tar.xz as source. This tarball ships an nsswitch.conf with the questionable initgroups: line in its default nsswitch.conf (so I am in fact on a susceptible version). However, openSUSE never ships that and instead its own nsswitch.conf, so I never have had any initgroups: line and don't do so to this day. So all commands I executed already were without initgroups:.
Just to rule out the possibility that openSUSE's internal default was modified to behave the way the new initgroups line does, can you set
initgroups: files [SUCCESS=continue] sss
explicitly and try that?
On Tuesday 2012-07-03 14:20, Stephen Gallagher wrote:
The version I am on uses glibc-2.15-725b8ee08aff.tar.xz as source. This tarball ships an nsswitch.conf with the questionable initgroups: line in its default nsswitch.conf (so I am in fact on a susceptible version). However, openSUSE never ships that and instead its own nsswitch.conf, so I never have had any initgroups: line and don't do so to this day. So all commands I executed already were without initgroups:.
Just to rule out the possibility that openSUSE's internal default was modified to behave the way the new initgroups line does, can you set
initgroups: files [SUCCESS=continue] sss
explicitly and try that?
Sigh. sssd problems are so hard to reproducible.
v-sfac:/home/jengelh # rm -Rf /var/lib/sss/{db,mc}/*; rcsssd restart redirecting to systemctl v-sfac:/home/jengelh # id jengelh uid=25121(jengelh) gid=100(users) groups=100(users),33(video) v-sfac:/home/jengelh # getent group 31327 rdesktop:*:31327:jengelh,fzapf,mmaus,mkromer (^ jengelh was not part of 31327 before...) v-sfac:/home/jengelh # id jengelh uid=25121(jengelh) gid=100(users) groups=100(users),33(video)
After adding the nsswitch.conf line:
v-sfac:/home/jengelh # rm -Rf /var/lib/sss/{db,mc}/*; rcsssd restart redirecting to systemctl v-sfac:/home/jengelh # id jengelh uid=25121(jengelh) gid=100(users) groups=100(users),33(video) v-sfac:/home/jengelh # getent group 31327 rdesktop:*:31327:jengelh,fzapf,mmaus,mkromer v-sfac:/home/jengelh # id jengelh uid=25121(jengelh) gid=100(users) groups=100(users),33(video),31327(rdesktop)
On Tue, 2012-07-03 at 23:56 +0200, Jan Engelhardt wrote:
On Tuesday 2012-07-03 14:20, Stephen Gallagher wrote:
The version I am on uses glibc-2.15-725b8ee08aff.tar.xz as source. This tarball ships an nsswitch.conf with the questionable initgroups: line in its default nsswitch.conf (so I am in fact on a susceptible version). However, openSUSE never ships that and instead its own nsswitch.conf, so I never have had any initgroups: line and don't do so to this day. So all commands I executed already were without initgroups:.
Just to rule out the possibility that openSUSE's internal default was modified to behave the way the new initgroups line does, can you set
initgroups: files [SUCCESS=continue] sss
explicitly and try that?
Sigh. sssd problems are so hard to reproducible.
v-sfac:/home/jengelh # rm -Rf /var/lib/sss/{db,mc}/*; rcsssd restart redirecting to systemctl v-sfac:/home/jengelh # id jengelh uid=25121(jengelh) gid=100(users) groups=100(users),33(video) v-sfac:/home/jengelh # getent group 31327 rdesktop:*:31327:jengelh,fzapf,mmaus,mkromer (^ jengelh was not part of 31327 before...) v-sfac:/home/jengelh # id jengelh uid=25121(jengelh) gid=100(users) groups=100(users),33(video)
After adding the nsswitch.conf line:
v-sfac:/home/jengelh # rm -Rf /var/lib/sss/{db,mc}/*; rcsssd restart redirecting to systemctl v-sfac:/home/jengelh # id jengelh uid=25121(jengelh) gid=100(users) groups=100(users),33(video) v-sfac:/home/jengelh # getent group 31327 rdesktop:*:31327:jengelh,fzapf,mmaus,mkromer v-sfac:/home/jengelh # id jengelh uid=25121(jengelh) gid=100(users) groups=100(users),33(video),31327(rdesktop)
Hmm, looks like something might be up with the nested group processing of RFC2307bis servers. There was only one patch in 1.8.4 that touched nested processing[1], so that should narrow down the search.
Can you please do the following?
1) Add debug_level = 8 to the [domain/DOMAINNAME] section of sssd 2) rm -Rf /var/lib/sss/{db,mc}/*; rcsssd restart 3) id -G jengelh 4) Send us the (sanitized if needed) /var/log/sssd/sssd_DOMAINNAME.log of that 'id -G' (please use the -G, otherwise the log will be full of group lookups as well, and what's happening here appears to be related only to initgroups())
[1] LDAP nested groups: Do not process callback with _post deep in the nested structure - 6efb62b8b94405cfd0afecbf2d04985b6f44419b - https://fedorahosted.org/sssd/ticket/1343
sssd-devel@lists.fedorahosted.org
-
Jan Engelhardt -
Stephen Gallagher