sssd-devel April 2010

sssd-devel@lists.fedorahosted.org

17 participants
63 discussions

Start a nNew thread

[PATCH] Fix a potential memory violation
by Sumit Bose 26 Apr '10

26 Apr '10

Hi, by chance I came across this short read loop. bye, Sumit

3 2

[INI] Code restructuring
by Dmitri Pal 26 Apr '10

26 Apr '10

Hi, ini_config.c got too big. It became to hard to change things and add new functionality. This patch splits it into several files. See the patch comment for more details. No functional changes though. -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/

3 4

[PATCH] Set LDAP_OPT_RESTART for all LDAP connections
by Sumit Bose 26 Apr '10

26 Apr '10

Hi, this patch moves the setting of LDAP_OPT_RESTART from the SASL authentication code to the general connect call. I think chances are that it might be needed when the LDAP provider is used together with other providers which fork children. bye, Sumit

2 2

[PATCH] Avoid accessing half-deallocated memory when using talloc_zfree macro
by Eugene Indenbom 16 Apr '10

16 Apr '10

The current implementation of talloc_zfree macro has a substantial deficiency: it deallocates memory first and then clears a pointer. Clearing pointer after deallocation completes could lead to bad side effects when callbacks are called during object destruction: the callback called from destructor could dereference half-destroyed object referenced by the yet-not-cleared pointer. The above could lead to disastrous effects including memory double free. The patch attached fixes the issues by using correct free sequence: clear pointer first, then deallocate memory block. Eugene

2 6

[PATCH] Make ID provider init functions clearer
by Stephen Gallagher 16 Apr '10

16 Apr '10

Using sssm_*_init() as the name of the initialization function for identity providers was a holdover from earlier development when we thought we would only have a single "provider" entry in the config file. As we have now separated out the initialization functions for auth, chpass and access, we should rename sssm_*_init() to sssm_*_id_init() for a cleaner interface. -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/

3 3

[PATCH] Give information about ldap_schema in the sample config
by Stephen Gallagher 16 Apr '10

16 Apr '10

As requested in https://fedorahosted.org/sssd/ticket/438 -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/

2 2

[PATCH] Use SO_PEERCRED on the PAM socket
by Sumit Bose 16 Apr '10

16 Apr '10

Hi, please find attached my second attempt to exchange uid, gid and pid between PAM client and responder. This new apporoach does not require any communication between the client and the responder and should behave much better than the previous one based on SO_PASSCRED and SCM_CREDENTIALS. To make the review easier the first patch reverts the previous attempt. bye, Sumit

4 8

Config options for IPA provider
by Sumit Bose 16 Apr '10

16 Apr '10

