[SSSD] Netgroups in SSSD

Dmitri Pal dpal at redhat.com
Mon Sep 13 16:07:35 UTC 2010


Stephen Gallagher wrote:
> On 09/10/2010 09:42 AM, Dmitri Pal wrote:
> > Stephen Gallagher wrote:
> >> On 09/08/2010 09:04 AM, Stephen Gallagher wrote:
> >>> 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've added some additional details about how I would like to do the
> >> nesting and loop detection to the wiki page. Comments welcome.
> >>
> > Sorry I am having trouble understanding this algorithm.
> > But may be it is because i do not understand the tevent_req interface to
> > the level needed here.
> > AFAIU the
> > struct tevent_req setnetgrent_send(char *netgroupname, hash_table_t
> > *nesting)
> > call will ask for the netgroups, while another call
> > errno_t setnetgrent_recv(tevent_req *req, struct collection **entries)
> > is the call that will be executed when the response from the server is
> > received.
>
> No, this is where you are mistaken. The call that will be executed when
> the request is finished is specified by the caller right after invoking
> setnetgrent_send() by using the tevent_set_callback() function.
>
> This function that is called must then invoke setnetgrent_recv() in
> order to read out the final result data that is available.
>

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.

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

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


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


Thanks
Dmitri



More information about the sssd-devel mailing list