[SSSD] Handling nested netgroups (looking for recommendations)

Jeff Schroeder jeffschroeder at computer.org
Tue Sep 28 23:02:23 UTC 2010


On Tue, Sep 28, 2010 at 11:17 AM, Stephen Gallagher <sgallagh at redhat.com> wrote:
> -----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).

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.

-- 
Jeff Schroeder

Don't drink and derive, alcohol and analysis don't mix.
http://www.digitalprognosis.com



More information about the sssd-devel mailing list