Stephen Gallagher wrote: > First, a little overview on netgroups. Netgroups in LDAP can contain two > attributes: > 1) nistNetgroupTriple - Contains a literal triple of (host, username, > domain) > 2) memberNisNetgroup - The name (or DN, more on that later) of another > netgroup. > > Returning triples are simple, we just return them as-is. However, > returning nested netgroups introduces a bit of additional complexity. > > Currently, nss_ldap just returns the name of the memberNisNetgroup > directly to glibc and allows it to handle it. This means that glibc will > make an extra, internal set of setnetgrent(), getnetgrent() > endnetgrent() calls to nss_ldap. Or not: the design of glibc means that > if the nested netgroup appears in an NSS provider listed in > nsswitch.conf before nss_ldap, it will be returned from there, rather > than nss_ldap. This means that it is theoretically possible for a local > file to override the centralized LDAP for a netgroup. > > With SSSD, our original plan was that we should always treat the LDAP > server as authoritative. We would internally handle recursive lookups > for nested netgroups and unravel them ourselves before returning them to > glibc. We would only return nested names in this case if the specified > member does not exist on the LDAP server (in this case we will assume > that it's meant to be handled by another netgroup provider). > > To illustrate the difference: > > With nsswitch.conf: > netgroup files nss_ldap > > On LDAP: > ldapnetgroup1: (user1, host1, ldapdomain) extranetgroup2 > extranetgroup2: (user2, host2, ldapdomain) > > In local files: > extranetgroup2: (localuser, localhost, localdomain) > > With nss_ldap, making a request for ldapnetgroup1 would return to the > calling application (after glibc completed all its internal lookups): > > ldapnetgroup1: (user1, host1, ldapdomain), (localuser, localhost, > localdomain) > > Whereas with the proposed approach for SSSD: > With nssswitch.conf: > netgroup files sss > > We would get back from glibc: > ldapnetgroup1: (user1, host1, ldapdomain), (user2, host2, ldapdomain) > > > So the difference in behavior should be clear now. > > > The obvious advantage to this approach is that the central server will > always be considered authoritative for its entries. We will assume that > the specified member should use the LDAP representation as its first > option, and fail over to glibc's lookup for other netgroup providers > only if it does not exist in LDAP. > > This should provide a more stable environment, however it does differ > from the current expected behavior as defined by nss_ldap. > > > To enumerate the options we can follow: > 1) We can behave exactly as nss_ldap does. If we locate a member > netgroup, we can return that directly to glibc and expect to have it > look it up as needed. Pros: identical behavior to the current state. > Cons: makes additional requests to the SSSD that we could be handling > internally without a lot of back-and-forth to glibc. > > 2) We can assume that member entries in LDAP refer to LDAP entries > unless we cannot locate them. In this case, we can internally handle the > recursive lookups to LDAP. Any member netgroups that we don't find in > LDAP should be returned to glibc to process. Pros: we can control > nesting limits this way. The memberOf plugin also does a good job with > protecting us against loops. We can parallelize the lookups of multiple > member netgroups for performance. Cons: we are changing the behavior as > described above.
Suggestion: a) Implement option 2 now b) File a ticket to add a compatibility mode (controlled by a configuration switch) later and defer to post 1.5 release > > Appendix) There is no formal specification of netgroups. It's possible > for the memberNisNetgroup attribute to contain either a simple name or a > full LDAP distinguished name. If a full DN is provided, we should assume > that this means that it must be in LDAP, and stop processing (and don't > return it) if we get a DN that doesn't match. For entries that are not > complete DN's, we should choose one of the two aforementioned approaches. > > > Please comment if you have an opinion. > > _______________________________________________ sssd-devel mailing list sssd-de...@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ _______________________________________________ Freeipa-devel mailing list Freeipaemail@example.com https://www.redhat.com/mailman/listinfo/freeipa-devel