On Thu, Sep 30, 2010 at 10:19:04AM -0400, Dmitri Pal wrote: > 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. >
ok, then I understood it wrong. So your suggestion is to translate the DNs to the corresponding CNs and return them together with the plain names from memberNisNetgroup to glibc and do not do any nested group unrolling in sssd. I'm fine with this scheme. As mentioned earlier I think we should agree on a basic solution for a start and should add optimizations based on Use-Cases later. bye, Sumit > > 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 _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
