- openldap-bugs - openldap.org

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

13 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 13 Nov '06

13 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 13 Nov '06

13 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

Re: (ITS#4749) Missed option in ldap.conf(5)
by hyc＠symas.com 13 Nov '06

13 Nov '06

ando(a)sys-net.it wrote: > tiamat(a)komi.mts.ru wrote: >> Full_Name: Alex Deiter >> Version: 2.3.29 >> OS: Solaris 9 sparc >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (217.66.145.224) >> >> >> Hi, >> >> I have found undocumented parameter for ldap.conf in libraries/libldap/init.c: >> RESTART, >> and has written the missed section for ldap.conf(5): >> >> ftp://ftp.openldap.org/incoming/alex-deiter-061111.patch >> > This option has been recently documented in ldap_get_option(3), but > honestly it's not clear to me what its intended usage is. I'll check > your patch and eventually apply it to HEAD. 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. -- -- 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

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

13 Nov '06

tiamat(a)komi.mts.ru wrote: > Full_Name: Alex Deiter > Version: 2.3.29 > OS: Solaris 9 sparc > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (217.66.145.224) > > > Hi, > > I have found undocumented parameter for ldap.conf in libraries/libldap/init.c: > RESTART, > and has written the missed section for ldap.conf(5): > > ftp://ftp.openldap.org/incoming/alex-deiter-061111.patch > This option has been recently documented in ldap_get_option(3), but honestly it's not clear to me what its intended usage is. I'll check your patch and eventually apply it to HEAD. Thanks, p.

1 0

Re: (ITS#4748) Implement [NETWORK_]TIMEOUT options for ldap.conf
by ando＠sys-net.it 13 Nov '06

13 Nov '06

tiamat(a)komi.mts.ru wrote: > Full_Name: Alex Deiter > Version: 2.3.29 > OS: Solaris 9 sparc > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (217.66.145.224) > > > Hi, > > Please review my patch which implement two new ldap.conf options: TIMEOUT and > NETWORK_TIMEOUT. These options are very useful to the wide list of applications, > which do not operate these parameters directly: samba, isc dhcp/bind, sendmail > and many other things. > > I offer two variants: with use ldap_set_option: > > ftp://ftp.openldap.org/incoming/alex-deiter-061112.patch > > and without it: > > ftp://ftp.openldap.org/incoming/alex-deiter-061113.patch > Usually, only patches for HEAD code are considered, unless they are specifically intended to fix bugs in release code. TIMEOUT is right now unused in the code; have no idea what it was originally intended for. Support for NETWORK_TIMEOUT in ldap.conf is already implemented in HEAD; OpenLDAP 2.3 is feature frozen, so it's unlikely that it will be backported, as it's not a major bug but rather a missing feature. p.

1 0

(ITS#4749) Missed option in ldap.conf(5)
by tiamat＠komi.mts.ru 13 Nov '06

13 Nov '06

Full_Name: Alex Deiter Version: 2.3.29 OS: Solaris 9 sparc URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.66.145.224) Hi, I have found undocumented parameter for ldap.conf in libraries/libldap/init.c: RESTART, and has written the missed section for ldap.conf(5): ftp://ftp.openldap.org/incoming/alex-deiter-061111.patch Thanks a lot!

1 0

(ITS#4748) Implement [NETWORK_]TIMEOUT options for ldap.conf
by tiamat＠komi.mts.ru 13 Nov '06

13 Nov '06

Full_Name: Alex Deiter Version: 2.3.29 OS: Solaris 9 sparc URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.66.145.224) Hi, Please review my patch which implement two new ldap.conf options: TIMEOUT and NETWORK_TIMEOUT. These options are very useful to the wide list of applications, which do not operate these parameters directly: samba, isc dhcp/bind, sendmail and many other things. I offer two variants: with use ldap_set_option: ftp://ftp.openldap.org/incoming/alex-deiter-061112.patch and without it: ftp://ftp.openldap.org/incoming/alex-deiter-061113.patch Thanks a lot!

1 0

Re: (ITS#4747) Function nisNetgroupTripleValidate fails on underscores
by Kurt＠OpenLDAP.org 12 Nov '06

12 Nov '06

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

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

12 Nov '06

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. Which is allowable ie username bad chars are " ,\t:+&#%$^()!@~*?<>=|\\/\"". suggest change line } else if ( !AD_CHAR( *p ) ) { to } else if ( !(AD_CHAR( *p ) || (*p) == '_' ) ) { Regards IT Manager 2

1 0

(ITS#4746) memory leak in syncrepl consumer
by hyc＠OpenLDAP.org 12 Nov '06

12 Nov '06

Full_Name: Howard Chu Version: RE23 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.168.84.21) Submitted by: hyc syncrepl_updateCookie leaks the CSN that it queues up. Detected with valgrind.

1 0

Re: (ITS#4742) parameter unique_attributes and unknown attribute types
by hyc＠symas.com 11 Nov '06

11 Nov '06

Pierangelo Masarati wrote: > Howard Chu wrote: >> OK. And we have usually used DEBUG_ANY for fatal messages of this >> type. The point I'm making now is that config errors are no longer >> always fatal; it depends on whether we're starting up or already running. > But right now all errors like that are LDAP_DEBUG_CONFIG. Since tools > now run with LDAP_DEBUG_NONE set, ORin LDAP_DEBUG_NONE to fatal messages > would let them always pop up with tools __and__ run-time; run-time it > shouldn't be a big deal, it's just another informative message in the > logs; with the tools it should make the difference. I have no > preference for either way: add LDAP_DEBUG_CONFIG_FATAL, enabled by > default in tools, or OR config messages with LDAP_DEBUG_NONE. OK, that makes sense. Perhaps we should define LDAP_DEBUG_ERROR (or _FATAL) as an alias of LDAP_DEBUG_NONE. -- -- 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

Re: (ITS#4742) parameter unique_attributes and unknown attribute types
by ando＠sys-net.it 11 Nov '06

11 Nov '06

Howard Chu wrote: > OK. And we have usually used DEBUG_ANY for fatal messages of this > type. The point I'm making now is that config errors are no longer > always fatal; it depends on whether we're starting up or already running. But right now all errors like that are LDAP_DEBUG_CONFIG. Since tools now run with LDAP_DEBUG_NONE set, ORin LDAP_DEBUG_NONE to fatal messages would let them always pop up with tools __and__ run-time; run-time it shouldn't be a big deal, it's just another informative message in the logs; with the tools it should make the difference. I have no preference for either way: add LDAP_DEBUG_CONFIG_FATAL, enabled by default in tools, or OR config messages with LDAP_DEBUG_NONE. 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#4742) parameter unique_attributes and unknown attribute types
by hyc＠symas.com 11 Nov '06

11 Nov '06

ando(a)sys-net.it wrote: > hyc(a)symas.com wrote: >> Another possibility would be to always enable LDAP_DEBUG_CONFIG for the >> tools. The only reason I suggest this is because I would prefer that >> runtime configuration errors are only logged when specifically >> requested, not at DEBUG_ANY. Since the error messages are already >> returnes to the client in the protocol, it's not always necessary to log >> them separately. >> > The point is that I'd like to separate informative messages about > configuration (LDAP_DEBUG_CONFIG) from __the__ message that described > why slaptest failed (or slapd refuses to start). Right now, either you > get all (which is annoying) or none (which is frustrating). Apparently, > unless we hijack LDAP_DEBUG_NONE for the duration of config parsing, and > OR it to all messages followed by "return ARG_BAD_CONF;", we need > another LDAP_DEBUG_*. OK. And we have usually used DEBUG_ANY for fatal messages of this type. The point I'm making now is that config errors are no longer always fatal; it depends on whether we're starting up or already running. -- -- 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

Re: (ITS#4742) parameter unique_attributes and unknown attribute types
by ando＠sys-net.it 11 Nov '06

11 Nov '06

hyc(a)symas.com wrote: > Another possibility would be to always enable LDAP_DEBUG_CONFIG for the > tools. The only reason I suggest this is because I would prefer that > runtime configuration errors are only logged when specifically > requested, not at DEBUG_ANY. Since the error messages are already > returnes to the client in the protocol, it's not always necessary to log > them separately. > The point is that I'd like to separate informative messages about configuration (LDAP_DEBUG_CONFIG) from __the__ message that described why slaptest failed (or slapd refuses to start). Right now, either you get all (which is annoying) or none (which is frustrating). Apparently, unless we hijack LDAP_DEBUG_NONE for the duration of config parsing, and OR it to all messages followed by "return ARG_BAD_CONF;", we need another LDAP_DEBUG_*. 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#4742) parameter unique_attributes and unknown attribute types
by hyc＠symas.com 11 Nov '06

11 Nov '06

ando(a)sys-net.it wrote: > michael(a)stroeder.com wrote: >> It seems that slapd stops without configuration error message if unknown >> attribute types are set for parameter unique_attributes (slapo-unique). It would >> be nice if a descriptive message is displayed (like in other cases). >> > I think this occurs if debug is set to "config" or "-1". However, it > would be more appropriate to log configuration errors that result in > failures at "any", so that whatever logging is set they show up. For > this purpose, many of the current occurrences of LDAP_DEBUG_CONFIG > should be turned into (LDAP_DEBUG_CONFIG | LDAP_DEBUG_NONE), so that > they show up when caught by tools with default logging (e.g. > slaptest(8)), or into LDAP_DEBUG_ANY, so that they show up all times. > I'd vote for the latter. Another possibility would be to always enable LDAP_DEBUG_CONFIG for the tools. The only reason I suggest this is because I would prefer that runtime configuration errors are only logged when specifically requested, not at DEBUG_ANY. Since the error messages are already returnes to the client in the protocol, it's not always necessary to log them separately. -- -- 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

Re: (ITS#4745) libslapi undefined symbols
by quanah＠stanford.edu 11 Nov '06

11 Nov '06

--On Saturday, November 11, 2006 9:10 PM +0000 hyc(a)symas.com wrote: > quanah(a)stanford.edu wrote: >> Full_Name: Quanah Gibson-Mount >> Version: 2.3.28 >> OS: Linux 2.6 64-bit >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (171.66.155.86) >> >> >> When building OpenLDAP 2.3.28, I found that libslapi is full of undefined >> symbols. Is it not being linked correctly? >> > Do you actually have a slapi plugin that isn't working? There's no > evidence of a bug here. Most dynamic libraries that depend on other > objects are full of undefined symbols. Nope, I don't use slapi at all, other than to enable it to disable the broken acl cacheing in 2.3. Thanks. --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#4745) libslapi undefined symbols
by hyc＠symas.com 11 Nov '06

11 Nov '06

quanah(a)stanford.edu wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.3.28 > OS: Linux 2.6 64-bit > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (171.66.155.86) > > > When building OpenLDAP 2.3.28, I found that libslapi is full of undefined > symbols. Is it not being linked correctly? > Do you actually have a slapi plugin that isn't working? There's no evidence of a bug here. Most dynamic libraries that depend on other objects are full of undefined symbols. -- -- 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#4745) libslapi undefined symbols
by quanah＠stanford.edu 11 Nov '06

11 Nov '06

Full_Name: Quanah Gibson-Mount Version: 2.3.28 OS: Linux 2.6 64-bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.66.155.86) When building OpenLDAP 2.3.28, I found that libslapi is full of undefined symbols. Is it not being linked correctly? ldap-uat00:/usr/local/stow/openldap-2.3.28.9-gcc411/lib> ldd libslapi.so libc.so.6 => /lib/libc.so.6 (0x00002b58357d6000) /lib64/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x0000555555554000) ldap-uat00:/usr/local/stow/openldap-2.3.28.9-gcc411/lib> ldd -r -d libslapi-2.3.so.0.2.16 libc.so.6 => /lib/libc.so.6 (0x00002adf05784000) /lib64/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x0000555555554000) undefined symbol: slap_schema (./libslapi-2.3.so.0.2.16) undefined symbol: sockbuf_max_incoming (./libslapi-2.3.so.0.2.16) undefined symbol: ch_mfuncs (./libslapi-2.3.so.0.2.16) undefined symbol: slap_send_ldap_extended (./libslapi-2.3.so.0.2.16) undefined symbol: slap_cids (./libslapi-2.3.so.0.2.16) undefined symbol: slap_unknown_bv (./libslapi-2.3.so.0.2.16) undefined symbol: frontendDB (./libslapi-2.3.so.0.2.16) undefined symbol: sockbuf_max_incoming_auth (./libslapi-2.3.so.0.2.16) undefined symbol: local_ssf (./libslapi-2.3.so.0.2.16) undefined symbol: slap_debug (./libslapi-2.3.so.0.2.16) undefined symbol: slap_send_search_entry (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_syslog_level (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_syslog (./libslapi-2.3.so.0.2.16) undefined symbol: slap_send_ldap_result (./libslapi-2.3.so.0.2.16) undefined symbol: slap_send_search_reference (./libslapi-2.3.so.0.2.16) undefined symbol: entry2str_mutex (./libslapi-2.3.so.0.2.16) undefined symbol: be_isroot (./libslapi-2.3.so.0.2.16) undefined symbol: slapi_plugins_used (./libslapi-2.3.so.0.2.16) undefined symbol: be_slurp_update (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_pvt_thread_cond_init (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_pvt_thread_cond_broadcast (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_mods_free (./libslapi-2.3.so.0.2.16) undefined symbol: lutil_strcopy (./libslapi-2.3.so.0.2.16) undefined symbol: slap_mods_check (./libslapi-2.3.so.0.2.16) undefined symbol: value_add_one (./libslapi-2.3.so.0.2.16) undefined symbol: attr_merge_normalize_one (./libslapi-2.3.so.0.2.16) undefined symbol: rdn_validate (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_pvt_thread_pool_context (./libslapi-2.3.so.0.2.16) undefined symbol: ber_dupbv (./libslapi-2.3.so.0.2.16) undefined symbol: get_supported_extop (./libslapi-2.3.so.0.2.16) undefined symbol: attr_merge_normalize (./libslapi-2.3.so.0.2.16) undefined symbol: ch_free (./libslapi-2.3.so.0.2.16) undefined symbol: modify_add_values (./libslapi-2.3.so.0.2.16) undefined symbol: ber_sockbuf_free (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_pvt_thread_cond_signal (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_pvt_thread_mutex_unlock (./libslapi-2.3.so.0.2.16) undefined symbol: be_issuffix (./libslapi-2.3.so.0.2.16) undefined symbol: ch_calloc (./libslapi-2.3.so.0.2.16) undefined symbol: slap_sl_free (./libslapi-2.3.so.0.2.16) undefined symbol: anlist2charray_x (./libslapi-2.3.so.0.2.16) undefined symbol: ch_strdup (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_bv2rdn (./libslapi-2.3.so.0.2.16) undefined symbol: value_match (./libslapi-2.3.so.0.2.16) undefined symbol: slap_str2ad (./libslapi-2.3.so.0.2.16) undefined symbol: overlay_is_inst (./libslapi-2.3.so.0.2.16) undefined symbol: ber_bvfree (./libslapi-2.3.so.0.2.16) undefined symbol: is_ad_subtype (./libslapi-2.3.so.0.2.16) undefined symbol: access_allowed_mask (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_pvt_thread_mutex_destroy (./libslapi-2.3.so.0.2.16) undefined symbol: dnExtractRdn (./libslapi-2.3.so.0.2.16) undefined symbol: send_ldap_sasl (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_charray_dup (./libslapi-2.3.so.0.2.16) undefined symbol: register_supported_control (./libslapi-2.3.so.0.2.16) undefined symbol: slap_mods2entry (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_pvt_thread_cond_wait (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_rdnfree (./libslapi-2.3.so.0.2.16) undefined symbol: ber_bvarray_add (./libslapi-2.3.so.0.2.16) undefined symbol: be_entry_get_rw (./libslapi-2.3.so.0.2.16) undefined symbol: dnPrettyNormal (./libslapi-2.3.so.0.2.16) undefined symbol: select_backend (./libslapi-2.3.so.0.2.16) undefined symbol: dnParent (./libslapi-2.3.so.0.2.16) undefined symbol: lt_dlerror (./libslapi-2.3.so.0.2.16) undefined symbol: attr_delete (./libslapi-2.3.so.0.2.16) undefined symbol: be_entry_release_rw (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_bv2dn (./libslapi-2.3.so.0.2.16) undefined symbol: str2entry (./libslapi-2.3.so.0.2.16) undefined symbol: dnNormalize (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_initialize (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_pvt_thread_mutex_lock (./libslapi-2.3.so.0.2.16) undefined symbol: get_supported_controls (./libslapi-2.3.so.0.2.16) undefined symbol: lt_dlclose (./libslapi-2.3.so.0.2.16) undefined symbol: entry_alloc (./libslapi-2.3.so.0.2.16) undefined symbol: slap_parse_ctrl (./libslapi-2.3.so.0.2.16) undefined symbol: entry2str (./libslapi-2.3.so.0.2.16) undefined symbol: entry_dup (./libslapi-2.3.so.0.2.16) undefined symbol: slap_entry2mods (./libslapi-2.3.so.0.2.16) undefined symbol: overlay_op_walk (./libslapi-2.3.so.0.2.16) undefined symbol: rdnNormalize (./libslapi-2.3.so.0.2.16) undefined symbol: str2filter (./libslapi-2.3.so.0.2.16) undefined symbol: filter_free (./libslapi-2.3.so.0.2.16) undefined symbol: attr_find (./libslapi-2.3.so.0.2.16) undefined symbol: ber_sockbuf_alloc (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_rdn2bv (./libslapi-2.3.so.0.2.16) undefined symbol: entry_free (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_dnfree (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_str2rdn (./libslapi-2.3.so.0.2.16) undefined symbol: dnIsSuffix (./libslapi-2.3.so.0.2.16) undefined symbol: rdnMatch (./libslapi-2.3.so.0.2.16) undefined symbol: ber_bvarray_free (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_unbind_ext_s (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_charray_free (./libslapi-2.3.so.0.2.16) undefined symbol: test_filter (./libslapi-2.3.so.0.2.16) undefined symbol: lt_dlopen (./libslapi-2.3.so.0.2.16) undefined symbol: overlay_register (./libslapi-2.3.so.0.2.16) undefined symbol: modify_delete_values (./libslapi-2.3.so.0.2.16) undefined symbol: attr_free (./libslapi-2.3.so.0.2.16) undefined symbol: backend_connection_init (./libslapi-2.3.so.0.2.16) undefined symbol: build_new_dn (./libslapi-2.3.so.0.2.16) undefined symbol: entry_schema_check (./libslapi-2.3.so.0.2.16) undefined symbol: ad_inlist (./libslapi-2.3.so.0.2.16) undefined symbol: filter2bv_x (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_pvt_thread_mutex_init (./libslapi-2.3.so.0.2.16) undefined symbol: ber_sockbuf_ctrl (./libslapi-2.3.so.0.2.16) undefined symbol: attr_dup (./libslapi-2.3.so.0.2.16) undefined symbol: connection_assign_nextid (./libslapi-2.3.so.0.2.16) undefined symbol: ch_realloc (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_controls_free (./libslapi-2.3.so.0.2.16) undefined symbol: mods_structural_class (./libslapi-2.3.so.0.2.16) undefined symbol: lt_dlsym (./libslapi-2.3.so.0.2.16) undefined symbol: filter_dup (./libslapi-2.3.so.0.2.16) undefined symbol: dnPretty (./libslapi-2.3.so.0.2.16) undefined symbol: slap_bv2ad (./libslapi-2.3.so.0.2.16) undefined symbol: acl_check_modlist (./libslapi-2.3.so.0.2.16) undefined symbol: dnMatch (./libslapi-2.3.so.0.2.16) undefined symbol: slap_mods_free (./libslapi-2.3.so.0.2.16) undefined symbol: ch_malloc (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_pvt_thread_cond_destroy (./libslapi-2.3.so.0.2.16) undefined symbol: lt_dlinit (./libslapi-2.3.so.0.2.16) undefined symbol: overlay_config (./libslapi-2.3.so.0.2.16)

1 0

Re: (ITS#4744) Bug in SASL authzTo validation using an ldap:// rule
by hyc＠symas.com 11 Nov '06

11 Nov '06

hyc(a)symas.com wrote: > ando(a)sys-net.it wrote: >> As far as I remember, that test is intended to prevent mapping when the >> search returns more than one entry. This makes perfectly sense, >> otherwise a SASL identity (or an authorization identity) would be >> arbitrarily mapped to one of the matching entries. So mapping is >> intended to succeed if and only if exactly one identity can be resolved. > > That test is only supposed to prevent mapping when doing an authzRegexp > mapping of a single SASL userID to a DN. When looking up > authzFrom/authzTo it is supposed to allow multiple results. > Interestingly, it looks like slap_sasl_match isn't even used for > authzRegexp mapping any more. Something is definitely broken here. > This behavior was changed in rev 1.126 of saslauthz.c. I believe the relevant portions of that patch need to be reverted. e.g. patch -R: diff -u -r1.125 -r1.126 --- saslauthz.c 26 Apr 2004 19:47:02 -0000 1.125 +++ saslauthz.c 26 Apr 2004 20:47:08 -0000 1.126 @@ -772,14 +802,26 @@ { smatch_info *sm = o->o_callback->sc_private; - if (rs->sr_type != REP_SEARCH) return 0; + if ( rs->sr_type != REP_SEARCH ) { + if ( rs->sr_err != LDAP_SUCCESS ) { + sm->match = -1; + } + return 0; + } + + if ( sm->match == 1 ) { + sm->match = -1; + return 0; + } if (dn_match(sm->dn, &rs->sr_entry->e_nname)) { sm->match = 1; - return -1; /* short-circuit the search */ + + } else { + sm->match = -1; } - return 1; + return 0; } /* @@ -984,7 +1026,7 @@ op.o_bd->be_search( &op, &rs ); - if (sm.match) { + if (sm.match == 1) { rc = LDAP_SUCCESS; } else { rc = LDAP_INAPPROPRIATE_AUTH; -- -- 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

Re: (ITS#4744) Bug in SASL authzTo validation using an ldap:// rule
by hyc＠symas.com 11 Nov '06

11 Nov '06

ando(a)sys-net.it wrote: > sylvain(a)pilotsystems.net wrote: >> Full_Name: Sylvain Viollon >> Version: 2.3 >> OS: FreeBSD 5 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (83.204.228.114) >> >> >> >> I have an directory with some users in ou=people,dc=pilotsystems,dc=net branch, >> having a custom class krbUser ; and a user (cn=auth,dc=pilotsystems,dc=net) >> having the following attribute : >> >> authzTo: ldap:///ou=people,dc=pilotsystems,dc=net??sub?(objectClass=krbUser) >> >> He can successfully authenticate, but not become an user listed by the search >> (with PROXYAUTHZ). Running slapd in debug-mode I saw that he can only become the >> last user returned by the search. >> >> In source, I read the file 'servers/slapd/saslauthz.c'. The filter >> 'sasl_sc_smatch' said if the wanted user is in the search result. In this >> function, there is a test : >> >> if ( sm->match == 1 ) { >> sm->match = -1; >> return 0; >> } >> >> I have removed the line : >> >> sm->match = -1; >> >> Which make the match to fail if there is an entry in the search return after the >> good one. Like every DN have to be unique, there is no multiple solution, and >> validation would not be discarded for that. I didn't know if it's a good >> solution, but it's work. >> >> > As far as I remember, that test is intended to prevent mapping when the > search returns more than one entry. This makes perfectly sense, > otherwise a SASL identity (or an authorization identity) would be > arbitrarily mapped to one of the matching entries. So mapping is > intended to succeed if and only if exactly one identity can be resolved. That test is only supposed to prevent mapping when doing an authzRegexp mapping of a single SASL userID to a DN. When looking up authzFrom/authzTo it is supposed to allow multiple results. Interestingly, it looks like slap_sasl_match isn't even used for authzRegexp mapping any more. Something is definitely broken here. -- -- 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs