openldap-bugs

openldap-bugs@openldap.org

1 participants
20995 discussions

(ITS#4982) link libldap_r explicitly with the threading libraries
by rra＠stanford.edu 24 May '07

24 May '07

Full_Name: Russ Allbery Version: 2.3.35 OS: Debian URL: Submission from: (NULL) (171.64.19.147) Since 2.2.23, Debian has been carrying the following patch to the libldap_r build process to explicitly link the library against the thread libraries. The comment at the time is: * libraries/libldap_r/Makefile.in: Code that uses pthreads *must* be linked with -pthread, even if it's a library; without this, the libldap_r library ends up with dangling unversioned reference to pthread_create() which gets resolved to a wrong version that causes segfaults on 64-bit platforms. Closes: #304549. See http://bugs.debian.org/304549 for the specific problems that this caused. --- openldap2.3-2.3.11~/libraries/libldap_r/Makefile.in 2005-12-01 13:48:50.000000000 +0100 +++ openldap2.3-2.3.11/libraries/libldap_r/Makefile.in 2005-12-02 10:05:17.637342000 +0100 @@ -56,7 +56,7 @@ XXLIBS = $(SECURITY_LIBS) $(LUTIL_LIBS) XXXLIBS = $(LTHREAD_LIBS) NT_LINK_LIBS = $(LDAP_LIBLBER_LA) $(AC_LIBS) $(SECURITY_LIBS) -UNIX_LINK_LIBS = $(LDAP_LIBLBER_LA) $(AC_LIBS) $(SECURITY_LIBS) +UNIX_LINK_LIBS = $(LDAP_LIBLBER_LA) $(AC_LIBS) $(SECURITY_LIBS) $(LTHREAD_LIBS) .links : Makefile @for i in $(XXSRCS); do \

1 0

(ITS#4981) Try -lpthread before -pthread
by rra＠stanford.edu 24 May '07

24 May '07

Full_Name: Russ Allbery Version: 2.3.35 OS: Debian URL: Submission from: (NULL) (171.64.19.147) Debian has been carrying the included patch for a while, originally added against 2.1.22 with: + Fixed the undefined symbols in libldap_r.so.2 (closes: #195990). | configure.in: Try -lpthread before -pthread to link the thread library. libtool does not pass -pthread through, -lpthread seems to work though. and then refreshed some time later against 2.2.23 with: * configure.in: reinstate the remainder of the fix for 195990 from 2.1.22-2: give preference to -lpthread over -pthread in configure.in, because some archs (mipsel, at least) don't like -pthread. A quick search of other ITSes didn't reveal this particular report, but it did look like people building on AIX were manually setting library flags that may produce the same result. I'm sure that none of Debian's platforms will break with -lpthread instead of -pthread since we've been using this for a while, although I'm not sure if that's sufficient. I'd ideally like to see Debian stop carrying this patch around as a divergence, particularly since it means that the package has to re-run Autoconf during the build. Index: openldap2.3/configure.in =================================================================== --- openldap2.3.orig/configure.in 2007-05-23 15:05:12.000000000 -0700 +++ openldap2.3/configure.in 2007-05-23 15:09:38.000000000 -0700 @@ -1489,6 +1489,7 @@ case $ol_with_threads in auto | yes | po dnl OL_PTHREAD_TRY([-mt], [ol_cv_pthread_mt]) OL_PTHREAD_TRY([-kthread], [ol_cv_pthread_kthread]) + OL_PTHREAD_TRY([-lpthread], [ol_cv_pthread_lpthread]) OL_PTHREAD_TRY([-pthread], [ol_cv_pthread_pthread]) OL_PTHREAD_TRY([-pthreads], [ol_cv_pthread_pthreads]) OL_PTHREAD_TRY([-mthreads], [ol_cv_pthread_mthreads])

1 0

Re: (ITS#4980) misaligned memory access (openssl?)
by hyc＠symas.com 23 May '07

23 May '07

richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: 2.3.35 > OS: Solaris 9 > URL: > Submission from: (NULL) (128.6.31.135) > > > OpenSSL 0.9.8e. slapd crashed with SIGBUS on Solaris/sparcv9, which almost > always means a misaligned memory access. Not sure if this is OpenLDAP's problem > or OpenSSL, but figured I'd at least track here (can always go bug the OpenSSL > guys if necessary)... This stack trace is pretty exclusively OpenSSL and libc code. Unless there's been a heap corruption somewhere, it appears to be an OpenSSL issue. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#4980) misaligned memory access (openssl?)
by richton＠nbcs.rutgers.edu 23 May '07

23 May '07

Full_Name: Aaron Richton Version: 2.3.35 OS: Solaris 9 URL: Submission from: (NULL) (128.6.31.135) OpenSSL 0.9.8e. slapd crashed with SIGBUS on Solaris/sparcv9, which almost always means a misaligned memory access. Not sure if this is OpenLDAP's problem or OpenSSL, but figured I'd at least track here (can always go bug the OpenSSL guys if necessary)... current thread: t@11 [1] t_delete(0x11c303480, 0x0, 0xffffffff7f268340, 0x2000, 0x2190, 0x1004e4290), at 0xffffffff7d24fab8 [2] _malloc_unlocked(0x80, 0x0, 0x0, 0x11ad552e0, 0x11ad552e0, 0x0), at 0xffffffff7d24f068 [3] malloc(0x80, 0xffffffff7e502458, 0xffffffff7e5014f0, 0xf68, 0x24fd00, 0xc00), at 0xffffffff7d24ee94 =>[4] CRYPTO_malloc(num = ???, file = ???, line = ???) (optimized), at 0xffffffff7e2b2274 (line ~304) in "mem.c" [5] bn_expand_internal(b = ???, words = ???) (optimized), at 0xffffffff7e308140 (line ~336) in "bn_lib.c" [6] BN_bin2bn(s = ???, len = ???, ret = ???) (optimized), at 0xffffffff7e308940 (line ~451) in "bn_lib.c" [7] RSA_eay_private_decrypt(flen = ???, from = ???, to = ???, rsa = ???, padding = ???) (optimized), at 0xffffffff7e32f160 (line ~517) in "rsa_eay.c" [8] ssl3_get_client_key_exchange(s = ???) (optimized), at 0xffffffff7e625150 (line ~1732) in "s3_srvr.c" [9] ssl3_accept(s = ???) (optimized), at 0xffffffff7e6227d0 (line ~449) in "s3_srvr.c" [10] ldap_pvt_tls_accept(sb = 0x11be3ac90, ctx_arg = 0x1004e4290), line 866 in "tls.c" [11] connection_read(s = 189), line 1348 in "connection.c" [12] slapd_daemon_task(ptr = (nil)), line 2359 in "daemon.c"

1 0

Re: (ITS#4958) slapd segfaults when overlay rwm, suffixmassage is used in conjunction with empty suffix
by nvoutsin＠noc.uoa.gr 23 May '07

23 May '07

Here is a simplified configuration that can be used to replicate the problem. I understand that such an error can not be easily triggered and in that sense might be considered as a low priority issue, but then again I believe it is worth mentioning. (I hope, I am not missing anything here...) # #include schemas here # access to dn.base="" by * read access to dn.base="cn=Subschema" by * read access to * by * none argsfile /var/openldap/run/slapd.args pidfile /var/openldap/run/slapd.pid loglevel any modulepath /opt/OpenLdap/sbin moduleload back_bdb.la moduleload back_relay.la moduleload rwm.la backend bdb database bdb suffix "dc=foo,dc=bar" rootdn "uid=manager,dc=foo,dc=bar" rootpw "secret" directory /var/openldap/bdb access to * by * read database relay suffix "" relay "dc=foo,dc=bar" massage access to * by * read As you can see from the logs below, ops like this one: SRCH base="dc=foo,dc=bar" scope=1 deref=0 filter="(objectClass=*)" SRCH attr=hasSubordinates objectClass fail, because slapd looks for an non-existent entry such as bdb_dn2entry("dc=foo,dc=bar,dc=foo,dc=bar"). The logs: ========= daemon: read activity on 11 connection_get(11) connection_get(11): got connid=0 connection_read(11): checking for input on id=0 daemon: select: listen=7 active_threads=0 tvp=NULL do_search >>> dnPrettyNormal: <dc=foo,dc=bar> <<< dnPrettyNormal: <dc=foo,dc=bar>, <dc=foo,dc=bar> SRCH "dc=foo,dc=bar" 1 0 0 0 0 begin get_filter PRESENT end get_filter 0 filter: (objectClass=*) => get_ctrls => get_ctrls: oid="2.16.840.1.113730.3.4.2" (noncritical) <= get_ctrls: n=1 rc=0 err="" attrs: hasSubordinates objectClass conn=0 op=5 SRCH base="dc=foo,dc=bar" scope=1 deref=0 filter="(objectClass=*)" conn=0 op=5 SRCH attr=hasSubordinates objectClass slap_global_control: unavailable control: 2.16.840.1.113730.3.4.2 ==> limits_get: conn=0 op=5 dn="uid=manager,dc=foo,dc=bar" [rw] searchDN: "dc=foo,dc=bar" -> "dc=foo,dc=bar,dc=foo,dc=bar" >>> dnPrettyNormal: <dc=foo,dc=bar,dc=foo,dc=bar> <<< dnPrettyNormal: <dc=foo,dc=bar,dc=foo,dc=bar>, <dc=foo,dc=bar,dc=foo,dc=bar> str2filter "(objectClass=*)" begin get_filter PRESENT end get_filter 0 => bdb_search bdb_dn2entry("dc=foo,dc=bar,dc=foo,dc=bar") => bdb_dn2id("dc=bar,dc=foo,dc=bar") <= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30989) send_ldap_result: conn=0 op=5 p=3 send_ldap_result: err=10 matched="dc=foo,dc=bar" text="" [rw] matchedDN: "dc=foo,dc=bar" -> "" >>> dnPretty: <> <<< dnPretty: <> send_ldap_response: msgid=6 tag=101 err=32 conn=0 op=5 SEARCH RESULT tag=101 err=32 nentries=0 text= Nikos Pierangelo Masarati wrote: > nvoutsin(a)noc.uoa.gr wrote: >> While slapd does not segfault anymore, slapd insists to concatenate >> unrelated database suffixes during search operations that look for attrs >> such as hasSubordinates. >> >> I mention this here because it seems to be related somehow > > As I could see it working as expected (by me, at least), I suggest you > cook a very simple example, consisting in two slapd.conf (one for the > remote server, and one for the offending mixed local-proxy-relay setup), > and as many data in LDIF format and submit it, so that you can show what > you consider an incorrect behavior. Otherwise, I don't see any further > indication of a bug. > > p. > > > > Ing. Pierangelo Masarati > OpenLDAP Core Team > > SysNet s.r.l. > 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#4976) memory corruption in test008-concurrency
by h.b.furuseth＠usit.uio.no 23 May '07

23 May '07

hyc(a)symas.com writes: > Try using ElectricFence, with my pthread patches. Still refuses to crash... -- Regards, Hallvard

1 0

Re: (ITS#4979) Bad response when requesting bad attributes
by hyc＠symas.com 22 May '07

22 May '07

Emmanuel Lecharny wrote: > Howard Chu a écrit : >> This works as designed - requesting an objectclass means to request >> all of the attributes included in that objectclass. In current >> revisions we expect objectClass names to be prefixed with "@" but the >> original behavior is still supported for backward compatibility. >> > Oh... Is there any RFC which expose this intended behaviour ? RFC 4529. This ITS will be closed. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#4979) Bad response when requesting bad attributes
by hyc＠symas.com 22 May '07

22 May '07

elecharny(a)apache.org wrote: > Full_Name: Emmanuel Lecharny > Version: 2.3.32 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.236.207.89) > > > When searching for entries using attributes to filter the result, you get all > the entries attributes if you give a wrong attribute : > > ldapsearch -h localhost -p 10389 -D "uid=Admin,ou=system" -w secret -b > "dc=example,dc=com" -s sub "(objectClass=*)" 9.9.9 > > will correctly returns only the DNs of all found entries, as if the 9.9.9 > attribute was 1.1 > > but > > ldapsearch -h localhost -p 10389 -D "uid=Admin,ou=system" -w secret -b > "dc=example,dc=com" -s sub "(objectClass=*)" person > > will return all entries attributes, as if the 'person' was substituted by "*" > > Of course, 'person' is not an attribute, but an objectClass, but the user intent > was to get only one single attribute value, so I don't think that returning > everything is correct. > > This is obviously not a serious issue. This works as designed - requesting an objectclass means to request all of the attributes included in that objectclass. In current revisions we expect objectClass names to be prefixed with "@" but the original behavior is still supported for backward compatibility. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#4979) Bad response when requesting bad attributes
by elecharny＠apache.org 22 May '07

22 May '07

Hallvard B Furuseth a écrit : >elecharny(a)apache.org writes: > > >>ldapsearch -h localhost -p 10389 -D "uid=Admin,ou=system" -w secret -b >>"dc=example,dc=com" -s sub "(objectClass=*)" person >> >>will return all entries attributes, as if the 'person' was substituted >>by "*" >> >> > >That is what RFC 4511 says. Section 4.5.1.8 (SearchRequest.attributes): > "If an attribute description in the list is not recognized, it is > ignored by the server." >Ignoring "person" yields an empty list, which works like a "*". > >I'm guessing that's not what it was intended to say though. RFC 1777 >(LDAPv2) did not have it, so 'person' would work like '1.1' does now. > > > Well, RFC 4511 just states that if the attribute is unknow, then it is ignored, but say nothing about using '1.1' or '*' . Ignoring the only attributes given by the user and substitute a '*' to it is a violation of user intent, IMHO (even if this user was wrong when selecting the attribute). RFC 4511 authors didn't thought of such a case, I guess ;) Anyway, OpenLdap behave differently if the attribute is unknown (9.9.9) and when it is known by the server (at least, the OID is known, even if it's not an attribute object), when it should returns always the same result : either '*' or '1.1'. This is not the case, and it's not consistent, whatever RFC 4511 says - or omits to say :) -. Emmanuel

1 0

Re: (ITS#4979) Bad response when requesting bad attributes
by h.b.furuseth＠usit.uio.no 22 May '07

22 May '07

elecharny(a)apache.org writes: > ldapsearch -h localhost -p 10389 -D "uid=Admin,ou=system" -w secret -b > "dc=example,dc=com" -s sub "(objectClass=*)" person > > will return all entries attributes, as if the 'person' was substituted > by "*" That is what RFC 4511 says. Section 4.5.1.8 (SearchRequest.attributes): "If an attribute description in the list is not recognized, it is ignored by the server." Ignoring "person" yields an empty list, which works like a "*". I'm guessing that's not what it was intended to say though. RFC 1777 (LDAPv2) did not have it, so 'person' would work like '1.1' does now. -- Regards, Hallvard

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