Learn more about these different git repos.
Other Git URLs
https://bugzilla.redhat.com/show_bug.cgi?id=732474
Description of problem: If SSSD configured to use LDAP with rfc2307 and add a local user to the memberUid attribute of an LDAP group, the LDAP group membership is shown by "getent group ldap_group". The local user membership vanishes as soon as the user is being queried through SSSD(eg: id local_user). Version-Release number of selected component (if applicable): sssd-1.5.1-34.el6_1.3.x86_64 How reproducible: Always Steps to Reproduce: 1. Create an LDAP group with memberuid:<local_user> 2. query the group (getent group <ldap_group> getent returns local_user as member of the LDAP group. And the user has been added to local db. ==================== # ldb3search -H /var/lib/sss/db/cache_default.ldb ..... dn: name=local_user,cn=users,cn=default,cn=sysdb createTimestamp: 1314015104 dataExpireTimestamp: 1314015103 lastLogin: 1314015104 lastUpdate: 1314015104 name: local_user objectClass: user memberof: name=ldap-unix,cn=groups,cn=default,cn=sysdb distinguishedName: name=local_user,cn=users,cn=default,cn=sysdb ==================== 3. Query local_user (# id <local_user>) Check group membership again, user <local_user> has been removed from the group. Also local_user entry has been purged from local ldb file. Actual results: # getent group <ldap_group> does not return local users. Expected results: # getent group <ldap_group> return all entries from ldap (including non ldap users added in memberuid attribute).
I'm not sure this is something we can fix and support right now.
Here's what happens:
- getent group <ldap_group> works OK because it primes the LDB cache with fake users and returns the usernames it grabs from memberuid attributes - getent passwd <local_user> works OK because it never gets into nss_sss - however id <local_user> calls getgrouplist() which in turn calls initgroups() in SSSD. The LDAP provider searches for <local_user> in LDAP, finds nothing and deletes the fake user.
As far as SSSD is concerned, there is no difference between "A user was deleted but there is a dangling memberuid" and "the user exists in /etc/passwd". Moreover, this scenario just cannot work with RFC2307bis.
Maybe this could be solved in future when/if SSSD supports sub-domains Sumit proposed some time ago.
coverity: => description: https://bugzilla.redhat.com/show_bug.cgi?id=732474
{{{ Description of problem: If SSSD configured to use LDAP with rfc2307 and add a local user to the memberUid attribute of an LDAP group, the LDAP group membership is shown by "getent group ldap_group". The local user membership vanishes as soon as the user is being queried through SSSD(eg: id local_user).
Version-Release number of selected component (if applicable): sssd-1.5.1-34.el6_1.3.x86_64
How reproducible: Always
Steps to Reproduce:
..... dn: name=local_user,cn=users,cn=default,cn=sysdb createTimestamp: 1314015104 dataExpireTimestamp: 1314015103 lastLogin: 1314015104 lastUpdate: 1314015104 name: local_user objectClass: user memberof: name=ldap-unix,cn=groups,cn=default,cn=sysdb distinguishedName: name=local_user,cn=users,cn=default,cn=sysdb ====================
Check group membership again, user <local_user> has been removed from the group. Also local_user entry has been purged from local ldb file.
Actual results:
Expected results:
}}} => https://bugzilla.redhat.com/show_bug.cgi?id=732474
}}}
patch: => 0 rhbz: => tests: => 0 testsupdated: => 0 upgrade: => 0
Fields changed
rhbz: => 732474
milestone: NEEDS_TRIAGE => SSSD 1.8.0
type: defect => enhancement
rhbz: 732474 => [https://bugzilla.redhat.com/show_bug.cgi?id=732474 732474]
blockedby: => blocking: => milestone: SSSD 1.8.0 => SSSD 1.9.0 NEEDS_TRIAGE
"Nice to have" for 1.9.
milestone: SSSD 1.9.0 NEEDS_TRIAGE => SSSD 1.9.0
feature_milestone: => milestone: SSSD 1.9.0 => SSSD 1.11 beta
The list of groups a user is member of change fonction of :
these are tests that I have executed and that may help to deal with this ticket :
$ grep sss /etc/nsswitch.conf passwd: files sss group: sss files ... $ grep ntp /etc/passwd ntp:x:38:18010::/etc/ntp:/sbin/nologin $ grep ntp /etc/group ntp:x:38:
In ldap I have two groups whose ntp is member of, "sysgroup" and "netgrp". as seen above, sysgroup (gid = 18010 ) is also declared locally as being ntp primary group :
# Entry : cn=sysgroup,ou=group,dc=example,dc=fr dn: cn=sysgroup,ou=group,dc=example,dc=fr cn: sysgroup gidnumber: 18010 memberuid: foo memberuid: ntp objectclass: posixGroup # Entry : cn=netgrp,ou=group,dc=example,dc=fr dn: cn=netgrp,ou=group,dc=example,dc=fr cn: netgrp gidnumber: 18000 memberuid: toto memberuid: ntp objectclass: posixGroup
There is no group "ntp" in ldap.
Command : $ su - ldap -c groups Returns : sysgroup ntp
Note that "netgrp" is not returned
Now if I simply create an ldap user entry for user ntp :
dn: uid=ntp,ou=sysaccount,ou=people,dc=example,dc=fr cn: ldap gidnumber: 18000 homedirectory: /var/lib/ldap objectclass: shadowAccount objectclass: posixAccount objectclass: inetOrgPerson objectclass: organizationalPerson objectclass: person sn: ldap uid: ldap uidnumber: 55 ...
Then secondary groups in ldap are also returned :
Command : $ su - ldap -c groups Returns : sysgroup ntp netgrp
Client OS :
$ cat /etc/issue Red Hat Enterprise Linux Server release 6.2 (Santiago) Kernel \r on an \m $ rpm -qa | grep sssd sssd-1.5.1-66.el6_2.3.x86_64 sssd-client-1.5.1-66.el6_2.3.x86_64
I use openldap2.4
In brieve, the behaviour that would be great IMHO would be : if nsswitch says that sss is the primary source of information for groups, then returns all ldap groups for users, and add the primary group declared locally if the primary group can't be found in ldap.
_comment0: The list of groups a user is member of change fonction of :
$ grep sss /etc/nsswitch.conf
passwd: files sss group: sss files ...
$ grep ntp /etc/passwd ntp:x:38:18010::/etc/ntp:/sbin/nologin
$ grep ntp /etc/group ntp:x:38:
In ldap I have to groups whose ntp is member of, sysgroup and netgroup. as seen above, sysgroup (gid = 18010 ) is also declared locally as being ntp primary group :
dn: cn=sysgroup,ou=group,dc=example,dc=fr cn: sysgroup gidnumber: 18010 memberuid: foo memberuid: ntp objectclass: posixGroup
dn: cn=netgroup,ou=group,dc=example,dc=fr cn: netgroup gidnumber: 18000 memberuid: toto memberuid: ntp objectclass: posixGroup
Command : $ su - ldap -c groups Returns : sysgroup ntp netgroup
$ cat /etc/issue Red Hat Enterprise Linux Server release 6.2 (Santiago) Kernel \r on an \m
$ rpm -qa | grep sssd sssd-1.5.1-66.el6_2.3.x86_64 sssd-client-1.5.1-66.el6_2.3.x86_64
I use openldap2.4 => 1331739978581086 _comment1: The list of groups a user is member of change fonction of :
{{{
$ grep ntp /etc/group ntp:x:38: }}}
dn: cn=netgroup,ou=group,dc=example,dc=fr cn: netgroup gidnumber: 18000 memberuid: toto memberuid: ntp objectclass: posixGroup }}}
{{{ Command : $ su - ldap -c groups Returns : sysgroup ntp }}}
{{{ dn: uid=ntp,ou=sysaccount,ou=people,dc=example,dc=fr cn: ldap gidnumber: 18000 homedirectory: /var/lib/ldap objectclass: shadowAccount objectclass: posixAccount objectclass: inetOrgPerson objectclass: organizationalPerson objectclass: person sn: ldap uid: ldap uidnumber: 55 ... }}}
{{{ Command : $ su - ldap -c groups Returns : sysgroup ntp netgroup
{{{ $ cat /etc/issue Red Hat Enterprise Linux Server release 6.2 (Santiago) Kernel \r on an \m
I use openldap2.4 => 1331740008769265 _comment2: The list of groups a user is member of change fonction of :
In ldap I have two groups whose ntp is member of, sysgroup and netgroup. as seen above, sysgroup (gid = 18010 ) is also declared locally as being ntp primary group :
I use openldap2.4 => 1331740120098751 _comment3: The list of groups a user is member of change fonction of :
dn: cn=netgrp,ou=group,dc=example,dc=fr cn: netgrp gidnumber: 18000 memberuid: toto memberuid: ntp objectclass: posixGroup }}}
{{{ Command : $ su - ldap -c groups Returns : sysgroup ntp netgrp
I use openldap2.4 => 1331740388475205 _comment4: The list of groups a user is member of change fonction of :
== I would expect (and recommend) that all groups whose "ntp" is declared as being a member in ldap would be returned by if the user ntp exists locally, weither or not it exists in ldap. ==
=> 1331740501939987 _comment5: The list of groups a user is member of change fonction of :
== '''I would expect (and recommend) that all groups whose "ntp" is declared as being a member in ldap would be returned if the user ntp exists locally, weither or not ntp exists in ldap.''' ==
=> 1331741919346741 _comment6: The list of groups a user is member of change fonction of :
== '''I would expect (and recommend) that all groups whose "ntp" is declared as being a member in ldap would be returned if the user ntp exists locally, weither or not user ntp exists in ldap.''' ==
In brieve, the behaviour that would be great IMHO me would be : if nsswitch says that sss is the primary source of information for groups, then returns all ldap groups for users, and add the primary group declared locally if the primary group for that user can't be found in ldap.
=> 1331741964854834 _comment7: The list of groups a user is member of change fonction of :
In brieve, the behaviour that would be great IMHO me would be : if nsswitch says that sss is the primary source of information for groups, then returns all ldap groups for users, and add the primary group declared locally if the primary group can't be found in ldap.
=> 1331741992394824
proposed_priority: => Optional
This ticket has been evaluated for inclusion into SSSD 1.10 release and was decided to be excluded since it does not match the main goals and themes of the release. It might be considered for later releases.
Linked to Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=866021 (Red Hat Enterprise Linux 6)
rhbz: [https://bugzilla.redhat.com/show_bug.cgi?id=732474 732474] => [https://bugzilla.redhat.com/show_bug.cgi?id=732474 732474], [https://bugzilla.redhat.com/show_bug.cgi?id=866021 866021]
milestone: SSSD 1.11 beta => SSSD 1.12 beta
design: => design_review: => 0 fedora_test_page: => owner: somebody => simo selected: => status: new => assigned
milestone: SSSD 1.12 beta => NEEDS_TRIAGE
patch: 0 => 1 review: => 0
design: => https://fedorahosted.org/sssd/wiki/DesignDocs/LocalGroupMembersForRFC2307
I'll leave the ticket open until our weekly meeting to decide if we want a sssd-1-9 commit, too.
_comment0: *master: fae99bf
I'll leave the patch open until our weekly meeting to decide if we want a sssd-1-9 commit, too. => 1363797105298620 _comment1: * master: fae99bf
I'll leave the patch open until our weekly meeting to decide if we want a sssd-1-9 commit, too. => 1363797251519077
milestone: NEEDS_TRIAGE => SSSD 1.9.5 resolution: => fixed status: assigned => closed
Metadata Update from @sgallagh: - Issue assigned to simo - Issue set to the milestone: SSSD 1.9.5
SSSD is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in SSSD's github repository.
This issue has been cloned to Github and is available here: - https://github.com/SSSD/sssd/issues/2062
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.