[SSSD] Netgroups in SSSD

Stephen Gallagher sgallagh at redhat.com
Wed Sep 8 17:05:04 UTC 2010


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/08/2010 12:00 PM, Dmitri Pal wrote:
> Stephen Gallagher wrote:
>> On 09/08/2010 08:26 AM, Jakub Hrozek wrote:
>>> On 09/08/2010 02:12 AM, Stephen Gallagher wrote:
>>>> I have written up a problem statement and a brief overview of my plans
>>>> regarding netgroup support in the SSSD.
>>>> Please read through and comment as needed:
>>>> https://fedorahosted.org/sssd/wiki/DesignDocs/Netgroups
>>>> My goal is to have this work completed before the end of September.
>>
>>> I asked my question as another bullet point to the wiki, but Stephen
>>> reminded me there's probably a wider audience on this list.
>>
>>> This was the question and answer:
>>
>>> Q: Maybe this is too low-level at this time, but is a cleanup task
>> planned?
>>> A: Netgroups should be handled in the same way that users and groups are
>>> handled, so I will probably have to extend the existing cleanup task to
>>> also address the netgroups entries in the cache
>>
>>
>> I've also been thinking about how we're going to handle processing the
>> nested groups, and I think what I'm going to do is take advantage of
>> some of the nicer features of libcollection.
>>
>> Internal processing of setnetgrent_send() will recursively call out a
>> subrequest to setnetgrent_send() again for each of the named nested
>> groups. The setnetgrent_recv() function will return a libcollection
>> object containing all of the results from that request (as well as any
>> additional subrequests called). When the results come back up, they can
>> be added together trivially using the col_add_collection_to_collection()
>> interface with the col_add_mode_clone mode.
>>
> I think this would work.
> I started thinking that potentially there should be a way to not clone
> the subcollections but rather use references to nested groups.
> I was thinking that if you keep a hash table of the names of netgroups
> as keys and pointers (or structures with one member being pointer) as
> values you would be able to construct collections from cache without
> copying data but rather by reference.
> However this seems to be an optimization that might not be worth it at
> least in the first implementation. So let us start with what you propose
> and see if it scales. If not we will see how it can be improved.


I thought about this approach originally, but the problem is that each
of the netgroup result objects have their own lifetime. For example, if
the lifetime is 30 seconds, and we do a lookup for netgroup1 at t=0,
then do a lookup for netgroup2 at t=29, where netgroup2 has netgroup1 as
a nested member, then the reference for that first netgroup is only
going to be valid for one more second. There are ways we can force
updates on read, but this is very expensive computationally.

I'd rather take a memory hit with copying the data to guarantee that it
remains intact than add the complexity of trying to manage references
with different life-spans.

So in this case, if netgroup2 is looked up at t=29, their internal copy
of netgroup1 is still valid until t=59 when netgroup2 expires.

- -- 
Stephen Gallagher
RHCE 804006346421761

Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkyHwkAACgkQeiVVYja6o6MNgQCfcjR+ZjKX01CQXtUHGsHEJ/2K
RogAn0Wc8zDZ8mhphmAMa5rDqjiopGz2
=zz/r
-----END PGP SIGNATURE-----



More information about the sssd-devel mailing list