sssd-devel October 2010

sssd-devel@lists.fedorahosted.org

14 participants
65 discussions

[PATCH] Save dummy groups to cache during initgroups (sssd-1.2)
by Jakub Hrozek 06 Oct '10

06 Oct '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [PATCH 1/2] sysdb interface for adding fake groups Adds a sysdb_add_fake_group_send() call that adds an expired group entry. [PATCH 2/2] Save dummy groups to cache during initgroups When performing initgroups/getgrouplist on RFC2307, add fake group entries for those groups that are not cached already. That way, complete group membership is returned without saving complete group objects. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkyrXBAACgkQHsardTLnvCXX1ACfSoDJ4xRyBNF88A+6viXwJukG hmoAoLSudyDHOSD4F30HlF0YEeVUGuoW =0xuH -----END PGP SIGNATURE-----

2 9

[PATCH] End update_members request if there's nothing to do (sssd-1.2)
by Jakub Hrozek 05 Oct '10

05 Oct '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 If there were no users to add nor delete, sysdb_update_members_step() would mark the request as done but not call post, so the callback would never be called. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkyrXAYACgkQHsardTLnvCVCYQCeI3I4GmRWwP+WuCibmVNOQl7n RAAAoKJsmOt0tpUKHs2lRzQOhpTj5XzN =kaPS -----END PGP SIGNATURE-----

2 1

[PATCH] Return offline instead of error
by Stephen Gallagher 04 Oct '10

04 Oct '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 When the failover code returns that there are no available servers while we are marked offline, we were returning an error to the PAM authentication code. Instead, we should return success with a result value of SDAP_UNAVAIL so that the PAM responder will mark the domain offline and attempt offline authentication. - -- 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/ iEYEARECAAYFAkymLIIACgkQeiVVYja6o6MNLwCfYs1KNyo/efVWxZXu1sY6jkb2 /YAAnREisr66R1+gWaj9tCkXyCOcZ/2w =eRON -----END PGP SIGNATURE-----

3 4

Handling nested netgroups (looking for recommendations)
by Stephen Gallagher 04 Oct '10

04 Oct '10

-----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-----

7 17

[PATCH] Save dummy member users during RFC2307 getgr{nam, uid} (master)
by Jakub Hrozek 02 Oct '10

02 Oct '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [PATCH 1/2] sysdb interface for adding fake users same as in previous patchset, just adds fake users [PATCH 2/2] Save dummy member users during RFC2307 getgr{nam,uid} When performing getgrnam/getgrgid, instead of looking up the member users, just save expired user entries. These patches apply on top of Ralf's patches. I also changed two very minor things that IMHO make the whole codepath read more easily - I moved struct sdap_process_group_state next to sdap_process_group_send() and renamed sdap_process_group_done() as the name suggested that it is a _done() callback of sdap_process_group_send(). Stephen, how would you like to coordinate backporting this to 1.2 since, as far as I recall, we won't be backporting Ralf's patches? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkykhNsACgkQHsardTLnvCWBnwCgiJVOzgnJnN6riKU3SUrhhf7G kq8AoKYyOhAz68ymJOSL2Pqfqhi2d4Xp =I238 -----END PGP SIGNATURE-----

1 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

sssd-devel October 2010