Simo Sorce wrote:
On Thu, 30 Sep 2010 14:53:56 +0200
Sumit Bose <sbose(a)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.
Exposing the inner workings of a nsswitch
module to the consumers is generally not a good idea IMO.
If we really *have* to return something and we do not have a name,
at least I suggest making a hash of the DN and returning that with a
prefix like "netgroup352AF324DE31242CB" so that it "looks" like a
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.
Engineering Manager IPA project,
Red Hat Inc.
Looking to carve out IT costs?