[SSSD] Handling nested netgroups (looking for recommendations)

Dmitri Pal dpal at redhat.com
Thu Sep 30 14:19:04 UTC 2010


Simo Sorce wrote:
> On Thu, 30 Sep 2010 14:53:56 +0200
> Sumit Bose <sbose at redhat.com> wrote:
>
>   
>>> would assume that most of the LDAP servers will have name rather
>>> than a DN. So at some point you need to do a lookup. I think that
>>> we can use heuristic that server has a DN in memberNisNetgroup
>>> later for optimization because I think is a corner case rather than
>>> a common situation. Internally we can use mapping between CN name
>>> and DN but IMO we should not return to libc something that is not
>>> in the attribute we read from the server. So if we read "foo" we
>>> should return "foo". If we already know that it is really a
>>> cn=foo,ou=netgroups... we can keep a hash table of CN to DN
>>> mappings in SSSD.       
>>>       
>> So you suggest that we return everything that is in memberNisNetgroup
>> to glibc but be more clever than nss_ldap if glibc asks for a group
>> with a name that is a DN?
>>     
>
> This looks weird and somewhat wrong to me.
> We should always translate DNs to names as that's what the glibc
> interface expect to see.
Agree 100%

>  Exposing the inner workings of a nsswitch
> module to the consumers is generally not a good idea IMO.
>
>   
+1

> If we really *have* to return something and we do not have a name, then
> at least I suggest making a hash of the DN and returning that with a
> prefix like "netgroup352AF324DE31242CB" so that it "looks" like a real
> name.
>
>   
We can use CN out of DN since the names of the netgroups within a domain
is unique. I do not think there is a need for creating a name.
But we can keep the full DNs in a hash table internally since in general
case we can't assume that they are under the same container like in IPA.

> Simo.
>
>   


-- 
Thank you,
Dmitri Pal

Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/




More information about the sssd-devel mailing list