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

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

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.


- -- 
Stephen Gallagher
RHCE 804006346421761

Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkyiMSIACgkQeiVVYja6o6MuxwCghVhG3baFori0Retl6itILvLe
NqkAn3Sn5EZkgP5Yoztuvh/KHudWP48S
=tcYu
-----END PGP SIGNATURE-----