openldap-bugs September 2007

openldap-bugs@openldap.org

33 participants
179 discussions

(ITS#5119) double free in slapd
by quanah＠zimbra.com 03 Sep '07

03 Sep '07

Full_Name: Quanah Gibson-Mount Version: 2.3.38/RE23 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (71.202.148.128) There is apparently a bug in attribute normalization of objectClasses that can result in a double free in slapd, causing it to crash. Please see: <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=440632> This behavior still exists in current RE23. --Quanah

1 0

Re: (ITS#5114) pcache cache results for searches that hit size/timelimit
by rhafer＠suse.de 03 Sep '07

03 Sep '07

On Saturday 01 September 2007 17:35, ando(a)sys-net.it wrote: > ando(a)sys-net.it wrote: > > Ralf, > > This patch should now work as expected. > > <http://www.sys-net.it/~ando/Download/pcache_sizelimit.patch> > > Does it harmonize with your improvements? Your changes to the response and cleanup handles interfere a bit with my changes (I move much of the _response code to _cleanup) but it should be easy to sort that out once we have either of the two patches in HEAD. But as 2.4.5 is not tagged yet we should probably wait until that happened. > Or, if you prefer, first > commit your changes, and I'll harmonize the rest. That doesn't really matter to me. I have the felling that it is easier the other way around :) -- Ralf

1 0

(ITS#5118) DB_CONFIG missing from converted config
by hyc＠OpenLDAP.org 02 Sep '07

02 Sep '07

Full_Name: Howard Chu Version: 2.3/2.4 OS: URL: Submission from: (NULL) (76.168.84.21) Submitted by: hyc The back-bdb config code was only parsing the DB_CONFIG file in server mode, but it needs to be parsed in all modes so that slaptest -f slapd.conf -F slapd.d can see it when converting. Already fixed in HEAD

1 0

Re: (ITS#4848) Another slapd startup segfault
by hyc＠symas.com 02 Sep '07

02 Sep '07

ando(a)sys-net.it wrote: > Your problem is related > to the fact that you intermixed overlay and database configuration > statements, so the idletimeout statement after the accesslog overlay > instantiation was causing invalid memory write (beyond the private data > of the accesslog overlay instead of in the private data of the bdb > database) resulting in heap corruption. The fix in HEAD has been backported to RE23 now. (The fix for ITS#5082 needed part of this fix.) -- -- 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#5082
by hyc＠symas.com 02 Sep '07

02 Sep '07

Howard Chu wrote: > ando(a)sys-net.it wrote: >> See also discussion in thread >> <http://www.openldap.org/lists/openldap-software/200708/msg00063.html> > > The fix currently in CVS HEAD is to remove the olcPasswordHash attribute from > the olcGlobal entry and move it to the frontendDB entry. For better backward compatibility, olcPasswordHash is allowed in both the olcGlobal entry and the frontendDB entry. The preferred location for this setting is now in the frontendDB entry. When generating a slapd.d from a slapd.conf file, only the frontendDB entry will carry the attribute. Existing slapd.d configs with the attribute in the global entry should continue to work but they should be manually updated to use only the frontendDB entry. This fix is now in RE23 as well as RE24. -- -- 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#5070) Issues in X.509 certificate parsing
by hyc＠symas.com 02 Sep '07

02 Sep '07

ando(a)sys-net.it wrote: > ando(a)sys-net.it wrote: > >> I've an issue with X.509 certificate parsing in HEAD/re24. The certificate, >> according to OpenSSL, has a SerialNumber c8:5b:9a:dd:ea:bf:f9:fa and HEAD fails >> to parse it because it is an integer with length equal to 9, which is larger >> than sizeof(ber_int_t), as tested in ber_getnint() at decode.c:254. The DER >> encoded value is: 2 9 0 200 91 154 221 234 191 249 250. Seems to be time >> to get past the sizeof(ber_int_t) limitation... > > ... which would violate RFC 4511 where it states that INTEGER means from > 0 up to 2^31-1... I have a simple solution for this problem, at the > cost of partially violating rfc 4523: if an integer is larger than > 2^31-1, it could be represented in the certificateExactMatch > normalization in hexadecimal form, much like OpenSSL does. This would > increase interoperability with OpenSSL and be at least self-consistent, > since all serialNumbers that large would be consistently expanded that > way. Another solution, preserving the decimal representation, would > probably require some arbitrary precision support from external > libraries. If there's consensus, I'd post my simple patch. I would go with the hex representation. IMO LDAP/X.500 has long needed a hex integer syntax (or at least some other binary base, but hex is probably best), since we can parse/validate them bytewise without any word size limitations or expensive conversions. And IMO GSER is a giant leap backward in network protocol efficiency. If it were merely a UI format, like LDIF, that would have been ok, but over the wire, that's ridiculous. (But that's a separate discussion entirely...) -- -- 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#5117) test049/test050 failures
by hyc＠symas.com 01 Sep '07

01 Sep '07

hyc(a)symas.com wrote: > hyc(a)symas.com wrote: >> I see the same result on FreeBSD 6.2. It appears to be because libfetch was >> detected by configure and used here, and libfetch failed to open the FILE URLs >> that load the necessary schema. > > The test script uses relative URLs (RFC1808) which our liblutil stuff supports, > but apparently libfetch only knows how to parse absolute URLs (RFC1738) - see > their CVS > http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libfetch/fetch.c?rev=1.38 > > Seems to me to be a deficiency in libfetch, but I guess we can rework the > scripts to use absolute FILE URLs here. Dunno if it's worth reporting this upstream, but libfetch accepts relative paths like this file://./foo/bar -> "./foo/bar" which violates both RFC1738 and RFC1808 (and RFC2396). I.e., when the "//" authority-spec is present the path must be absolute. Probably, since libfetch provides no mechanism for defining a base URI, it should just never accept relative paths. -- -- 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#5117) test049/test050 failures
by hyc＠symas.com 01 Sep '07

01 Sep '07

hyc(a)symas.com wrote: > I see the same result on FreeBSD 6.2. It appears to be because libfetch was > detected by configure and used here, and libfetch failed to open the FILE URLs > that load the necessary schema. The test script uses relative URLs (RFC1808) which our liblutil stuff supports, but apparently libfetch only knows how to parse absolute URLs (RFC1738) - see their CVS http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libfetch/fetch.c?rev=1.38 Seems to me to be a deficiency in libfetch, but I guess we can rework the scripts to use absolute FILE URLs here. -- -- 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#5117) test049/test050 failures
by hyc＠symas.com 01 Sep '07

01 Sep '07

kurt(a)OpenLDAP.org wrote: > Full_Name: Kurt Zeilenga > Version: HEAD > OS: MacoSX 10.4.8/FreeBSD 6.2 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (24.180.46.200) > Submitted by: kurt > > > On both MacOS X and FreeBSD, I see test047 fail trying to configure the server > via cn=config. Both built using ./configure --enable-backends > --enable-overlays, nothing fancy. > > Cleaning up test run directory leftover from previous run. > Running ./scripts/test049-sync-config... > running defines.sh > Starting producer slapd on TCP/IP port 9011... > Using ldapsearch to check that producer slapd is running... > Inserting syncprov overlay on producer... > Starting consumer slapd on TCP/IP port 9012... > Using ldapsearch to check that consumer slapd is running... > Configuring syncrepl on consumer... > Waiting 10 seconds for syncrepl to receive changes... > Using ldapsearch to check that syncrepl received config changes... > Adding schema and databases on producer... I see the same result on FreeBSD 6.2. It appears to be because libfetch was detected by configure and used here, and libfetch failed to open the FILE URLs that load the necessary schema. > ldapadd failed for database config (21)! > > where test.out contains: > ldap_add: Invalid syntax (21) > additional info: olcSuffix: value #0 invalid per syntax > > and the LDIF was: > dn: olcDatabase={1}bdb,cn=config > objectClass: olcDatabaseConfig > objectClass: olcbdbConfig > olcDatabase: {1}bdb > olcSuffix: dc=example,dc=com > olcDbDirectory: ./db > olcRootDN: cn=Manager,dc=example,dc=com > olcRootPW: secret > olcSyncRepl: rid=002 provider=ldap://localhost:9011/ > binddn="cn=Manager,dc=example,dc=com" bindmethod=simple > credentials=secret searchbase="dc=example,dc=com" type=refreshOnly > interval=00:00:00:10 > olcUpdateRef: ldap://localhost:9011/ > > dn: olcOverlay=syncprov,olcDatabase={1}bdb,cn=config > changetype: add > objectClass: olcOverlayConfig > objectClass: olcSyncProvConfig > olcOverlay: syncprov > > > > -- -- 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#5117) test049/test050 failures
by kurt＠OpenLDAP.org 01 Sep '07

01 Sep '07

Full_Name: Kurt Zeilenga Version: HEAD OS: MacoSX 10.4.8/FreeBSD 6.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.180.46.200) Submitted by: kurt On both MacOS X and FreeBSD, I see test047 fail trying to configure the server via cn=config. Both built using ./configure --enable-backends --enable-overlays, nothing fancy. Cleaning up test run directory leftover from previous run. Running ./scripts/test049-sync-config... running defines.sh Starting producer slapd on TCP/IP port 9011... Using ldapsearch to check that producer slapd is running... Inserting syncprov overlay on producer... Starting consumer slapd on TCP/IP port 9012... Using ldapsearch to check that consumer slapd is running... Configuring syncrepl on consumer... Waiting 10 seconds for syncrepl to receive changes... Using ldapsearch to check that syncrepl received config changes... Adding schema and databases on producer... ldapadd failed for database config (21)! where test.out contains: ldap_add: Invalid syntax (21) additional info: olcSuffix: value #0 invalid per syntax and the LDIF was: dn: olcDatabase={1}bdb,cn=config objectClass: olcDatabaseConfig objectClass: olcbdbConfig olcDatabase: {1}bdb olcSuffix: dc=example,dc=com olcDbDirectory: ./db olcRootDN: cn=Manager,dc=example,dc=com olcRootPW: secret olcSyncRepl: rid=002 provider=ldap://localhost:9011/ binddn="cn=Manager,dc=example,dc=com" bindmethod=simple credentials=secret searchbase="dc=example,dc=com" type=refreshOnly interval=00:00:00:10 olcUpdateRef: ldap://localhost:9011/ dn: olcOverlay=syncprov,olcDatabase={1}bdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs September 2007