- openldap-bugs - openldap.org

Re: (ITS#4951) [contrib] RADIUS password module fixes
by richton＠nbcs.rutgers.edu 24 May '07

24 May '07

On Tue, 22 May 2007, Pierangelo Masarati wrote: > If that's an issue, I have no problem in explicitly setting that pointer > to NULL. I got some more dbx time on this, and it looks like that's a workaround for something that shouldn't be happening/needs to be fixed anyway. config_filename is always NULL at dlopen() time, just as it should be. Calling lock(&libradius_mutex) apparently overwrites config_filename, and explicitly initializing to NULL somehow stops this from happening. I can't see anything wrong with radius.c (as in HEAD), though; if anybody can weigh in on this, it'd be much appreciated. I suppose it could still be a compiler or a libthread bug, but I'm still missing a smoking gun here.

1 0

Re: (ITS#4981) Try -lpthread before -pthread
by kurt＠OpenLDAP.org 24 May '07

24 May '07

On May 23, 2007, at 10:16 PM, rra(a)stanford.edu wrote: > libtool does not pass -pthread through Our libtool does. But gcc might not do the right thing with it. In that case, it's a gcc bug which should be reported to the gcc folks. I believe using -lpthread over -pthread will cause more problems than its worth. That is, the problems caused by the missing link on some platforms is not nearly as bad as the caused by using -lc instead of -lc_r on other platforms. -- Kurt

1 0

Re: (ITS#4982) link libldap_r explicitly with the threading libraries
by h.b.furuseth＠usit.uio.no 24 May '07

24 May '07

rra(a)stanford.edu writes: > This issue, ITS#4982, is that no threading flags (not -pthread, not > -lpthread, not anything) are passed into the final link line of libldap_r, > as near as I can tell. Right. grepping make >& make.out shows no thread switch in the command line which builds libldap_r.so. Adding the ITS#4982 patch (and not ITS#4981), I got 4 '-pthread's in a row, which should be enough:-) -- Regards, Hallvard

1 0

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

24 May '07

Kurt Zeilenga <kurt(a)OpenLDAP.org> writes: > libtool should properly handle -pthread. If it doesn't, that should be > fixed instead of kludging things up with -lpthread. -pthread tells gcc > to do the right thing. The right thing might not be to link in > -lpthread. (On some versions of FreeBSD, the right think is -lc_r.) > -pthread also might do more than link in a library. > As OpenLDAP includes its own copy of libtool, a local fix can be > provided until the upstream fixes it right. I think the above was meant for ITS #4981? This issue, ITS#4982, is that no threading flags (not -pthread, not -lpthread, not anything) are passed into the final link line of libldap_r, as near as I can tell. It's possible that I'm reading the makefile wrong and this has been fixed in some other way since the Debian patch had been applied, but libraries/libldap_r/Makefile.in contains: UNIX_LINK_LIBS = $(LDAP_LIBLBER_LA) $(AC_LIBS) $(SECURITY_LIBS) and build/lib-shared.mk has: $(LIBRARY): version.lo $(LTLINK_LIB) -o $@ $(OBJS) version.lo $(LINK_LIBS) including only LINK_LIBS, and not the regular LIBS variable (which is what includes LTHREAD_LIBS via XXXLIBS). It could be that I'm missing some contribution to LTLINK_LIB handled by the threading macros, though. -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

Re: (ITS#4982) link libldap_r explicitly with the threading libraries
by kurt＠OpenLDAP.org 24 May '07

24 May '07

libtool should properly handle -pthread. If it doesn't, that should be fixed instead of kludging things up with -lpthread. -pthread tells gcc to do the right thing. The right thing might not be to link in - lpthread. (On some versions of FreeBSD, the right think is -lc_r.) -pthread also might do more than link in a library. As OpenLDAP includes its own copy of libtool, a local fix can be provided until the upstream fixes it right. -- Kurt On May 24, 2007, at 1:25 AM, rra(a)stanford.edu wrote: > Hallvard B Furuseth <h.b.furuseth(a)usit.uio.no> writes: >> Hallvard B Furuseth writes: > >>> Is this the second half of the Debian patch you posted in >>> ITS#4981 - so >>> it'd be wrong to apply one one of these patches? > >> Sorry, "wrong to apply _only_ one of". > >> (I.e. does ITS#4981 introduce breakage which ITS#4982 fixes?) Maybe >> everything worked well before we switched to libtool... > > No, they should be independent, I think. I believe that the > rationale for > 4982 is still correct; if you use pthread functions, you need to > explicitly link against the library to avoid getting unversioned > references. Unversioned references will *normally* not cause a > problem, > so they're a bit of a time bomb. They keep working fine right up > until > the library makes an incompatible change in the data structures, > and then > they break. > > -- > Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/ > ~eagle/> > >

1 0

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

24 May '07

Hallvard B Furuseth <h.b.furuseth(a)usit.uio.no> writes: > Hallvard B Furuseth writes: >> Is this the second half of the Debian patch you posted in ITS#4981 - so >> it'd be wrong to apply one one of these patches? > Sorry, "wrong to apply _only_ one of". > (I.e. does ITS#4981 introduce breakage which ITS#4982 fixes?) Maybe > everything worked well before we switched to libtool... No, they should be independent, I think. I believe that the rationale for 4982 is still correct; if you use pthread functions, you need to explicitly link against the library to avoid getting unversioned references. Unversioned references will *normally* not cause a problem, so they're a bit of a time bomb. They keep working fine right up until the library makes an incompatible change in the data structures, and then they break. -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

Re: (ITS#4982) link libldap_r explicitly with the threading libraries
by h.b.furuseth＠usit.uio.no 24 May '07

24 May '07

Hallvard B Furuseth writes: > Is this the second half of the Debian patch you posted in ITS#4981 - so > it'd be wrong to apply one one of these patches? Sorry, "wrong to apply _only_ one of". (I.e. does ITS#4981 introduce breakage which ITS#4982 fixes?) Maybe everything worked well before we switched to libtool... -- Regards, Hallvard

1 0

Re: (ITS#4982) link libldap_r explicitly with the threading libraries
by h.b.furuseth＠usit.uio.no 24 May '07

24 May '07

rra(a)stanford.edu writes: > 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. > (...) Is this the second half of the Debian patch you posted in ITS#4981 - so it'd be wrong to apply one one of these patches? -- Regards, Hallvard

1 0

Re: (ITS#4981) Try -lpthread before -pthread
by h.b.furuseth＠usit.uio.no 24 May '07

24 May '07

rra(a)stanford.edu writes: > (...) libtool does not pass -pthread through, -lpthread seems > to work though. > (...) > + OL_PTHREAD_TRY([-lpthread], [ol_cv_pthread_lpthread]) > OL_PTHREAD_TRY([-pthread], [ol_cv_pthread_pthread]) > (...) This may be correct for Debian, but looks dubious as a general patch. On other systems that have a thread compiler switch it may be wrong to link the thread library "by hand" and omit the compiler switch, otherwise what's the compiler switch for? Their comments seem to indicate libtool is a better place to fix it. An OpenLDAP patch would likely need some 'if <debian>' code. (Note, I do not know Debian, nor specifics about differing Linux variants.) -- Regards, Hallvard

1 0

Re: (ITS#4983) libldap_r/tls.c compile failure
by h.b.furuseth＠usit.uio.no 24 May '07

24 May '07

kurt(a)OpenLDAP.org writes: > tls.c: In function `tls_thread_self': > tls.c:412: error: invalid operands to binary / > tls.c:415: warning: comparison between pointer and integer Well, that was quick... my tls.c rev 1.154 patch, tls_thread_self(), deliberately causes that for non-integer thread types. I wanted feedback from systems where that happens, since the OpenSSL doc says such systems are rare and this code can break there. The CRYPTO_set_id_callback manpage (from openssl/doc/crypto/threads.pod) says the function expects an integer thread ID, but that the function is not needed if getpid() returns different answers for different threads. And that this may be dangerous to relay on because one might compile a program on a machine where this is true and then run it on a machine where it is false. Anyway, possibly the correct fix is to not call this function on FreeBSD, it depends on getpid(). I have no idea. But since it presumably worked before: The simplest fix is to just remove the 'ok' and 'Check' code. But then we can again silently compile to bad code when the thread type is not an integer. Next simplest: simplify the 'ok' check to: enum { ok = sizeof(ldap_pvt_thread_t) <= sizeof(long) }; which will still let us know of systems where the conversion to ulong clearly loses data. Not quite a safe, since pointer<->integer conversions can do who-knows-what. But I guess OpenLDAP depends on those elsewhere. (Can sizeof(long) be < sizeof(pointer) on FreeBSD?) Also in any case cast tls_thread_self()'s return value to u.long. -- Regards, Hallvard

1 0

(ITS#4983) libldap_r/tls.c compile failure
by kurt＠OpenLDAP.org 24 May '07

24 May '07

Full_Name: Kurt Zeilenga Version: HEAD OS: FreeBSD RELENG_6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.182.55.218) Submitted by: kurt /bin/sh ../..//libtool --mode=compile cc -g -O2 -I../../include -I../../include -DLDAP_R_COMPILE -I./../libldap -I/usr/local/include -I/usr/pkg/include/db44 -I/usr/pkg/include -DLDAP_LIBRARY -c tls.c cc -g -O2 -I../../include -I../../include -DLDAP_R_COMPILE -I./../libldap -I/usr/local/include -I/usr/pkg/include/db44 -I/usr/pkg/include -DLDAP_LIBRARY -c tls.c -fPIC -DPIC -o .libs/tls.o tls.c: In function `tls_thread_self': tls.c:412: error: invalid operands to binary / tls.c:415: warning: comparison between pointer and integer tls.c:415: error: enumerator value for `ok' not integer constant tls.c:416: error: negative width in bit-field `dummy' tls.c:416: error: size of array `Check' is negative tls.c:418: warning: return makes integer from pointer without a cast

1 0

(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

Re: (ITS#4978) slapo-ppolicy.5 and missing Zero value example
by ghenry＠suretecsystems.com 22 May '07

22 May '07

<quote who="hyc(a)symas.com"> > ahasenack(a)terra.com.br wrote: >> On Mon, May 21, 2007 at 09:25:23PM +0000, ghenry(a)OpenLDAP.org wrote: >>> draft-behera-ldap-password-policy-xx.txt and ppolicy.schema list: >>> >>> "A 000001010000Z value means that the account has been locked >>> permanently, and >>> that only a password administrator can unlock the account." >>> >>> But pwdAccountLockedTime doesn't use integerMatch, so an example of the >>> above >>> syntax is needed with anything that has a generalizedTimeMatch. I think >>> pwdAccountLockedTime is the only one? >> >> The slapo-ppolicy(5) manpage is actually misleading. It implies that >> the value is a plain zero, which doesn't work: >> "If pwdAccountLockedTime is set to zero (0), the user's account (...)" > > That text in the manpage came from an earlier revision of the ppolicy > draft; it just wasn't updated when the meaning was clarified in a later > draft version. Looks like Gavin has fixed it in HEAD now. Yes, sorry. I thought silence meant it was ok to go ahead. This is my first ever commit, so I'll be a bit more patient next time ;-) Thanks. > > -- > -- 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#4958) slapd segfaults when overlay rwm, suffixmassage is used in conjunction with empty suffix
by ando＠sys-net.it 22 May '07

22 May '07

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#4964) consumer with slapo-chain segfaults when using ldappasswd
by krause＠biochem.mpg.de 22 May '07

22 May '07

I have downloaded the cvs version (2007-05-21) and built it, but get, as it seems related to something else, a segfault. i reproduced this trice. what i did: (just to be sure i did not make a fatal mistake) * fetched cvs * ran configure with the following command line: env CPPFLAGS=-I/usr/include/db42 ./configure --enable-wrappers --enable-aclgroups --enable-spasswd --enable-modules --enable-shared --enable-dynamic --with-tls --with-cyrus-sasl --enable-crypt --enable-aci --enable-bdb --enable-hdb --enable-ldbm --enable-rewrite --enable-ldap=yes --enable-meta=mod --enable-monitor=yes --enable-perl=mod --enable-slp --enable-overlays=yes --enable-lmpasswd --with-yielding-select --enable-debug=yes i had to install the development package for BDB 4.2 (although the rpm from opensuse has it built with BDB 4.3, also i could not reuse the existing ldap db) * then make depend; make; make test -> all tests succeded (as far is i can tell) * gdb openldap/servers/slapd/.libs/slapd run -h ldap:/// ldaps:/// -g ldap -u ldap -d 65535 as the "local" ldap db on this consumer is empty the replication starts (reproduced after segfault and removal of the direcory contents): [lot of debugging output, and finally:] entry_decode: "cn=Neurobiologie EDV,ou=IT Contacts,ou=ACL,dc=biochem,dc=mpg,dc=de" <= entry_decode(cn=Neurobiologie EDV,ou=IT Contacts,ou=ACL,dc=biochem,dc=mpg,dc=de) => test_filter PRESENT => access_allowed: search access to "cn=Neurobiologie EDV,ou=IT Contacts,ou=ACL,dc=biochem,dc=mpg,dc=de" "objectClass" requested <= root access granted => access_allowed: search access granted by manage(=mwrscxd) <= test_filter 6 nonpresent_callback: rid=013 got UUID 1f1b0732-9823-102b-8c9e-b3c3d9320a55, dn cn=Neurobiologie EDV,ou=IT Contacts,ou=ACL,dc=biochem,dc=mpg,dc=de send_ldap_result: conn=-1 op=0 p=0 send_ldap_result: err=0 matched="" text="" bdb_modify: dc=biochem,dc=mpg,dc=de bdb_dn2entry("dc=biochem,dc=mpg,dc=de") entry_decode: "dc=biochem,dc=mpg,dc=de" <= entry_decode(dc=biochem,dc=mpg,dc=de) bdb_modify_internal: 0x00000001: dc=biochem,dc=mpg,dc=de <= acl_access_allowed: granted to database root bdb_modify_internal: add contextCSN => entry_encode(0x00000001): dc=biochem,dc=mpg,dc=de bdb_modify: updated id=00000001 dn="dc=biochem,dc=mpg,dc=de" send_ldap_result: conn=-1 op=0 p=0 send_ldap_result: err=0 matched="" text="" Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1225942112 (LWP 19016)] slap_dup_sync_cookie (dst=0x8283400, src=0xb6ed8cf0) at ldapsync.c:327 327 new->sids[i] = src->sids[i]; the backtrace says: (gdb) bt #0 slap_dup_sync_cookie (dst=0x8283400, src=0xb6ed8cf0) at ldapsync.c:327 #1 0x080c83fd in syncrepl_updateCookie (si=0x8283310, op=0xb6ed8e7c, pdn=<value optimized out>, syncCookie=0xb6ed8cf0) at syncrepl.c:2615 #2 0x080ced95 in do_syncrep2 (op=0xb6ed8e7c, si=0x8283310) at syncrepl.c:1016 #3 0x080cffbc in do_syncrepl (ctx=0xb6ed92d8, arg=0x8282d60) at syncrepl.c:1161 #4 0x08074c0a in connection_read_thread (ctx=0xb6ed92d8, argv=0x11) at connection.c:1273 #5 0xb7f5f7f2 in ldap_int_thread_pool_wrapper (xpool=0x821ff08) at tpool.c:725 #6 0xb7c4134b in start_thread () from /lib/libpthread.so.0 #7 0xb7bd965e in clone () from /lib/libc.so.6 (gdb) after this it also segfaults if started again : [lot of debugging output, and finally:] do_syncrep2: rid=013 LDAP_RES_INTERMEDIATE - REFRESH_PRESENT ber_scanf fmt (t{) ber: ber_dump: buf=0x08312178 ptr=0x08312178 end=0x083121a8 len=48 0000: a2 2e 04 2c 63 73 6e 3d 32 30 30 37 30 35 31 36 ...,csn=20070516 0010: 31 38 30 30 34 38 5a 23 30 30 30 30 36 35 23 30 180048Z#000065#0 0020: 30 23 30 30 30 30 30 30 2c 72 69 64 3d 30 31 33 0#000000,rid=013 ber_scanf fmt (m) ber: ber_dump: buf=0x08312178 ptr=0x0831217a end=0x083121a8 len=46 0000: 04 2c 63 73 6e 3d 32 30 30 37 30 35 31 36 31 38 .,csn=2007051618 0010: 30 30 34 38 5a 23 30 30 30 30 36 35 23 30 30 23 0048Z#000065#00# 0020: 30 30 30 30 30 30 2c 72 69 64 3d 30 31 33 000000,rid=013 ber_scanf fmt (}) ber: ber_dump: buf=0x08312178 ptr=0x083121a8 end=0x083121a8 len=0 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1235027040 (LWP 23928)] compare_csns (sc1=0xb662ecd0, sc2=0xb662ecf0, which=0xb662ede4) at syncrepl.c:647 647 if ( sc1->sids[i] != sc2->sids[j] ) backtrace says this time: (gdb) bt #0 compare_csns (sc1=0xb662ecd0, sc2=0xb662ecf0, which=0xb662ede4) at syncrepl.c:647 #1 0x080ced4c in do_syncrep2 (op=0xb662ee7c, si=0x82832b0) at syncrepl.c:1005 #2 0x080cffbc in do_syncrepl (ctx=0xb662f2d8, arg=0x8282d00) at syncrepl.c:1161 #3 0x08074c0a in connection_read_thread (ctx=0xb662f2d8, argv=0x11) at connection.c:1273 #4 0xb7eb67f2 in ldap_int_thread_pool_wrapper (xpool=0x821ff08) at tpool.c:725 #5 0xb7b9834b in start_thread () from /lib/libpthread.so.0 #6 0xb7b3065e in clone () from /lib/libc.so.6 * the configuration on the provider and the consumer were left untouched (except path corrections) to the until now running without errors rpm-version 2.3.34, the old rpms have been removed (using rpm -e) did i make something wrong or did i hit another bug?? regards markus Zitat von Pierangelo Masarati <ando(a)sys-net.it>: > This is now completely fixed in HEAD; I need to check any issue related > to backporting to re23, for quick release. Please test. Thanks for > reporting, 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 > --------------------------------------- > > +-----------------------------------------------------------------+ | Markus Krause, Mogli-Soft | | Support for Mac OS X, Webmail/Horde, LDAP, RADIUS, MySQL | | by order of the | | Computing Center of the Max-Planck-Institute of Biochemistry | +--------------------------------+--------------------------------+ | E-Mail: krause(a)biochem.mpg.de | Tel.: 089 - 89 40 85 99 | | markus.krause(a)mac.com | Fax.: 089 - 89 40 85 98 | | Skype: markus.krause | iChat: markus.krause(a)mac.com | +--------------------------------+--------------------------------+ ---------------------------------------------------------------------- This message was sent using https://webmail2.biochem.mpg.de If you encounter any problems please report to rz-linux(a)biochem.mpg.de

1 0

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

22 May '07

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 Pierangelo Masarati wrote: > nvoutsin(a)noc.uoa.gr wrote: > >> As ando already said: >> .....it tries to lookup a database to relay for when unbinding, >> but unbind has no DN, so a strcmp on NULL is performed. This does not >> happen when using the "relay" directive because relay database selection >> does not occur for each operation.... > > Technically, the bug is now fixed in HEAD/re23 (please test). > Concerning the issue initially raised on the -software list, which seems > to be open yet, see discussion on the list. > > 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs