- openldap-bugs - openldap.org

Re: (ITS#5556) ldapadd/slapadd create objects without RDN
by h.b.furuseth＠usit.uio.no 14 Jun '08

14 Jun '08

Well, pre-2.4.9 versions would reject the Add operation... Is it 2.4.10 built from the OpenLDAP source, or some prepackaged binary? Maybe an overlay or something interferes with auto-adding the naming attrs? Please post your slapd.conf too, after removing passwords etc. -- Hallvard

1 0

(ITS#5560) API for assertion control
by michael＠stroeder.com 14 Jun '08

14 Jun '08

Full_Name: Michael Ströder Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.75.195) I would be handy to have an API for generating an assertion control (see RFC 4528). The function should take a string representation of a LDAP search filter as input.

1 0

Re: (ITS#5556) ldapadd/slapadd create objects without RDN
by ando＠sys-net.it 14 Jun '08

14 Jun '08

joshua(a)itsecureadmin.com wrote: > When adding an object with slapadd or ldapadd, it is possible to create an > object which does not have an RDN, and therefore not searchable by RDN. Can't reproduce. Works as expected here (adding entry without naming attributes/distinguished values results in automatically generating that data, both by slapadd and ldapadd). Can you confirm software versions? 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: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5555) authzTo ACL check for wrong principal
by ando＠sys-net.it 14 Jun '08

14 Jun '08

andrew.findlay(a)skills-1st.co.uk wrote: > When using "authz-policy to" I find that the entity that is trying to do an > operation on behalf of another entity needs read access to its own authzTo > attribute. > This seems wrong: authzTo is defining what the user may do: I do not really want > them to be able to see it. When doing a proxy authz I think ACLs for this > attribute should not be checked at all as the access is effectively being done > by the rootdn. AFAIK, access to that attribute is checked using AUTH rather than read. The idea is that ACLs should allow to fine-grain control who is allowed to exploit the authorization feature while giving up as little as possible (e.g. AUTH instead of READ). 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: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5559) slapo-pcache sizelimit caching not documented
by ando＠sys-net.it 14 Jun '08

14 Jun '08

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Submitted by: ando The sizelimit caching feature, and related setting, are not documented in slapo-pcache(5) man page.

1 0

Re: (ITS#5549) slapd SEGV faults in entry_partsize when monitoring
by ando＠sys-net.it 14 Jun '08

14 Jun '08

andreas.mueller(a)othello.ch wrote: > Full_Name: Andreas Mueller > Version: 2.4.9 > OS: Solaris 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.134.170.35) > > > We have four slapd servers in a mirrormode configuration. > This generally works well. We monitor these servers using > ldapsearches to cn=Monitor every minute, and collect > performance data to construct load/performance graphs > with rrdtool. Unfortunately, it sometimes happens that > slapd crashes during the monitoring query. Using gdb, we > were able to get a stack backtrace: > > Core was generated by `/usr/local/libexec/slapd'. > Program terminated with signal 11, Segmentation fault. > #0 0x0005fd48 in entry_partsize () > (gdb) bt > #0 0x0005fd48 in entry_partsize () > #1 0x000603b4 in entry_flatsize () > #2 0x0006a5c8 in slap_send_search_entry () > #3 0x00134330 in monitor_send_children () > #4 0x001348e0 in monitor_back_search () > #5 0x000523ac in fe_op_search () > #6 0x00051b64 in do_search () > #7 0x0004dd8c in connection_operation () > #8 0x0004e4c4 in connection_read_thread () > #9 0x001a22a8 in ldap_int_thread_pool_wrapper () > #10 0xfe3c5800 in __tbl_10_huge_digits () from /lib/libc.so.1 > > All cores obtained so far show that the segmentation fault > occured at the same location inside entry_partsize. > > Unfortunately we cannot systematically reproduce this behaviour, > and we also cannot get the line number (binaries are stripped). > > We have not tried other versions or other platforms. For production, > we use the versions available in package form from www.sunfreeware.com, > but the error also happens on servers we have compiled ourselves from > the sources. You should run a non-stripped binary, in order to allow more useful information to be extracted from those core files. 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: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5558) Buffer Overflow in back_sock and back_shell
by hyc＠symas.com 13 Jun '08

13 Jun '08

stef(a)memberwebs.com wrote: > Full_Name: Stef Walter > Version: openldap 2.4.10 > OS: FreeBSD 6.3-RELEASE-p2 > URL: http://memberwebs.com/stef/scraps/openldap24-buffer-overflow.patch > Submission from: (NULL) (189.162.38.105) > > > The back_sock and back_shell backends have a buffer overflow (off by one) > problem in their result parsing code in read_and_send_results() lines 82-89 in > result.c. The buffer is reallocated when an additional string would be too long > for the buffer, but the string's null terminator is not taken into account. > > This can cause a crash in certain situations. These situations are obviously > data and OS dependent. But with specific data, the crash is reproducible. > > Patch which fixes the problem: Thanks, now fixed in CVS HEAD. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5558) Buffer Overflow in back_sock and back_shell
by stef＠memberwebs.com 13 Jun '08

13 Jun '08

Full_Name: Stef Walter Version: openldap 2.4.10 OS: FreeBSD 6.3-RELEASE-p2 URL: http://memberwebs.com/stef/scraps/openldap24-buffer-overflow.patch Submission from: (NULL) (189.162.38.105) The back_sock and back_shell backends have a buffer overflow (off by one) problem in their result parsing code in read_and_send_results() lines 82-89 in result.c. The buffer is reallocated when an additional string would be too long for the buffer, but the string's null terminator is not taken into account. This can cause a crash in certain situations. These situations are obviously data and OS dependent. But with specific data, the crash is reproducible. Patch which fixes the problem: --- ../openldap-2.4.10/servers/slapd/back-sock/result.c 2008-02-08 18:46:09.000000000 -0000 +++ servers/slapd/back-sock/result.c 2008-06-13 15:56:46.000000000 -0000 @@ -77,7 +77,7 @@ } len = strlen( line ); - while ( bp + len - buf > bsize ) { + while ( bp + (len + 1) - buf > bsize ) { size_t offset = bp - buf; bsize += BUFSIZ; buf = (char *) ch_realloc( buf, bsize ); --- ../openldap-2.4.10/servers/slapd/back-shell/result.c 2008-02-11 17:26:47.000000000 -0000 +++ servers/slapd/back-shell/result.c 2008-06-13 15:57:02.000000000 -0000 @@ -80,7 +80,7 @@ } len = strlen( line ); - while ( bp + len - buf > bsize ) { + while ( bp + (len + 1) - buf > bsize ) { size_t offset = bp - buf; bsize += BUFSIZ; buf = (char *) ch_realloc( buf, bsize );

1 0

(ITS#5557) memory leak in ACL sets
by hyc＠OpenLDAP.org 13 Jun '08

13 Jun '08

Full_Name: Howard Chu Version: 2.3.39/2.4/HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Submitted by: hyc slap_set_join() with an '|' operator will leak values if it detects a duplicate in the rset. A fix will be committed shortly.

1 0

(ITS#5556) ldapadd/slapadd create objects without RDN
by joshua＠itsecureadmin.com 13 Jun '08

13 Jun '08

Full_Name: Josh Miller Version: 2.4.10 OS: CentOS 5.1 URL: http://itsecureadmin.com/uid-test.txt Submission from: (NULL) (65.249.25.3) When adding an object with slapadd or ldapadd, it is possible to create an object which does not have an RDN, and therefore not searchable by RDN. Example data: dn: uid=nouiduser,ou=People,dc=openldap,dc=example,dc=com objectClass: mailAccount maildrop: nouiduser(a)nest.tld mailid: nouiduser(a)nest.tld maildir: nouiduser/ userPassword:: e2NyeXB0fSQxJERCQS5wdmZYJHU0eFp3TndSRDIwSDFkTDBrNmZMRi4= mailquota: 35969216S The above LDIF is added to the directory without any errors and is then missing the uid attribute. ldapsearch will not return any results when filtering on uid, ie: $ ldapsearch -xZZH ldap://server uid=nouiduser - Expected result - return the object. - Actual result - no object returned. - Workaround - use ldapmodify to add the uid attribute. Please see the attached URL for complete event details (add/search/modify).

1 0

(ITS#5555) authzTo ACL check for wrong principal
by andrew.findlay＠skills-1st.co.uk 13 Jun '08

13 Jun '08

Full_Name: Andrew Findlay Version: 2.4.10 OS: Linux: SuSE 10.2 URL: Submission from: (NULL) (88.97.25.132) When using "authz-policy to" I find that the entity that is trying to do an operation on behalf of another entity needs read access to its own authzTo attribute. This seems wrong: authzTo is defining what the user may do: I do not really want them to be able to see it. When doing a proxy authz I think ACLs for this attribute should not be checked at all as the access is effectively being done by the rootdn.

1 0

Re: (ITS#5554) slapd.conf man page missing TLSCipherSuite
by ghenry＠OpenLDAP.org 12 Jun '08

12 Jun '08

<quote who="Howard Chu"> > ghenry(a)OpenLDAP.org wrote: >> Full_Name: Gavin Henry >> Version: HEAD >> OS: >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (212.159.59.85) >> >> >> http://www.openldap.org/software/man.cgi?query=slapd.conf&sektion=5&apropos… >> missing TLSCipherSuite >> >> > No. The Admin Guide is missing the note about GnuTLS under the > TLSCipherSuite > description. The note is present in slapd.conf(5). I don't knwo what I was thinking when I wrote that, but I did mean what you've just wrote. Weird.

1 0

Re: (ITS#5554) slapd.conf man page missing TLSCipherSuite
by hyc＠symas.com 12 Jun '08

12 Jun '08

ghenry(a)OpenLDAP.org wrote: > Full_Name: Gavin Henry > Version: HEAD > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.159.59.85) > > > http://www.openldap.org/software/man.cgi?query=slapd.conf&sektion=5&apropos… > missing TLSCipherSuite > > > No. The Admin Guide is missing the note about GnuTLS under the TLSCipherSuite description. The note is present in slapd.conf(5). -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5554) slapd.conf man page missing TLSCipherSuite
by ghenry＠OpenLDAP.org 12 Jun '08

12 Jun '08

Full_Name: Gavin Henry Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) http://www.openldap.org/software/man.cgi?query=slapd.conf&sektion=5&apropos… missing TLSCipherSuite

1 0

Re: (ITS#5551) assertion causes application failure
by ghenry＠OpenLDAP.org 12 Jun '08

12 Jun '08

> Is there debug output you would like from me? See http://www.openldap.org/faq/data/cache/59.html -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: (ITS#5540) Normalization assertion in attr.c
by h.b.furuseth＠usit.uio.no 12 Jun '08

12 Jun '08

hyc(a)symas.com writes: >>> monitorContext, readOnly and the olc* attributes are defined by OpenLDAP >>> (their OIDs start with 1.3.6.1.4.1.4203) and can be modified if we feel >>> like it. Personally I prefer attrs to have the matching rules they can >>> have unless there is a reason not to, but I didn't write these modules >>> so I don't know if there _is_ a reason not to. > > For the config attributes, I just assumed no one needs to search on > them (so no filter capability needed) and for single-valued > attributes, there's no need to consider modifies... Oh, good. No reason not to add matching rules then:-) I search for one config attrs or another once in a while. Mostly for olcSuffix and with presence filters, but it'd be nice if e.g. (olcAccess:caseIgnoreSubstringsMatch:=*userPassword*) worked. Also some day I'll want to use assertion controls as a check on modify operations someday. Still, I'm not proposing to add more work than necessary to this ITS. Get it right first, then think of "nice to have"-features if/when anyone bothers. -- Hallvard

1 0

Re: (ITS#5553) Inconsistent sasl.c logging format
by h.b.furuseth＠usit.uio.no 12 Jun '08

12 Jun '08

hyc(a)symas.com writes: >> Would it be reasonable to change the 6 debug statements in sasl.c to >> use the first format? > > I don't see any reason not to. I do: Currently that format is more or less reserved for loglevel stats/stats2, and is useful when grepping a more chatty log for stats. Though it could certainly be useful to normalize log formats a little. -- Hallvard

1 0

Re: (ITS#5540) Normalization assertion in attr.c
by hyc＠symas.com 12 Jun '08

12 Jun '08

unix.gurus(a)gmail.com wrote: >>> namingContexts >>> configContext >>> dynamicSubtrees >>> >>> These attributes do not have equality matching rules, but probably >>> should. I add 'EQUALITY distinguishedNameMatch' to them in >>> schema_prep.c. >> No, that breaks the definitions in the RFCs they come from. (See their >> DESC strings.) I don't know why they lack EQUALITY rules, maybe we just >> forgot when we defined them, but that's the way it is. Same with >> supportedControl. configContext is OpenLDAP-specific. It is also single-valued, so it seemed to me it did not need an EQ rule. > Ok, so we should not define nvals for them? No normalizer, therefore, cannot provide nval... >> monitorContext, readOnly and the olc* attributes are defined by OpenLDAP >> (their OIDs start with 1.3.6.1.4.1.4203) and can be modified if we feel >> like it. Personally I prefer attrs to have the matching rules they can >> have unless there is a reason not to, but I didn't write these modules >> so I don't know if there _is_ a reason not to. For the config attributes, I just assumed no one needs to search on them (so no filter capability needed) and for single-valued attributes, there's no need to consider modifies... -- -- Howard Chu CTO, 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#5553) Inconsistent sasl.c logging format
by hyc＠symas.com 12 Jun '08

12 Jun '08

unix.gurus(a)gmail.com wrote: > Full_Name: Sean Burford > Version: 2.4.8 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (72.14.227.1) > > > Most connection logs are of the format: > conn=\d+ fd=\d+ MSG > > sasl.c Debug logs are of the format: > SASL .*[conn=\d+]: MSG > > Would it be reasonable to change the 6 debug statements in sasl.c to use the > first format? I don't see any reason not to. > > This is not an important issue, just a small inconsistency. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5553) Inconsistent sasl.c logging format
by unix.gurus＠gmail.com 12 Jun '08

12 Jun '08

Full_Name: Sean Burford Version: 2.4.8 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (72.14.227.1) Most connection logs are of the format: conn=\d+ fd=\d+ MSG sasl.c Debug logs are of the format: SASL .*[conn=\d+]: MSG Would it be reasonable to change the 6 debug statements in sasl.c to use the first format? This is not an important issue, just a small inconsistency.

1 0

(ITS#5552) Ppolicy overlay doesn't accept unquoted DN for "olcPpolicyDefault"
by ralf＠OpenLDAP.org 12 Jun '08

12 Jun '08

Full_Name: Ralf Haferkamp Version: HEAD, RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.189.171) Submitted by: ralf Adding an unquoted DN (containing white spaces) to olcPpolicyDefault results in the following error: ldap_modify: Constraint violation (19) additional info: <olcPPolicyDefault> extra cruft after <policyDN> Fix is on the way to CVS.

1 0

Re: (ITS#5550) Unable to do scp from and to server ldap
by hyc＠symas.com 12 Jun '08

12 Jun '08

karim.bourenane(a)orange-ftgroup.com wrote: > Full_Name: Bourenane > Version: Openldap-server-2.3.41 / and clien > OS: FreeBSD 7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (57.250.229.136) > > > Hi All > > My server running fine, with ldap and ldaps. > Is i do a command SCP from any server to user i have : > > server# scp kbourena@ldap-rain:/home/kbourena/toto.txt . > Password: > unknown user 1206 > server# > > On ldap-rain scp is not OpenLDAP software. Since you already said your server is running fine, this is clearly not an OpenLDAP software issue, and therefore does not belong in the OpenLDAP ITS. This ITS will be closed. -- -- Howard Chu CTO, 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#5462) Allow setting of RANDOM_FILE for gnutls
by pogma＠thewrittenword.com 12 Jun '08

12 Jun '08

On Tue, Jun 10, 2008 at 12:50:22PM -0700, Howard Chu wrote: > pogma(a)thewrittenword.com wrote: >> Full_Name: Peter O'Gorman >> Version: 2.4.8 >> OS: multiple >> URL: ftp://ftp.openldap.org/incoming/the-written-word-080410.patch >> Submission from: (NULL) (24.76.165.223) >> >> >> gcrypt-1.4.x and later allow the egd socket path to be set. This patch allows >> the conf file option to work when building openldap with gnutls on systems that >> do not have a /dev/random. > > Hm, this patch is a silent no-op if the gcrypt function is missing. > Currently the randfile option is already documented as being ignored by > GNUtls. I would prefer that the behavior is absolutely consistent - either > the feature always works or is always ignored. Perhaps we should require > gcrypt 1.4 or newer? Requiring gcrypt-1.4.x or newer is ok with us. Peter -- Peter O'Gorman pogma(a)thewrittenword.com

1 0

Re: (ITS#5551) assertion causes application failure
by aej＠WPI.EDU 12 Jun '08

12 Jun '08

I ran the thing again to get a trace back, and went to attach the code and found a free() which was at the wrong location. I think I caused the problem. I still don't know what's happening with ldap on the mail server, but my application bug was not related after all.

1 0

(ITS#5551) assertion causes application failure
by aej＠wpi.edu 12 Jun '08

12 Jun '08

Full_Name: Allan E. Johannesen Version: 2.4.10 OS: Linux EL 4 URL: Submission from: (NULL) (130.215.24.208) Recently, incorrect "User unknown" have been appearing in the mail logs with some frequency, accompanied by nss ldap error messages. I can't see into that application, so I'm not sure what's going on. At another place, I've had an application failing where it sees an assertion fail, so this may be the cause of the other problem. Did some debug code remain in the 2.4.10 release? [New Thread 1367456096 (LWP 14151)] [New Thread 1388435808 (LWP 14165)] [Thread 1514314080 (LWP 14129) exited] [New Thread 1514314080 (LWP 14178)] [Thread 1252067680 (LWP 13877) exited] [Thread 1241577824 wpi closed] [Thread 1241577824 (LWP 13824) exited] [New Thread 1241577824 (LWP 14188)] [Thread 1199618400 (LWP 13994) exited] [Thread 1231087968 wpi closed] [Thread 1231087968 (LWP 13888) exited] [New Thread 1231087968 (LWP 14199)] [Thread 1115699552 wpi closed] [Thread 1115699552 (LWP 13946) exited] [Thread 1126189408 alum_connect ldap://alum.wpi.edu] [New Thread 1115699552 (LWP 14212)] [Thread 1136679264 wpi_connect ldap://ldapv2back.wpi.edu] [New Thread 1199618400 (LWP 14223)] [Thread 1105209696 (LWP 14011) exited] [New Thread 1105209696 (LWP 14234)] [Thread 1294027104 (LWP 13865) exited] [Thread 1335986528 (LWP 13839) exited] [Thread 1094719840 (LWP 14057) exited] [New Thread 1094719840 (LWP 14251)] [Thread 1346476384 alum_connect ldap://alum.wpi.edu] [New Thread 1335986528 (LWP 14271)] [New Thread 1294027104 (LWP 14285)] [Thread 1126189408 alum closed] [New Thread 1252067680 (LWP 14286)] [Thread 1126189408 (LWP 14022) exited] [New Thread 1398925664 (LWP 14297)] [New Thread 1126189408 (LWP 14308)] [Thread 1294027104 (LWP 14285) exited] [New Thread 1409415520 (LWP 14318)] [Thread 1157658976 wpi closed] [Thread 1157658976 (LWP 13960) exited] [New Thread 1157658976 (LWP 14329)] [New Thread 1294027104 (LWP 14342)] [Thread 1377945952 (LWP 13928) exited] [New Thread 1377945952 (LWP 14353)] [New Thread 1419905376 (LWP 14363)] [Thread 1325496672 (LWP 14100) exited] [Thread 1294027104 (LWP 14342) exited] [Thread 1136679264 wpi closed] [Thread 1136679264 (LWP 14033) exited] [New Thread 1136679264 (LWP 14380)] [Thread 1262557536 (LWP 13971) exited] [Thread 1220598112 (LWP 14111) exited] [Thread 1283537248 (LWP 14140) exited] [Thread 1346476384 alum closed] [Thread 1346476384 (LWP 14069) exited] [Thread 1367456096 wpi_connect ldap://ldapv2back.wpi.edu] phish+: decode.c:779: ber_scanf: Assertion `((ber)->ber_opts.lbo_valid==0x2)' failed. Program received signal SIGABRT, Aborted. [Switching to Thread 1367456096 (LWP 14151)] 0x000000382342e25d in raise () from /lib64/tls/libc.so.6 (gdb) quit The program is running. Exit anyway? (y or n) y Is there debug output you would like from me?

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs