[SSSD] sss_cache --everything

Jakub Hrozek jhrozek at redhat.com
Thu Aug 8 07:51:25 UTC 2013


On Thu, Aug 08, 2013 at 09:04:37AM +0200, steve wrote:
> On Thu, 2013-08-08 at 00:15 +0200, Jakub Hrozek wrote:
> > On Wed, Aug 07, 2013 at 05:25:08PM +0200, steve wrote:
> > > On Wed, 2013-08-07 at 08:07 -0400, Stephen Gallagher wrote:
> > > > On 08/07/2013 07:48 AM, steve wrote:
> > > > > On Wed, 2013-08-07 at 13:17 +0200, Jakub Hrozek wrote:
> > > > >>> 
> > > > >> 
> > > > >> What kind of script?
> > > > > 
> > > > > #!/bin/bash systemctl stop sssd rm /usr/local/var/lib/sss/db/* 
> > > > > systemctl start sssd
> > > > > 
> > > > 
> > > > It's worth noting that sss_cache does not *delete* the cache contents,
> > > > it only marks them all as expired. This means you don't lose cached
> > > > credentials and if your LDAP server isn't available to repopulate the
> > > > cache, you still have access to the old, expired data until it is.
> > > > 
> > > 
> > > Hi
> > > OK, maybe I should explain our frustration. A college where students
> > > come and go and change courses. This involves changes in AD. Just
> > > something to say e.g. student1 has left or change his group from course1
> > > to course2 or remove him from that course or group. Something like
> > > turning off nscd when you run nss-ldapd. Imagine doing it for a whole
> > > class as and when the student returns, a bit at a time. We don't want
> > > old expired data. At the end of the class neither we nor the student
> > > have any need for it.
> > > Cheers
> > 
> > And if you ran sss_cache -UG instead, would that still give you wrong data?
> 
> Yes. -UG is not enough:
> 
> Here is an AD group with one member:
> 
> ldbsearch --url=/usr/local/samba/private/sam.ldb cn=staff2
> # record 1
> dn: CN=staff2,CN=Users,DC=hh3,DC=site
> cn: staff2
> instanceType: 4
> whenCreated: 20130605160553.0Z
> uSNCreated: 3922
> name: staff2
> objectGUID: 6ce9797b-96db-4e70-97ca-e1a2d8d0b3d1
> objectSid: S-1-5-21-451355595-2219208293-2714859210-1111
> sAMAccountName: staff2
> sAMAccountType: 268435456
> groupType: -2147483646
> objectCategory: CN=Group,CN=Schema,CN=Configuration,DC=hh3,DC=site
> objectClass: top
> objectClass: posixGroup
> objectClass: group
> gidNumber: 21111
> member: CN=steve2,CN=Users,DC=hh3,DC=site
> whenChanged: 20130808065259.0Z
> uSNChanged: 5758
> 
> Here is sssd showing the member:
> 
> hh16:/home/steve # getent group staff2
> staff2:*:21111:steve2
> 
> We remove the member from the group:
> hh16:/home/steve # samba-tool group removemembers staff2 steve2
> Removed members from group staff2
> 
> Here is the group with steve2 removed:
> 
>  ldbsearch --url=/usr/local/samba/private/sam.ldb cn=staff2
> # record 1
> dn: CN=staff2,CN=Users,DC=hh3,DC=site
> cn: staff2
> instanceType: 4
> whenCreated: 20130605160553.0Z
> uSNCreated: 3922
> name: staff2
> objectGUID: 6ce9797b-96db-4e70-97ca-e1a2d8d0b3d1
> objectSid: S-1-5-21-451355595-2219208293-2714859210-1111
> sAMAccountName: staff2
> sAMAccountType: 268435456
> groupType: -2147483646
> objectCategory: CN=Group,CN=Schema,CN=Configuration,DC=hh3,DC=site
> objectClass: top
> objectClass: posixGroup
> objectClass: group
> gidNumber: 21111
> whenChanged: 20130808064630.0Z
> uSNChanged: 5757
> 
> sssd_cache -UG still shows steve2 as a member:
> 
> hh16:/home/steve # sss_cache -UG
> hh16:/home/steve # systemctl restart sssd
> hh16:/home/steve # getent group staff2
> staff2:*:21111:steve2
> 
> The only way this works is to remove the contents
> of /usr/local/var/lib/sss/db/ and restart sssd.
> Thanks

This sounds to me like a bug. Even without the restart the sequence of:

sss_cache -UG
getent group staff2

Is suposed to fetch the new group memberships. You're running a custom
build, right? Can you please try applying commits
9615f4c3c6f6dcc50ee7d4e50020549a2ff720c0 and
f7aef1e3ca5bdcddb6fb7c7e6556315faa96165d ?

Those landed yesterday and might fix the problem for you..



More information about the sssd-devel mailing list