On Thu, 2012-05-10 at 18:59 -0400, Braden McDaniel wrote:
> I'll start out by saying that I don't know if sssd is the culprit in my
> problem or not; but if not, I hope someone here with more knowledge of
> the moving parts at play can point me in the right direction.
> 
> I have two machines: one with Fedora 16 and one with the Fedora 17
> prerelease.  I had initially created a posixGroup in LDAP for mock with
> GID 990.  But then I realized that my two installations had different
> GIDs for the mock group.  So, I decided to change the GID in LDAP and on
> the Fedora 16 box to match the GID for mock on the Fedora 17
> installation (989).  The Fedora 16 box seems to be just fine.  However,
> the Fedora 17 box still seems to think that my user is a member of the
> group with GID 990 (which happens to be pulse-access):
> 
>         $ groups
>         users desktop_admin_r ccache pulse-access
> 
>         $ getent group | grep mock
>         mock:x:989:
>         $ getent group | grep 990
>         pulse-access:x:990:
> 
> At this point, *there is no group in LDAP with GID 990*:
> 
>         $ ldapsearch -x -H ldap://ldap.endoframe.net -D 
> "cn=Manager,dc=endoframe,dc=net" -W "objectClass=posixGroup"
>         Enter LDAP Password: 
>         # extended LDIF
>         #
>         # LDAPv3
>         # base <dc=endoframe,dc=net> (default) with scope subtree
>         # filter: objectClass=posixGroup
>         # requesting: ALL
>         #
>         
>         # users, Groups, endoframe.net
>         dn: cn=users,ou=Groups,dc=endoframe,dc=net
>         objectClass: top
>         objectClass: posixGroup
>         cn: users
>         gidNumber: 100
>         memberUid: braden
>         
>         # ccache, Groups, endoframe.net
>         dn: cn=ccache,ou=Groups,dc=endoframe,dc=net
>         objectClass: top
>         objectClass: posixGroup
>         cn: ccache
>         gidNumber: 988
>         memberUid: braden
>         
>         # desktop_admin_r, Groups, endoframe.net
>         dn: cn=desktop_admin_r,ou=Groups,dc=endoframe,dc=net
>         objectClass: top
>         objectClass: posixGroup
>         gidNumber: 497
>         cn: desktop_admin_r
>         memberUid: braden
>         
>         # desktop_user_r, Groups, endoframe.net
>         dn: cn=desktop_user_r,ou=Groups,dc=endoframe,dc=net
>         objectClass: top
>         objectClass: posixGroup
>         gidNumber: 496
>         cn: desktop_user_r
>         
>         # mock, Groups, endoframe.net
>         dn: cn=mock,ou=Groups,dc=endoframe,dc=net
>         objectClass: top
>         objectClass: posixGroup
>         cn: mock
>         gidNumber: 989
>         memberUid: braden
>         
>         # search result
>         search: 2
>         result: 0 Success
>         
>         # numResponses: 6
>         # numEntries: 5
>         
> And here's the really goofy bit (from my perspective): if I remove
> braden from the LDAP mock group, "groups" output no longer lists
> "pulse-access"; if I add braden back to the LDAP mock group, "groups"
> lists "pulse-access" once again.
> 
> It seems (to me) like something has cached the association of the LDAP
> mock group with GID 990; and now the group *name* is being got from
> LDAP, associated with the old GID, and that old GID is being conveyed to
> tools that (rightfully) associate GID 990 with the local pulse-access
> group.
> 
> Can anyone shed some light on what might be happening here?
> 


The two most likely answers are: 1) the mock group is listed
in /etc/group, which always overrides SSSD or 2) You are running nscd,
which provides its own cache that gets in the way of SSSD.

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/sssd-devel

Reply via email to