[SSSD] memory cache for initgroups

Jakub Hrozek jhrozek at redhat.com
Mon Nov 3 14:41:43 UTC 2014


On Mon, Nov 03, 2014 at 08:53:06AM -0500, Simo Sorce wrote:
> On Mon, 3 Nov 2014 13:57:08 +0100
> Jakub Hrozek <jhrozek at redhat.com> wrote:
> 
> > Hi,
> > 
> > we had short discussion on $SUBJECT with Simo on IRC already, but
> > there are multiple people involved from multiple timezones, so I
> > think a mailing list thread would be better trackable.
> > 
> > Can we add another memory cache file to SSSD, that would track
> > initgroups/getgrouplist results for the NSS responder? I realize
> > initgroups is a bit different operation than getpw{uid,nam} and
> > getgr{gid,nam} but what if the new memcache was only used by the NSS
> > responder and at the same time invalidated when initgroups is
> > initiated by the PAM responder to ensure the memcache is up-to-date?
> 
> Can you describe the use case before jumping into a proposed solution ?

Many getgrouplist() or initgroups() calls in a quick succession. One
user is GlusterFS -- I'm not quite sure what the reason is there, maybe
Vijay can elaborate.

The other use-case is slapi-nis that calls getgrouplist() -- Alexander
would explain better here, I only know that slapi-nis uses
getgrouplist() during memberUID processing, but I'm fuzzy on the
details.

> 
> > I already know about two projects that would benefit from faster
> > initgroups operation - GlusterFS uses getgrouplist() quite a lot with
> > some setups and also in the IPA server mode, the SSSD running on the
> > server becomes a bit of a bottlenec for some operations.
> 
> Is the problem related to accessing the main ldb cache, or the fact we
> also go out and contact the IdM server ?

Mostly the cache. In particular, with the GlusterFS case, there was a
huge filesystem directory that triggered 4000+ getgrouplist() calls, one
per a file. Even though the getgrouplist() calls were for fewer than 10
users, we would hit LDB every time and that produced quite a load on the
SSSD.

> 
> > Are there any technical reasons against a new memcache file that would
> > cache initgroups?
> 
> The main reason would be potential inconsistency between this cache and
> the users and groups caches, but I do not think that would be really a
> big deal if there is a pretty good reason for the cache.

Hm, I see, then we have the same information duplicated in two caches,
just from a different angle. However, for cases where precision really
matters (access control), we don't use these caches anyway.

Could we mitigate this problem by invalidating the memcache when group
membership changes at all during a backend operation? I think changes to
LDAP object are so rare, that invalidating the memcache (which is quite
shortlived anyway) would be worth it.

> 
> Do we need to insure all groups are resolvable in the groups cache ?

I don't think so, if the group is not in the groups cache, then we just
hit the responder.

> Or is it ok if gids returned by the getgrouplist are not immediately
> available in the groups cache ?
> What about the user ?

I *think* the user could also be left out. If the application also needs
user data, it simply calls getpwnam -- like id(1) does. getgrouplist is
a different interface with different outputs.

> 
> Simo.
> 
> -- 
> Simo Sorce * Red Hat, Inc * New York



More information about the sssd-devel mailing list