-----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/
Stephen Gallagher wrote:
First, a little overview on netgroups. Netgroups in LDAP can contain two attributes:
- 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:
- 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.
- 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@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
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 attributes:
- 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:
- 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.
- 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.
My suggestion is to lookup all memberNisNetgroup which are a DN in sssd directly and return everything else to glibc.
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 Cases.
bye, Sumit
sssd-devel mailing list sssd-devel@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/
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
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 attributes:
- 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:
- 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.
- 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.
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 would assume that most of the LDAP servers will have name rather than a DN. 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 we already know that it is really a cn=foo,ou=netgroups... we can keep a hash table of CN to DN mappings in SSSD.
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 Cases.
bye, Sumit
sssd-devel mailing list sssd-devel@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/
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
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 attributes:
- 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:
- 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.
- 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.
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 a DN. 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 we 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?
bye, Sumit
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 Cases.
bye, Sumit
sssd-devel mailing list sssd-devel@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/
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
sssd-devel mailing list sssd-devel@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/
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
On Thu, 30 Sep 2010 14:53:56 +0200 Sumit Bose sbose@redhat.com wrote:
would assume that most of the LDAP servers will have name rather than a DN. 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 we 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 looks weird and somewhat wrong to me. We should always translate DNs to names as that's what the glibc interface expect to see. Exposing the inner workings of a nsswitch module to the consumers is generally not a good idea IMO.
If we really *have* to return something and we do not have a name, then at least I suggest making a hash of the DN and returning that with a prefix like "netgroup352AF324DE31242CB" so that it "looks" like a real name.
Simo.
Simo Sorce wrote:
On Thu, 30 Sep 2010 14:53:56 +0200 Sumit Bose sbose@redhat.com wrote:
would assume that most of the LDAP servers will have name rather than a DN. 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 we 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 looks weird and somewhat wrong to me. We should always translate DNs to names as that's what the glibc interface expect to see.
Agree 100%
Exposing the inner workings of a nsswitch module to the consumers is generally not a good idea IMO.
+1
If we really *have* to return something and we do not have a name, then at least I suggest making a hash of the DN and returning that with a prefix like "netgroup352AF324DE31242CB" so that it "looks" like a real name.
We can use CN out of DN since the names of the netgroups within a domain is unique. I do not think there is a need for creating a name. But we can keep the full DNs in a hash table internally since in general case we can't assume that they are under the same container like in IPA.
Simo.
On Thu, Sep 30, 2010 at 10:19:04AM -0400, Dmitri Pal wrote:
Simo Sorce wrote:
On Thu, 30 Sep 2010 14:53:56 +0200 Sumit Bose sbose@redhat.com wrote:
would assume that most of the LDAP servers will have name rather than a DN. 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 we 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 looks weird and somewhat wrong to me. We should always translate DNs to names as that's what the glibc interface expect to see.
Agree 100%
Exposing the inner workings of a nsswitch module to the consumers is generally not a good idea IMO.
+1
If we really *have* to return something and we do not have a name, then at least I suggest making a hash of the DN and returning that with a prefix like "netgroup352AF324DE31242CB" so that it "looks" like a real name.
We can use CN out of DN since the names of the netgroups within a domain is unique. I do not think there is a need for creating a name. But we can keep the full DNs in a hash table internally since in general case we can't assume that they are under the same container like in IPA.
ok, then I understood it wrong. So your suggestion is to translate the DNs to the corresponding CNs and return them together with the plain names from memberNisNetgroup to glibc and do not do any nested group unrolling in sssd.
I'm fine with this scheme. As mentioned earlier I think we should agree on a basic solution for a start and should add optimizations based on Use-Cases later.
bye, Sumit
Simo.
-- Thank you, Dmitri Pal
Engineering Manager IPA project, Red Hat Inc.
Looking to carve out IT costs? www.redhat.com/carveoutcosts/
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
Sumit Bose wrote:
On Thu, Sep 30, 2010 at 10:19:04AM -0400, Dmitri Pal wrote:
Simo Sorce wrote:
On Thu, 30 Sep 2010 14:53:56 +0200 Sumit Bose sbose@redhat.com wrote:
would assume that most of the LDAP servers will have name rather than a DN. 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 we 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 looks weird and somewhat wrong to me. We should always translate DNs to names as that's what the glibc interface expect to see.
Agree 100%
Exposing the inner workings of a nsswitch module to the consumers is generally not a good idea IMO.
+1
If we really *have* to return something and we do not have a name, then at least I suggest making a hash of the DN and returning that with a prefix like "netgroup352AF324DE31242CB" so that it "looks" like a real name.
We can use CN out of DN since the names of the netgroups within a domain is unique. I do not think there is a need for creating a name. But we can keep the full DNs in a hash table internally since in general case we can't assume that they are under the same container like in IPA.
ok, then I understood it wrong. So your suggestion is to translate the DNs to the corresponding CNs and return them together with the plain names from memberNisNetgroup to glibc and do not do any nested group unrolling in sssd.
I'm fine with this scheme. As mentioned earlier I think we should agree on a basic solution for a start and should add optimizations based on Use-Cases later.
Yes
bye, Sumit
Simo.
-- Thank you, Dmitri Pal
Engineering Manager IPA project, Red Hat Inc.
Looking to carve out IT costs? www.redhat.com/carveoutcosts/
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/30/2010 12:03 PM, Sumit Bose wrote:
ok, then I understood it wrong. So your suggestion is to translate the DNs to the corresponding CNs and return them together with the plain names from memberNisNetgroup to glibc and do not do any nested group unrolling in sssd.
I'm fine with this scheme. As mentioned earlier I think we should agree on a basic solution for a start and should add optimizations based on Use-Cases later.
Ok, just to summarize:
The plan will be that for ALL memberNisNetgroup entries, we will normalize them as names of netgroups if they are DNs, and then we will return all of them to glibc rather than attempting to internally resolve them.
Is this an accurate summary?
- -- Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
Stephen Gallagher wrote:
On 09/30/2010 12:03 PM, Sumit Bose wrote:
ok, then I understood it wrong. So your suggestion is to translate the DNs to the corresponding CNs and return them together with the plain names from memberNisNetgroup to glibc and do not do any nested group unrolling in sssd.
I'm fine with this scheme. As mentioned earlier I think we should agree on a basic solution for a start and should add optimizations based on Use-Cases later.
Ok, just to summarize:
The plan will be that for ALL memberNisNetgroup entries, we will normalize them as names of netgroups if they are DNs, and then we will return all of them to glibc rather than attempting to internally resolve them.
Is this an accurate summary?
Yes
_______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
On Tue, Sep 28, 2010 at 11:17 AM, Stephen Gallagher sgallagh@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.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/29/2010 01:02 AM, Jeff Schroeder wrote:
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.
Is that behaviour used in the field, though? In what scenario? (I'm not a sysadmin, so these are genuine questions..)
FWIW, my personal opinion is similar to Dmitri's - implement just #2 for now as it sounds like a much better solution from engineering perspective and add a compatibility mode if needed in a later release if someone asks for it. That way we get coverage for 99% of the cases now and we'll see if we need to worry about the compatibility mode at all.
Jakub
On Wed, Sep 29, 2010 at 1:45 AM, Jakub Hrozek jhrozek@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/29/2010 01:02 AM, Jeff Schroeder wrote:
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.
Is that behaviour used in the field, though? In what scenario? (I'm not a sysadmin, so these are genuine questions..)
Well it really depends on the admin. Personally, if I wanted to implement the equivalent of netgroups locally, pam_access is the tool for the job. I was just pointing out that you're going around a perfectly valid existing configuration and it might be unexpected. Please make sure to document this feature well.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/28/2010 07:02 PM, Jeff Schroeder wrote
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.
Well, as I was trying to explain in the original email, there are several advantages to doing this differently.
1) Much higher performance. If we perform the nested lookups inside of SSSD, we can potentially perform multiple parallel lookups and save us the time of repeated round-trips from LDAP.*
2) We can provide an option for nesting limits. Right now, glibc will always follow nested netgroups down as far as it can go. In a pathological case, this could be thousands of nestings deep. That can be extremely expensive.
3) We guarantee that the central LDAP store is authoritative for netgroups. Doing things this way ensures that if a netgroup arrangement is set up on the server, no local change will interject unexpected values into the mix, intentionally or otherwise.
* It occurred to me while writing this email that even if we did go with the traditional behavior, we could still probably pre-cache the nested groups so that when glibc requests them we can serve them from cache. Of course, this can also be a waste of processing time if it turns out that one of the nested members (potentially one that has other, further nested members) is in fact being overridden on the client. - -- Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
On Wed, Sep 29, 2010 at 3:40 AM, Stephen Gallagher sgallagh@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/28/2010 07:02 PM, Jeff Schroeder wrote
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.
Well, as I was trying to explain in the original email, there are several advantages to doing this differently.
- Much higher performance. If we perform the nested lookups inside of
SSSD, we can potentially perform multiple parallel lookups and save us the time of repeated round-trips from LDAP.*
- We can provide an option for nesting limits. Right now, glibc will
always follow nested netgroups down as far as it can go. In a pathological case, this could be thousands of nestings deep. That can be extremely expensive.
These are both excellent reasons to use sssd.
- We guarantee that the central LDAP store is authoritative for
netgroups. Doing things this way ensures that if a netgroup arrangement is set up on the server, no local change will interject unexpected values into the mix, intentionally or otherwise.
I'm not sold on this idea whatsoever. If you have access to change nss, you have access to disable sssd / futz the ldap configuration. While this is a noble goal, configuration management is for ensuring valid configurations. As I so eloquently say, "You can't protect a system from a stupid admin."
- It occurred to me while writing this email that even if we did go with
the traditional behavior, we could still probably pre-cache the nested groups so that when glibc requests them we can serve them from cache. Of course, this can also be a waste of processing time if it turns out that one of the nested members (potentially one that has other, further nested members) is in fact being overridden on the client.
Just trying to keep you gents on your toes. Keep up the great work and thanks for answering my questions.
[Jeff Schroeder]
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.
We use netgroups in NIS and LDAP here at the University of Oslo, and we expect netgroups to behave as they always have, no matter the supplier (nis, ldap or sss :).
I use netgroups in /etc/netgroups when I need to debug stuff, to be able to quickly change their values before pushing the final version into our admin too (which is used to populate NIS and LDAP). So to me, it would be a surprise if /etc/nsswitch.conf was ignored when it come to netgroup sources and glibc was not the one in charge of expanding recursive netgroups. If I did not want to consult local files, I would list 'netgroup: sss' instead of 'netgroup files sss' in nsswitch.conf. :)
Happy hacking,
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/04/2010 07:38 AM, Petter Reinholdtsen wrote:
[Jeff Schroeder]
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.
We use netgroups in NIS and LDAP here at the University of Oslo, and we expect netgroups to behave as they always have, no matter the supplier (nis, ldap or sss :).
I use netgroups in /etc/netgroups when I need to debug stuff, to be able to quickly change their values before pushing the final version into our admin too (which is used to populate NIS and LDAP). So to me, it would be a surprise if /etc/nsswitch.conf was ignored when it come to netgroup sources and glibc was not the one in charge of expanding recursive netgroups. If I did not want to consult local files, I would list 'netgroup: sss' instead of 'netgroup files sss' in nsswitch.conf. :)
Happy hacking,
Yes, we've made our final decision that, instead of trying to improve our performance, we are simply going to throw the nested group names over the wall to glibc and let it sort it out.
We lose the ability to limit nesting levels and do loop-detection in this case, however. We just have to trust that glibc is sane.
- -- Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
sssd-devel@lists.fedorahosted.org
-
Dmitri Pal -
Jakub Hrozek -
Jeff Schroeder -
Petter Reinholdtsen -
Simo Sorce -
Stephen Gallagher -
Sumit Bose