On Thu, Sep 30, 2010 at 08:28:37AM -0400, Dmitri Pal wrote:
Sumit Bose wrote:
> On Tue, Sep 28, 2010 at 06:27:29PM -0400, Dmitri Pal wrote:
>> Stephen Gallagher wrote:
>>> 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).
>>> 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,
>>> 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.
>> 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
>>> Please comment if you have an opinion.
> My suggestion is to lookup all memberNisNetgroup which are a DN in sssd
> directly and return everything else to glibc.
How it is a DN? You can't say what server will have the DN or name. I
No you can't because in general can have both names and DNs even in the
memberNisNetgroup of the same object.
would assume that most of the LDAP servers will have name rather than
So at some point you need to do a lookup. I think that we can use
heuristic that server has a DN in memberNisNetgroup later for
optimization because I think is a corner case rather than a common
situation. Internally we can use mapping between CN name and DN but IMO
we should not return to libc something that is not in the attribute we
read from the server. So if we read "foo" we should return "foo". If
already know that it is really a cn=foo,ou=netgroups... we can keep a
hash table of CN to DN mappings in SSSD.
So you suggest that we return everything that is in memberNisNetgroup to
glibc but be more clever than nss_ldap if glibc asks for a group with a
name that is a DN?
> This way we
> - are mostly compatible with nss_ldap. Mostly, because nss_ldap does not
> handle DNs. I will return DNs to glibc and when they are set back by
> glibc it does not treat them as DNs but as netgroup name. E.g. if there
> is an entry like cn=g1,ou= netgroups,dc=example,dc=com in
> memberNisNetgroup, nss_ldap returns 'cn=g1,ou=
> netgroups,dc=example,dc=com' to glibc and when glibc asks for a
> netgroups with the name 'cn=g1,ou=netgroups,dc=example,dc=com' nss_ldap
> search for 'cn=cn\=g1,ou\=netgroups,dc\=example,dc\=com' in LDAP, which
> in general will fail.
> - can let the admin decide if he wants full compatiblity (use only names
> in memberNisNetgroup) or wants to reduce the number of LDAP queries
> (use DNs for netgroups in LDAP)
> In future version we can add other kinds of optimatiztions based on Use
>> sssd-devel mailing list
>> Thank you,
>> Dmitri Pal
>> Engineering Manager IPA project,
>> Red Hat Inc.
>> Looking to carve out IT costs?
>> sssd-devel mailing list
> sssd-devel mailing list
Engineering Manager IPA project,
Red Hat Inc.
Looking to carve out IT costs?
sssd-devel mailing list