openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

Re: (ITS#4750) libldap initialization of ~/.ldaprc and setuid
by hyc＠symas.com 15 Nov '06

15 Nov '06

quanah(a)stanford.edu wrote: > --On Tuesday, November 14, 2006 5:06 AM +0000 Kurt(a)OpenLDAP.org wrote: > > >> I note that nss/pam-ldap setting NOINIT (or otherwise mucking >> with libldap options) might break LDAP-enabled programs. But >> that's another matter. >> >> Anyways, I think the only good fix (for this and many other >> larger problems) is a library redesign/rewrite. > > Okay. > > I note I don't find any mention of NOINIT in the nss_ldap or pam_ldap > source, maybe it was removed at some point? I'm looking at the latest code > from PADL. > > Unless you mean patching nss_ldap/pam_ldap to set "LDAPNOINIT" in the > environment? Which has other problems. For the specific case of nss/pam_ldap the obvious solution is to require that they never use default values anywhere. Generally that is already what happens anyway. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4752) back-config Adds are not atomic
by hyc＠OpenLDAP.org 15 Nov '06

15 Nov '06

Full_Name: Howard Chu Version: HEAD/23/24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.168.84.21) Submitted by: hyc When LDAPAdding various types of entries under cn=config, failures in some later portion of the entry will cause the operation to fail but anything already set remains set. The current approach of using check_vals to validate before doing the main processing is inadequate. It may be possible to extend the current pre-check approach, otherwise we'll need to do something like define destructors for everything.

1 0

(ITS#4751) back-perl crashing with anonymous search request
by rhafer＠suse.de 14 Nov '06

14 Nov '06

Full_Name: Ralf Haferkamp Version: HEAD, RE23 OS: SUSE Linux 10.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.155.116) I created a simple back-perl setup with the SampleLDAP.pm Module (slightly enhanced with a bind() method that just returns SUCCESS) from CVS Head and slapd crashed on me immediately on receiving the first anonymous search request. It survived however when I issued bind requests followed by search request. While digging through the code I found that back_perl_bind calls "PERL_SET_CONTEXT( PERL_INTERPRETER );" since a few revisions. All other back_perl_* functions (search, delete, modify, ...) do not call PERL_SET_CONTEXT, adding that seems to fix the crash. The perlembed man-pages state related to PERL_SET_CONTEXT: "PERL_SET_CONTEXT(interp) should also be called whenever "interp" is used by a thread that did not create it (using either perl_alloc(), ..." I'll commit a fix that adds PERL_SET_CONTEXT calls to the other functions as well (wrapped behind #ifdefs just like in back_perl_bind()).

1 0

