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