> 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?
I guess SSSD cache is probably the reason why you still have the old GID. Try running sss_cache -G to invalidate all groups and if you have queried SSSD for that group in last few minutes, wait for the client in-memory cache to expire as well (or you can just restart SSSD). HTH Jan
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