Hi, the IPA provider has its own set of config options: - ipa_domain - ipa_server - ipa_hostname in the most simple case only ipa_server is needed. (If we can resolve service records we wouldn't even need this.) Behind the scenes the IPA provider is the LDAP identity provider glued together with the Kerberos authentication/change password provider and an IPA specific access provider. The options for the LDAP and Kerberos provider are set to defaults that will work with an IPAv2 server in a secure way. As documented in the man page it is possible to set LDAP or Kerberos specific options to override the defaults set by the IPA provider. While this makes sense e.g. for the timeout options there are other cases, especially for the LDAP provider, where is doesn't. So it is possible to set ldap_id_use_start_tls to true which is kind of useless and has performance penalties, because the communication is already protected by GSSAPI. Or it would be possible to disable GSSAPI by setting ldap_sasl_mech to none. So the question arises how to handle this situation? - Shall we keep everything as it is and only update the man page to underline that the default configuration is secure and you really only need the ipa_* options? - Shall we stop parsing ldap_* and krb5_* options and introduce ipa_* options for timeouts and other useful options? - Shall we start reading the config from the IPA server only? - Shall we do sometime completely different? Comments? bye, Sumit

5 5

Multi-line values in INI
by Dmitri Pal 15 Apr '10

15 Apr '10

Hi, First news is that I will spend more time in INI validation code in the nearest future than in ELAPI as it was originally planned. So ELAPI work will be deferred. Decision is made at least for now. Second is that I came to realization that the internal data representation for the INI collection should change. There is a bunch of data that makes sense to store together with the actual configuration value. 1) The line number 2) Whether the value was read from the file originally or was added on the second pass or may be it was automatically generated because other value implies it. 3) In future it might also store some state or other additional information needed for the validation. For example: was the value successfully validated and if not, what was the error. We do not need to define all the use cases now. But the fact that "just value" is not enough any more is important. So I think of replacing the "value" in the configuration collection with the "value object" that will be able to store mentioned above information and the "value" itself. I think it should be a structure since it is internal and can be easily internally extended on as needed basis. Same is true regarding the interfaces to deal with the object. Since it is going to be an internal object we do not have obligation to keep the interfaces the same. So the interface will have create, destroy, and a bunch of other set and get style methods. Though it is C and not C++ I am still following a pattern of "loose coupling" and creating "facades" rather than letting anyone deal with the structure directly. Hope no objections on that front. But as I started looking into the value object I realized that this is a perfect time to introduce or at least think about supporting multi line values in the INI files. I see two use cases that need to be handled in a different way: 1) I have a long line that I want to just split between several lines for readability. key = my long multi line value \ that I want to split in the ini file \ between different lines for readability. In this case the splitting between different lines is just done for readability and the application would expect the value consisting of one buffer with all lines concatenated, new lines removed and NEW LINE indicators removed. In the example above the NEW LINE indicator is a back slash but we will talk about alternative indicatios in more details below. 2) I have format where the new lines embedded into the value. For example PEM format for the certificate expects one buffer that consists of the set of the concatenated lines with NEW LINES symbols at the end of those lines preserved since they are a part of the format. In the ini file it will look like this: -----BEGIN CERTIFICATE REQUEST----- MIIBnTCCAQYCAQAwXTELMAkGA1UEBhMCU0cxETAPBgNVBAoTCE0yQ3J5cHRvMRIw EAYDVQQDEwlsb2NhbGhvc3QxJzAlBgkqhkiG9w0BCQEWGGFkbWluQHNlcnZlci5l eGFtcGxlLmRvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAr1nYY1Qrll1r uB/FqlCRrr5nvupdIN+3wF7q915tvEQoc74bnu6b8IbbGRMhzdzmvQ4SzFfVEAuM MuTHeybPq5th7YDrTNizKKxOBnqE2KYuX9X22A1Kh49soJJFg6kPb9MUgiZBiMlv tb7K3CHfgw5WagWnLl8Lb+ccvKZZl+8CAwEAAaAAMA0GCSqGSIb3DQEBBAUAA4GB AHpoRp5YS55CZpy+wdigQEwjL/wSluvo+WjtpvP0YoBMJu4VMKeZi405R7o8oEwi PdlrrliKNknFmHKIaCKTLRcU59ScA6ADEIWUzqmUzP5Cs6jrSRo3NKfg1bd09D1K 9rsQkRc9Urv9mRBIsredGnYECNeRaK5R1yzpOowninXC -----END CERTIFICATE REQUEST----- So to address both use cases I propose that the INI interface would implement the following logic: Read a line from the INI file into buffer Label: IF the NEW LINE indicator is present at the end of the buffer THEN IF indicator shows that the NEW LINES should be stripped THEN 1) The indicator is stripped and end of line character(s) are stripped 2) Next line is read and appended to the value. 3) Goto Label ELSE IF indicator shows that the NEW LINES should not be stripped THEN 1) The indicator is stripped and end of line character(s) are stripped 2) In place of the stripped data the new line character is inserted 3) Next line is read and appended to the value. 4) Goto Label ELSE ERROR ENDIF ELSE We are done with this value. ENDIF Now let us talk about the NEW LINE indicator. I think of it as a sequence of characters that indicate that we have a multi-line value that either should have or should not have the new line symbol as part of the resulting concatenated string. It can be a symbol, series of symbols or a pattern. The most logical and most convenient, as it seems to me, (and this is where I heard some resistance) would be the following patterns: a) New line indicator that does not preserve new line is a sequence of a back slash and any spaces or tabs after it. Example (notice that there are spaces after slash): key = my long multi line value \ that I want to split in the ini file \ between different lines for readability. b) New line indicator that preserves new line is a sequence of a back slash and symbol 'n' and any spaces or tabs after it. Example (notice that there are spaces after 'n' ): key = my long multi line value with \n the preserved new lines because this \n is the format my application expects. I heard some concerns that these patterns should not be used the way I propose since some other applications like make allow no spaces after "\". But I do not see how my approach harms? It allows those who made a mistake of putting space after slash not being punished. The spaces at the end are irrelevant so why I should punish the users of the INI interface and applications built on top of it for putting a space that has no meaning and is tripped anyways. May be I should use some other patterns instead so that someone does not confuse with the escaping? Like: key = my long multi line value + that I want to split in the ini file + between different lines for readability. And key = my long multi line value with & the preserved new lines because this & is the format my application expects. Comments and suggestions welcome! Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/

8 17

[Transifex] File submitted via email to SSSD | master
by admin＠transifex.net 15 Apr '10

15 Apr '10

Hello sssd, this is Transifex at http://www.transifex.net. The following attached files were submitted to SSSD | master by logan <logan(a)fedoraproject.org> Please, visit Transifex at http://www.transifex.net/projects/p/sssd/c/master/ in order to see the component page. Thank you, Transifex

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

sssd-devel April 2010