Re: (ITS#4750) libldap initialization of ~/.ldaprc and setuid
by quanah＠stanford.edu 14 Nov '06

14 Nov '06

--On Tuesday, November 14, 2006 5:06 AM +0000 Kurt(a)OpenLDAP.org wrote: > I note that nss/pam-ldap setting NOINIT (or otherwise mucking > with libldap options) might break LDAP-enabled programs. But > that's another matter. > > Anyways, I think the only good fix (for this and many other > larger problems) is a library redesign/rewrite. Okay. I note I don't find any mention of NOINIT in the nss_ldap or pam_ldap source, maybe it was removed at some point? I'm looking at the latest code from PADL. Unless you mean patching nss_ldap/pam_ldap to set "LDAPNOINIT" in the environment? Which has other problems. >From the source of libldap: init.c: if( getenv("LDAPNOINIT") != NULL ) { --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4750) libldap initialization of ~/.ldaprc and setuid
by Kurt＠OpenLDAP.org 14 Nov '06

14 Nov '06

It was my intent when ldap.conf(5) was designed that it only provide defaults when selected by the user. For instance, a hostname when the user provides none. While libldap always read ldap.conf/.ldaprc, that wasn't considered a big deal. However, with various init options which are used without program selection, programs need now to provide an option to disable initialization. Ugh. I have noted that if I had to do it all over again, libldap would never read ldap.conf(5). Instead the program would have to separately call out to facility to obtain defaults. Some of RRA suggests are not workable. For instance, as now some options can only be set via ldap.conf(5)/.ldaprc, disabling it for root disallows root to use all features of programs and the library. But this is all water under the bridge. The library is what it is. Changing it would likely break other things. I note that nss/pam-ldap setting NOINIT (or otherwise mucking with libldap options) might break LDAP-enabled programs. But that's another matter. Anyways, I think the only good fix (for this and many other larger problems) is a library redesign/rewrite. Kurt At 08:04 PM 11/13/2006, quanah(a)stanford.edu wrote: >Full_Name: Quanah Gibson-Mount >Version: All >OS: NA >URL: >Submission from: (NULL) (171.66.155.86) > > >The debian folks committed the following patch: > >Modified: openldap/trunk-2.1/libraries/libldap/init.c >=================================================================== >--- openldap/trunk-2.1/libraries/libldap/init.c 2006-11-12 10:08:20 UTC (rev >749) >+++ openldap/trunk-2.1/libraries/libldap/init.c 2006-11-14 00:54:38 UTC (rev >750) >@@ -252,6 +252,12 @@ > char *home; > char *path = NULL; > >+ if (getuid() != geteuid()) { >+ /* Caller is setuid -- don't read any per-user configs in >+ these circumstances, as this may not be safe */ >+ return; >+ } >+ > if (file == NULL) { > /* no file name */ > return; > > >You can see this is against 2.1, but the code is essentially the same in OL >HEAD. > >The reason was: > >+ * Don't check for user configuration files when the caller is setuid; >+ addresses #387467, which is a potential security hole allowing >+ libnss-ldap settings to be overridden. Thanks to Stephen Frost for >+ bringing this to my attention. > > >which Howard note is not really the right way to do this. > >[19:07] Howard Chu: that's the wrong fix >[19:07] Howard Chu: libnss-ldap should set NOINIT for its own usage. >[19:09] Quanah: so this patch doesn't really fix anything? >[19:09] Howard Chu: probably not. > > >However, one of my co-workers notes: > > >19:48 <rra@home> Well, I appreciate Howard's opinion here, but that's a crappy >fix because it means that every single binary that uses the LDAP libraries > and may be setuid has to know to do this. >19:49 <rra@home> libnss-ldap should *also* set NOINIT, of course. >19:50 <rra@home> It sounded like it was reading dotfiles out of the user's home >directory, though. >19:50 <rra@home> Is that really what it's doing? >19:50 <rra@home> Something along those lines? >19:50 <Q> http://www.openldap.org/devel/cvsweb.cgi/libraries/libldap/init.c?hideattic… >19:50 <Q> it can read .ldaprc, yes >19:50 <rra@home> Libraries reading dotfiles is all by itself pretty evil. >19:51 <rra@home> That to me violates abstraction layers. >19:51 <rra@home> Applications are not going to expect libraries to do that. >19:51 <rra@home> The *right* solution would to me be to not do that; failing >that, I think OpenLDAP should bear the responsibility to do it securely, which > would include not reading user .ldaprc files when running as root. (There >are other ways to prevent that, of course.) >19:55 <rra@home> Basically, my argument is more that there should be a mode that >loads user configuration, but it probably shouldn't be the default > interface. >19:55 <rra@home> Anyway, Howard's certainly right that libnss-ldap needs to be >fixed regardless to pass that flag. > > >So, thoughts appreciated. > >--Quanah

1 0

(ITS#4750) libldap initialization of ~/.ldaprc and setuid
by quanah＠stanford.edu 14 Nov '06

14 Nov '06

Full_Name: Quanah Gibson-Mount Version: All OS: NA URL: Submission from: (NULL) (171.66.155.86) The debian folks committed the following patch: Modified: openldap/trunk-2.1/libraries/libldap/init.c =================================================================== --- openldap/trunk-2.1/libraries/libldap/init.c 2006-11-12 10:08:20 UTC (rev 749) +++ openldap/trunk-2.1/libraries/libldap/init.c 2006-11-14 00:54:38 UTC (rev 750) @@ -252,6 +252,12 @@ char *home; char *path = NULL; + if (getuid() != geteuid()) { + /* Caller is setuid -- don't read any per-user configs in + these circumstances, as this may not be safe */ + return; + } + if (file == NULL) { /* no file name */ return; You can see this is against 2.1, but the code is essentially the same in OL HEAD. The reason was: + * Don't check for user configuration files when the caller is setuid; + addresses #387467, which is a potential security hole allowing + libnss-ldap settings to be overridden. Thanks to Stephen Frost for + bringing this to my attention. which Howard note is not really the right way to do this. [19:07] Howard Chu: that's the wrong fix [19:07] Howard Chu: libnss-ldap should set NOINIT for its own usage. [19:09] Quanah: so this patch doesn't really fix anything? [19:09] Howard Chu: probably not. However, one of my co-workers notes: 19:48 <rra@home> Well, I appreciate Howard's opinion here, but that's a crappy fix because it means that every single binary that uses the LDAP libraries and may be setuid has to know to do this. 19:49 <rra@home> libnss-ldap should *also* set NOINIT, of course. 19:50 <rra@home> It sounded like it was reading dotfiles out of the user's home directory, though. 19:50 <rra@home> Is that really what it's doing? 19:50 <rra@home> Something along those lines? 19:50 <Q> http://www.openldap.org/devel/cvsweb.cgi/libraries/libldap/init.c?hideattic… 19:50 <Q> it can read .ldaprc, yes 19:50 <rra@home> Libraries reading dotfiles is all by itself pretty evil. 19:51 <rra@home> That to me violates abstraction layers. 19:51 <rra@home> Applications are not going to expect libraries to do that. 19:51 <rra@home> The *right* solution would to me be to not do that; failing that, I think OpenLDAP should bear the responsibility to do it securely, which would include not reading user .ldaprc files when running as root. (There are other ways to prevent that, of course.) 19:55 <rra@home> Basically, my argument is more that there should be a mode that loads user configuration, but it probably shouldn't be the default interface. 19:55 <rra@home> Anyway, Howard's certainly right that libnss-ldap needs to be fixed regardless to pass that flag. So, thoughts appreciated. --Quanah

1 0

Re: (ITS#4747) Function nisNetgroupTripleValidate fails on underscores
by temp1＠ips.gov.au 13 Nov '06

13 Nov '06

G'Day Kurt Yes, RFC 2307 is restrictive re: limiting the legal character set for the nisNetgroupTripleSyntax values to a "keystring" (ref: RFC 2252). What I find irksome probably boils down to:- Since LDAP was originally designed to gateway requests to X.500 servers that the character set of an IA5String should be legal. (RFC 2307, section 2.4, X.500 nisNetgroupTripleSyntax) With the added twist of the knife, that underscores are legal in the user CN's when doing the nisMapName=netgroup.byuser Note: OS specific "bad chars" still need to be taken into account by the implementer. Since the "nisNetgroupTripleSyntax" is unlikely to change from "keystring" to IA5String in the near future for OpenLDAP, I think I'll have to consider our options re: netgroup configuration and use. Regards IT Manager 2 Kurt D. Zeilenga wrote: > At 09:26 PM 11/12/2006, temp1(a)ips.gov.au wrote: >> Full_Name: IT Manager 2 >> Version: 2.3 & 2.4 >> OS: FreeBSD 6.2-PRERELEASE #0: Thu Oct 19 11:23:22 EST 2006 >> URL: >> Submission from: (NULL) (220.233.132.66) >> >> >> Src ./servers/slapd/schema_init.c >> Function nisNetgroupTripleValidate >> >> Fails validate of NIS Netgroup triplet when an underscore is used in a username, >> hostname or domainname. > > I believe this is the intended behavior. > >> Which is allowable ie username bad chars are " ,\t:+&#%$^()!@~*?<>=|\\/\"". > > RFC 2307 is more restrictive. > > >> suggest change line >> } else if ( !AD_CHAR( *p ) ) { >> to >> } else if ( !(AD_CHAR( *p ) || (*p) == '_' ) ) { >> >> Regards >> IT Manager 2 > >

1 0

Re: (ITS#4749) Missed option in ldap.conf(5)
by ando＠sys-net.it 13 Nov '06

13 Nov '06

Kurt(a)OpenLDAP.org wrote: > Same applies to timeouts as well. Basically, items are intended > to provide defaults for applications which say "use default". > Having options, such as this and various timeouts, which get used > by the library without application saying "use default" are > quite problematic and should be avoided. > See my comment above; ldap.conf(5) sounds like a good place to put parameters that existing applications wouldn't allow. Maybe allowing things like timeouts as user-only would be a solution, since a user can force LDAPCONF for specific applications and alter their behavior. By now, I'd remove the RESTART option but leave the NETWORK_TIMEOUT in place. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4749) Missed option in ldap.conf(5)
by ando＠sys-net.it 13 Nov '06

13 Nov '06

hyc(a)symas.com wrote: > As I recall there was some debate about making this available in > ldap.conf, since setting it globally can break some applications that > aren't expecting one behavior or another. I believe the option should > remain undocumented, and the support for parsing it from ldap.conf > should likely be removed. It should only be available when a program > specifically requests it via ldap_set_option. > OK; I don't recall discussions about that. I've cleaned up code and man pages in HEAD. Maybe parsing could be only allowed from user files, but right now I'm just removing it. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4749) Missed option in ldap.conf(5)
by Kurt＠OpenLDAP.org 13 Nov '06

13 Nov '06

At 02:16 PM 11/13/2006, hyc(a)symas.com wrote: >As I recall there was some debate about making this available in >ldap.conf, since setting it globally can break some applications that >aren't expecting one behavior or another. I believe the option should >remain undocumented, and the support for parsing it from ldap.conf >should likely be removed. It should only be available when a program >specifically requests it via ldap_set_option. Same applies to timeouts as well. Basically, items are intended to provide defaults for applications which say "use default". Having options, such as this and various timeouts, which get used by the library without application saying "use default" are quite problematic and should be avoided. Kurt

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs