[Freeipa-devel] [SSSD] Handling nested netgroups (looking for recommendations)

[Dmitri Pal]

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-devel at 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/