sssd-devel February 2010

sssd-devel@lists.fedorahosted.org

13 participants
85 discussions

[PATCH] Remove ELAPI from the SSSD repo
by Stephen Gallagher 12 Feb '10

12 Feb '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ELAPI now lives at https://fedorahosted.org/ELAPI This patch removes the ELAPI source from the tree (and build). The patch is gzipped because all the deleted text is included (making the patch very large) - -- 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/ iEYEARECAAYFAktxz0IACgkQeiVVYja6o6NX1gCcDSUz41/SlanwKcQC2rOYUgKi MYoAoKwN8MTgImVWJTCx+Pr9wNxP3AGH =Oxgf -----END PGP SIGNATURE-----

2 2

[PATCH] gitignore additions
by Jakub Hrozek 12 Feb '10

12 Feb '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 add some binaries to .gitignore -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkt1Ru8ACgkQHsardTLnvCUSHwCZAbA8V4tNRAHaeTxAhFC57pKh eF0AnR1HMffb39h9v7Ug//OQboCjIFCe =J+G/ -----END PGP SIGNATURE-----

2 2

[PATCH] Make change password errors more transparent
by Sumit Bose 12 Feb '10

12 Feb '10

Hi, this patch send the error message from an LDAP or Kerberos server back to the user if a password change fails. I think we do not disclose information here, because the user is already authenticated with his old password during this operation. Currently thers is no easy way to translate these messages. bye, Sumit

2 2

[PATCH] Don't pass a variable as format to talloc_asprintf()
by Martin Nagy 12 Feb '10

12 Feb '10

Hi, SSIA. Martin

2 2

Developing custom SSSD data provider backends
by Stephen Gallagher 11 Feb '10

11 Feb '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 For the last week, I've been working on developing a set of guidelines on how to create a custom SSSD data provider backend. These backends would be capable of performing identification and/or authentication to custom mechanisms (such as winbind, NIS, SecurID, etc.) First, I'd like to describe the way things work internally (for the benefit of anyone not intimately familiar), then I'll go into the issues we're facing with allowing custom backends. Currently, the SSSD provides two services that face the system: NSS and PAM. This is done by way of very lightweight NSS and PAM modules that can be loaded automatically by nsswitch.conf or the PAM stack and that then pass the request across a privileged pipe to the sssd_nss or sssd_pam services (as appropriate). Each time a request comes in, the service first queries the internal sysdb to determine whether the entry already exists in an unexpired cache entry. If it does not exist (or is expired), the service then must communicate directly with a backend provider to update the cache. This is done over a private pipe using the D-BUS protocol (we refer to communications over this pipe as SBUS communications, so as not to be confused with communications going over the system bus). When a data provider backend receives the request, it then contacts its own information source (LDAP, NIS, etc.) in an appropriate manner, retrieving the information and updating the sysdb cache. It then returns a message to the NSS/PAM service stating only whether the communication succeeded (and if not, an error message describing the problem). Assuming that it succeeded, the service will then query the sysdb again, this time receiving an updated entry. Now, it is important to note here that at no time does the communication on the SBUS carry the result of the lookup that is performed by the provider backend. It only carries the success/failure message. The true final result is only returned from the sysdb, when it is queried after the provider replies. Because of this design, it is necessary for all data providers to be capable of writing directly to the sysdb. This introduces some serious concerns for potential backend implementers. The sysdb is designed to be an asynchronous interface using the tevent mainloop. There is currently no way to integrate the sysdb with any other mainloop, because at its heart, the sysdb operates on an LDB database, which also mandates the use of tevent for asynchronous operation. So, in order to implement a backend provider, the provider must be written in C and built around libtevent. This is not likely to be an acceptable set of requirements for many implementers. I've been trying to work around this, and I have come up with a few potential approaches to this problem. 1) We can create a sync wrapper around all calls to the sysdb and hides the requirement for tevent. Internally, all calls to the actual LDB are effectively synchronous, so the performance shouldn't be too poor, though there is still a chance that some of the longer operations (like initgroups commands with large user bases) may block for an extended period of time. 2) We can fork a process/spawn a thread to do the processing outside of main execution and signal our completion. As I understand it, this is the approach SELinux takes to asynchronous operation. This would likely be a tremendous amount of work. 3) We can create a new SSSD service (sssd_sysdb?) that exposes the sysdb over the SBUS(or even the system bus) restricted to root processes. This might be the most future-compatible approach, but it too is a lot of work (though I believe it to be less work than option 2) 4) We can go back to our original plan of having third-party implementers follow our internal example and write shared objects that can be loaded by the sssd_be process. This approach handles the mainloop integration internally, thereby simplifying it for the implementers, but it carries potential licensing issues. Since the sssd_be is licensed as GPL, any shared object that it loads needs to be GPL-compatible. This won't fly for companies that want to create a closed-source backend. This is the least amount of work (almost none). - -- 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/ iEYEARECAAYFAkt0Rr4ACgkQeiVVYja6o6PjbACfUFDIqTNHDiduguFv+lrIGbrZ LgwAoKPmPp6GZYsydREqPz9/J2EhKVhX =nmc3 -----END PGP SIGNATURE-----

