On Tue, Sep 28, 2010 at 11:17 AM, Stephen Gallagher <sgallagh(a)redhat.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
First, a little overview on netgroups. Netgroups in LDAP can contain two
1) nistNetgroupTriple - Contains a literal triple of (host, username,
2) memberNisNetgroup - The name (or DN, more on that later) of another
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).
Not for the sake of being argumentative, but for the sake of
completeness, why do you want to change the semantics of what an admin
would expect? Especially when most people using sssd are former
pam_ldap users and expect things like netgroups to work a certain way?
While not disagreeing, I'm just curious as to the reasoning.
Don't drink and derive, alcohol and analysis don't mix.