Simo Sorce wrote: > On Thu, 30 Sep 2010 14:53:56 +0200 > Sumit Bose <sb...@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/ _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
