[SSSD] Netgroups in SSSD

Stephen Gallagher sgallagh at redhat.com
Mon Sep 13 17:35:35 UTC 2010


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

On 09/13/2010 12:07 PM, Dmitri Pal wrote:
> 
> If I read it right you are saying that the callback is invoked first and
> it in turn invokes setnetgrent_recv() from itself. If this is the case
> then my statement in general is true. And the problem I see is that you
> can't assume that the order of the responses from the server will be
> same as the order of the requests. What if the request got rejected due
> to a bad connection but next request was satisfied. Or there was a
> glitch in router or something. It does not matter. My point that
> generally it is possible that the responses will come in reverse order
> so relying on the order of the responses in the algorithm is a mistake.
> 

No, it's not possible. The way requests with subrequests work is that
the toplevel request will NEVER return until all of its subrequests have
been processed (or an error occurs, which will cancel the subrequests).

I'll try to explain in pseudocode a little better.

setnetgrent() {
    req = setnetgrent_send(<data>);
    tevent_req_set_callback(req, setnetgrent_done);
}

setnetgrent_send() {
    subreq = setnetgrent_internal_send(data, nesting=0);
    tevent_req_set_callback(subreq, setnetgrent_internal_done)
}

The toplevel will NEVER call setnetgrent_done() until any and all
individual setnetgrent_send_internal_send/done pairs have completed.


That's a high-level view. In a real implementation, the
setnetgrent_internal_done() call would call a
setnetgrent_internal_step() function whose purpose it would be to call
setnetgrent_internal_send() again in series so that we processed all the
lookups.

We don't parallelize the individual netgroup lookups. They're always
done in a serial manner (though asynchronous so we don't block if they
have to go to LDAP).

>>> The problems I have are with the item 4).
>>> If it removes the netgroup from the hash how the hash ever grows?
>>
>> You're confusing the hash with the result set (which will be a
>> libcollection object). I'm thinking about changing the way I do the
>> nested invocation so that the toplevel hides the need for the hash.
>>
>> The idea behind the hash is actually to have it double as a reference
>> count and a loop-detection mechanism. It doesn't need to be a hash (it
>> could just as easily be a b-tree), but since we already have an
>> efficient hash available, I was just going to use that.
>>
> 
> It does not make a difference what actual implementation (hash, b-tree,
> collection you are going to use for it). It is a set and a check against
> a set needs to be made.
> 

Yes, and also the dhash has a built-in function that can report the
total number of keys available, which I'll use to identify the nesting
level.

>> The idea is that for every time we recurse down a level, we will add the
>> name of that netgroup to the hash. Before recursing down again, we'll
>> make sure that the new name is not a key in the hash. If it is, we know
>> we've hit a loop and should break processing.
> I agree with this part 100%. I was concerned about the moment you plan
> to remove item from the set.
> 

I have to remove it from the set when we traverse down a separate
section of the nesting tree because (as an optimization) we're saving
the results of the nested netgroups in their entirety into the cache
(since we're already processing it). So that if we call netgroupA which
has netgroupB and netgroupC as members, each of which ALSO have
netgroupD as a member, then we have the complete copies of netgroupB and
netgroupC available in the lookup cache already, in case a request is
made directly against them.

It DOES result in duplicate data when reporting netgroupA (which is
acceptable), but it means that we have complete data to cache for the
other netgroups.

> 
>>
>> When we recurse up a level, we need to remove this entry from the
>> tracking hash so that it's possible to recurse down into it again in a
>> different branch of the tree. There is a pro and con to this approach.
> I see what you are trying to accomplish but since you can't rely on the
> order of the responses you can't be sure if this is a response for a
> nested group or group on a different branch. We need to think of a
> better safeguard here.
> 

See above. We can always guarantee the order of the responses.


- -- 
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/

iEYEARECAAYFAkyOYOcACgkQeiVVYja6o6MNLACeJD9TmIQ30LEEt/tFilE0YBWM
pvsAn23weIajFuwiXGzB+h1jjxwZ9sGq
=9Str
-----END PGP SIGNATURE-----



More information about the sssd-devel mailing list