2 3

extent of doc change for bug #167
by David O'Brien 11 Feb '10

11 Feb '10

https://fedorahosted.org/sssd/ticket/167 Again, I don't know what notifications are sent out for closed bugs, hence the email. cheers -- David O'Brien Red Hat Asia Pacific Pty Ltd He who asks is a fool for five minutes, but he who does not ask remains a fool forever." ~ Chinese proverb

1 0

[PATCH] sss_groupshow improvements
by Jakub Hrozek 10 Feb '10

10 Feb '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This patch fixes the following issues: * man page issues (#395) * show info on MPGs (#396) * recursively print indirect members (#397) * the list of groupnames is comma separated (#398) * output inconsistencies (#399) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAktwbZkACgkQHsardTLnvCUl6gCffDSrlRrfr955H9o8Y55PteLz Kk8AoOk4Y1CgJuXXT4KcVulQDfMrkCko =38ve -----END PGP SIGNATURE-----

3 8

[PATCH] Make collection_queue.h and collection_stack.h into public headers
by Stephen Gallagher 10 Feb '10

10 Feb '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 When we turned libcollection into a shared library, I neglected to include collection_queue.h and collection_stack.h in the list of installed public headers. These are necessary for the elapi split. - -- 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/ iEYEARECAAYFAktywoQACgkQeiVVYja6o6O4PACfU3HZ5HBK0g3SqWKxDW7csgZ1 R2IAn0Gr3qccih/DhfOQslPgTVKmQg/C =JXTL -----END PGP SIGNATURE-----

2 4

[PATCH] Fix other memory alignment issues
by Jakub Hrozek 10 Feb '10

10 Feb '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Similar to George McCollister's patch to the pam code, this patch fixes other places in the code where we forced data into 32-bit alignment. Fixes: #390 George was testing KRB authentication with this patch and confirmed[1] it was working for him on ARM. I was running SSSD with this patch on x86_64 and did not spot any regressions. [1] https://fedorahosted.org/sssd/ticket/390#comment:3 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAktx1hcACgkQHsardTLnvCUADwCgt9M05Clp45G7IUVLe/sFiJ1n ov8AoKSP2QGpoFXvAGGyEbmjfmBlG5sP =a2Yy -----END PGP SIGNATURE-----

3 4

[PATCH] Few misc minor man page bugs
by Jakub Hrozek 10 Feb '10

10 Feb '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 * sssd.conf * sbus_timeout was used in an example but explained nowhere * enum_cache_timeout unit was not defined * same for entry_cache_timeout * store_legacy_passwords option does not exist anymore * better example than domain/LOCAL - domain/LDAP which uses krb5/ldap * sssd.conf(5) listed sssd.conf(5) in SEE ALSO section * sssd-krb5, sssd-ldap * these include each other in SEE ALSO section -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAktwbZMACgkQHsardTLnvCWosACdGFeykoTyFbiK8ELd6jjRcejA i7IAoJoR+Rm7tuvzqIs/ob2r6tP8vKgz =1Qkg -----END PGP SIGNATURE-----

2 4

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

sssd-devel February 2010