- openldap-bugs - openldap.org

(ITS#5530) OpenLDAP fails to compile
by mike＠tedder.cc 26 May '08

26 May '08

Full_Name: Mike Tedder Version: 2.4.9 OS: powerpc-linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (210.170.158.22) The back-bdb backend for the OpenLDAP slapd server fails to compile when being built using Berkeley DB 4.7: cd back-bdb; make -w all make[3]: Entering directory `/mnt/home/bpoint/src/openldap-2.4.9/servers/slapd/back-bdb' rm -f version.c ../../../build/mkversion -v "2.4.9" back_bdb > version.c /bin/sh ../../..//libtool --tag=disable-shared --mode=compile cc -g -O2 -I../../../include -I../../../include -I.. -I./.. -c init.c cc -g -O2 -I../../../include -I../../../include -I.. -I./.. -c init.c -o init.o init.c: In function `bdb_db_open': init.c:509: error: structure has no member named `lk_handle' init.c: In function `bdb_back_initialize': init.c:752: warning: passing arg 1 of `db_env_set_func_yield' from incompatible pointer type make[3]: *** [init.lo] Error 1 make[3]: Leaving directory `/mnt/home/bpoint/src/openldap-2.4.9/servers/slapd/back-bdb' make[2]: *** [.backend] Error 1 make[2]: Leaving directory `/mnt/home/bpoint/src/openldap-2.4.9/servers/slapd' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/mnt/home/bpoint/src/openldap-2.4.9/servers' make: *** [all-common] Error 1 The reason for this error is because there is no longer a "lk_handle" member inside the DB_ENV structure in /usr/include/db.h. I checked the mailing list archives, and there's not a sign of anyone having this compile error anywhere. I also checked the HEAD revision in CVS, and init.c still uses the lk_handle member variable. I guess no one's upgraded to Berkeley 4.7 yet...? :) To work around the compile error, I have changed: #if DB_VERSION_FULL >= 0x04060012 ...to... #if 0 && DB_VERSION_FULL >= 0x04060012 in all places in init.c and cache.c (the only two files affected), and slapd compiles successfully. I'm not sure if this is the proper way to fix it or not, however...

1 0

(ITS#5529) test048-syncrepl-multiproxy --without-threads hangs
by h.b.furuseth＠usit.uio.no 26 May '08

26 May '08

Full_Name: Hallvard B Furuseth Version: HEAD, RE24 OS: Linux URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-080526.tgz.1 Submission from: (NULL) (129.240.6.233) Submitted by: hallvard RE24 configured with --quiet --without-threads --enable-ldap 'CFLAGS=-O0 -g' $ ./run test048 Cleaning up test run directory leftover from previous run. Running ./scripts/test048-syncrepl-multiproxy... running defines.sh Starting master slapd on TCP/IP port 9011... Using ldapsearch to check that master slapd is running... gdb shows both slapd and ldapsearch waiting in poll(). testrun with backtraces enclosed. Ignore the Hallvard-Furuseth-080526.tgz (without .1) file; ftp created it but did not let me upload it. Needed passive mode to upload.

1 0

Re: (ITS#5521) Can't change indexing of an attribute within a single modification
by rhafer＠suse.de 26 May '08

26 May '08

On Montag, 26. Mai 2008, ando(a)sys-net.it wrote: > rhafer(a)suse.de wrote: > >>> Splitting the above modification in two separate operations works > >>> around that problem. > >> > >> What about using replace instead? > > > > That causes the same behavior as the modification pasted above. So > > it doesn't work as well. > > Also, it might not be very practical if very complex indexing is in > place... Yes. But I think I fixed the original issue now. (r1.39 of servers/slapd/back-bdb/attr.c) -- Ralf

1 0

Re: (ITS#5521) Can't change indexing of an attribute within a single modification
by ando＠sys-net.it 26 May '08

26 May '08

rhafer(a)suse.de wrote: >>> Splitting the above modification in two separate operations works >>> around that problem. >> What about using replace instead? > That causes the same behavior as the modification pasted above. So it > doesn't work as well. Also, it might not be very practical if very complex indexing is in place... 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#5524) Additions to the Security section of the Admin Guide
by ghenry＠OpenLDAP.org 26 May '08

26 May '08

> I've patched security.sdf and I'm abotu to clean up some typos and > formating. Hmm, maybe I should do the same to the e-mails I write ;-)

1 0

Re: (ITS#5521) Can't change indexing of an attribute within a single modification
by rhafer＠suse.de 26 May '08

26 May '08

On Sonntag, 25. Mai 2008, Pierangelo Masarati wrote: > rhafer(a)suse.de wrote: > > The following modification to add an additional index an attribute > > fails with the error messages pasted below: > > > > -------------------------- > > dn: olcDatabase={1}bdb,cn=config > > changetype: modify > > delete: olcdbindex > > olcDbIndex: cn pres,eq > > - > > add: olcdbindex > > olcDbIndex: cn pres,eq,sub > > -------------------------- > > > > modifying entry "olcDatabase={1}bdb,cn=config" > > ldap_modify: Other (e.g., implementation specific) error (80) > > additional info: <olcDbIndex> handler exited with 1 > > > > As far as I can see it fails because the old indexmask hat not yet > > been deleted from the bdb-struct. The ainfo_insert()-call in > > back-bdb/attr.c(bdb_attr_index_config()) returns with -1. > > > > Splitting the above modification in two separate operations works > > around that problem. > > What about using replace instead? That causes the same behavior as the modification pasted above. So it doesn't work as well. -- Ralf

1 0

Re: (ITS#5524) Additions to the Security section of the Admin Guide
by ghenry＠OpenLDAP.org 26 May '08

26 May '08

andrew.findlay(a)skills-1st.co.uk wrote: > Full_Name: Andrew Findlay > Version: 2.4.9 > OS: Linux > URL: http://www.skills-1st.co.uk/pub/code/openldap-guide-patch-20080522 > Submission from: (NULL) (88.97.25.132) > > > This patch adds text to the Security chapter in the Admin Guide. It describes > the password storage schemes, including the {SASL} scheme that triggers > pass-through authentication. The latter facility has existed since version 2.0 > but has never been mentioned in the docs, so I have included a section with an > example of its use. > > I've patched security.sdf and I'm abotu to clean up some typos and formating. Should we also mention that CRYPT is platform specific? Lastly, should I also put: Portions Copyright 2008 Andrew Findlay <andrew.findlay(a)skills-1st.co.uk> into doc/guide/COPYRIGHT ? -- 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#5244) Problem configuring openldap 2.4.6
by h.b.furuseth＠usit.uio.no 26 May '08

26 May '08

pierre42d(a)9online.fr writes: > Ok i agree it's an enhancement request rather than a bug. I know this > environment variables, but my point of view is that /usr/local should > be considered part of default/standard system locations. I don't think we should suddenly mess with these defaults now, but there could be an option to add them to CPPFLAGS and LDFLAGS. Or rather, add $includedir (default /usr/local/include) and $libdir (default /usr/local/lib). -- Hallvard

1 0

(ITS#5528) Problem compiling openldap 2.4.9
by pierre42d＠9online.fr 26 May '08

26 May '08

Full_Name: Pierre Version: 2.4.9 OS: GNU/Linux URL: Submission from: (NULL) (79.82.49.83) # make Making all in /tmp/openldap-2.4.9 Entering subdirectory include make[1]: Entering directory `/tmp/openldap-2.4.9/include' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/tmp/openldap-2.4.9/include' Entering subdirectory libraries make[1]: Entering directory `/tmp/openldap-2.4.9/libraries' Making all in /tmp/openldap-2.4.9/libraries Entering subdirectory liblutil make[2]: Entering directory `/tmp/openldap-2.4.9/libraries/liblutil' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/tmp/openldap-2.4.9/libraries/liblutil' Entering subdirectory liblber make[2]: Entering directory `/tmp/openldap-2.4.9/libraries/liblber' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/tmp/openldap-2.4.9/libraries/liblber' Entering subdirectory liblunicode make[2]: Entering directory `/tmp/openldap-2.4.9/libraries/liblunicode' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/tmp/openldap-2.4.9/libraries/liblunicode' Entering subdirectory libldap make[2]: Entering directory `/tmp/openldap-2.4.9/libraries/libldap' /bin/sh ../..//libtool --mode=link gcc -s -O3 -march=i686 -L/usr/local/BerkeleyDB.4.6/lib -o apitest apitest.o libldap.la ../../libraries/liblber/liblber.la ../../libraries/liblutil/liblutil.a -lsasl2 -lgnutls -lcrypt -lresolv gcc -s -O3 -march=i686 -o .libs/apitest apitest.o -L/usr/local/BerkeleyDB.4.6/lib ./.libs/libldap.so /tmp/openldap-2.4.9/libraries/liblber/.libs/liblber.so -L/usr/local/lib ../../libraries/liblber/.libs/liblber.so ../../libraries/liblutil/liblutil.a /usr/local/lib/libsasl2.so -ldl /usr/local/lib/libgnutls.so /usr/local/lib/libtasn1.so /usr/local/lib/libgcrypt.so -lnsl -lcap /usr/local/lib/libgpg-error.so -lz -lcrypt -lresolv ./.libs/libldap.so: undefined reference to `gnutls_cipher_suite_info' collect2: ld returned 1 exit status make[2]: *** [apitest] Error 1 make[2]: Leaving directory `/tmp/openldap-2.4.9/libraries/libldap' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/tmp/openldap-2.4.9/libraries' make: *** [all-common] Error 1

1 0

Re: (ITS#5244) Problem configuring openldap 2.4.6
by pierre42d＠9online.fr 25 May '08

25 May '08

Ok i agree it's an enhancement request rather than a bug. I know this environment variables, but my point of view is that /usr/local should be considered part of default/standard system locations. Regards,

1 0

Re: (ITS#5521) Can't change indexing of an attribute within a single modification
by ando＠sys-net.it 25 May '08

25 May '08

rhafer(a)suse.de wrote: > The following modification to add an additional index an attribute fails with > the error messages pasted below: > > -------------------------- > dn: olcDatabase={1}bdb,cn=config > changetype: modify > delete: olcdbindex > olcDbIndex: cn pres,eq > - > add: olcdbindex > olcDbIndex: cn pres,eq,sub > -------------------------- > > modifying entry "olcDatabase={1}bdb,cn=config" > ldap_modify: Other (e.g., implementation specific) error (80) > additional info: <olcDbIndex> handler exited with 1 > > As far as I can see it fails because the old indexmask hat not yet been deleted > from the bdb-struct. The ainfo_insert()-call in > back-bdb/attr.c(bdb_attr_index_config()) returns with -1. > > Splitting the above modification in two separate operations works around that > problem. What about using replace instead? 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#5517) add superclass of existing class fails
by ando＠sys-net.it 25 May '08

25 May '08

Kurt Zeilenga wrote: > > On May 24, 2008, at 2:18 AM, ando(a)sys-net.it wrote: > >> I believe the actual implementation should be... implementation >> dependent :), provided it is consistent. > > I agree there is a slight inconsistency. > > A client can delete a listed superclass but not add an superclass of a > listed attribute. > > One could argue that both be considered invalid operations. However, it > would be reasonable to consider an add of an unlisted superclass and a > delete of a listed superclass to be valid. However, a add of an already > listed class should be invalid and a delete of a unlisted class should > always be invalid. Agreed. With respect to the current implementation, we're back to square one, since the issue is related to using objectSubClassMatch() to check for the presence of a value. Any superclass is returned as present no matter if it is actually present or just implied. From your answers, it seems that treating objectClass specially should be the solution, and the fix I'm proposing goes in this direction. Should I commit it, or does anyone see any side effect? 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#5517) add superclass of existing class fails
by Kurt＠OpenLDAP.org 25 May '08

25 May '08

On May 24, 2008, at 2:18 AM, ando(a)sys-net.it wrote: > I believe the actual implementation should be... implementation > dependent :), provided it is consistent. I agree there is a slight inconsistency. A client can delete a listed superclass but not add an superclass of a listed attribute. One could argue that both be considered invalid operations. However, it would be reasonable to consider an add of an unlisted superclass and a delete of a listed superclass to be valid. However, a add of an already listed class should be invalid and a delete of a unlisted class should always be invalid. -- Kurt

1 0

Re: (ITS#5517) add superclass of existing class fails
by Kurt＠OpenLDAP.org 25 May '08

25 May '08

On May 24, 2008, at 2:37 PM, h.b.furuseth(a)usit.uio.no wrote: > ando(a)sys-net.it writes: >> The issue right now is caused by the fact that comparing present >> values with the asserted one causes objectSubClassMatch() to check >> for >> match including superiors. > > This looks like a bug to me. Maybe in the RFCs. > objectClass has EQUALITY matching rule > objectIdentifierMatch, which does not follow the object class > inheritance chain. Yes, but objectClass is quite special (despite being a userApplications attribute). For instance, (objectClass=*) is to match DSEs which don't have an objectClass attribute. Likewise, objectClass=foo can match objectClass attributes which don't explicitly contain foo. > See RFC 4517 section 4.2.26. RFC 4512 section 3.3 > (the 'objectClass' attribute) does not special-case this. > > What makes slapd work is that it also disobeys RFC 4512 section 3.3: > "When creating an entry or adding an 'objectClass' value to an > entry, > all superclasses of the named classes SHALL be implicitly added as > well if not already present." > This doesn't say the classes shall be considered to be implicitly > present, like slapd does. You are reading 3.3 as if it said "SHALL be added (by the server)". It doesn't say "SHALL be added (by the server). It says "SHALL be implicitly added" (presumedly by the server). This was discussed during LDAPbis discussions. As the Editor of RFC 4512, I can say that it was my intent to allow servers to merely treat superclasses as being present. > Instead slapd should add the missing classes to the actual object, Doing so is problematic. A client which adds B then deletes B would be surprised by non-net-zero result of the operation(s). > just like it adds some other attribute/values > implicitly (createTimestamp, subschemaSubentry, etc). These are operational attributes. ObjectClass is an userApplications attribute. Servers should not muck with the values of userApplication attributes. > I don't know what to do about it now though. Will replication work > between current servers and servers which obeys the RFCs? Is this a > RE25 > fix, so we should stay with fixed like previously suggested in > RE24? Or > yet another thing to do with the last RE23, for the sake of > replication? > > -- > Hallvard > >

1 0

Re: (ITS#5517) add superclass of existing class fails
by Kurt＠OpenLDAP.org 25 May '08

25 May '08

On May 18, 2008, at 11:09 AM, h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: Linux > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > If objectclass B is a subclass of A, and an entry contains > objectclass B > but not A, slapd returns attributeOrValueExists to a request to add A. Yes, A is implicitly present (by implicit add). > OTOH it allows replace(objectClass: <A, B>), and after that it allows > delete(objectClass: A). This is inconsistent. This can be argued to be incorrect. It is improper to attempt to delete a superclass of any listed class. > If the objectClass attribute contains B, does it "really" contain A as > well? If provided by the client, yes. Otherwise A is implicitly present due to B. When a client adds B then deletes B, its a net zero result. If A were actually added by the server, the delete of B would either leave A behind or be invalid (such as when A is abstract). > I couldn't find such a statement in the RFCs, The RFCs are someone vague here. > so my guess is that add(objectClass: A) should be allowed. Adding A when a subclass is present is just as invalid as deleting A when a subclass is present. Both should result in errors. > Though I haven't looked > all that hard. > > Example: > > ldapadd -cx <<'EOF' > # Create initial object > dn: c=NO > objectClass: friendlyCountry > c: NO > co: Norway > > # error > dn: c=NO > changetype: modify > add: objectClass > objectClass: top > - > > # error > dn: c=NO > changetype: modify > add: objectClass > objectClass: country > - > > # success > dn: c=NO > changetype: modify > replace: objectClass > objectClass: top > objectClass: country > objectClass: friendlyCountry > - > > # success > dn: c=NO > changetype: modify > delete: objectClass > objectClass: top > - > > # success > dn: c=NO > changetype: modify > delete: objectClass > objectClass: country > - > EOF > >

1 0

Re: (ITS#5517) add superclass of existing class fails
by h.b.furuseth＠usit.uio.no 25 May '08

25 May '08

h.b.furuseth(a)usit.uio.no writes: > This looks like a bug to me. objectClass has EQUALITY matching rule > objectIdentifierMatch, which does not follow the object class > inheritance chain. (...) > > What makes slapd work is that it also disobeys RFC 4512 section 3.3: Oops, I meant the opposite: It's 1st bug which slapd with 2nd bug work. -- Hallvard

1 0

Re: (ITS#5517) add superclass of existing class fails
by h.b.furuseth＠usit.uio.no 24 May '08

24 May '08

ando(a)sys-net.it writes: > The issue right now is caused by the fact that comparing present > values with the asserted one causes objectSubClassMatch() to check for > match including superiors. This looks like a bug to me. objectClass has EQUALITY matching rule objectIdentifierMatch, which does not follow the object class inheritance chain. See RFC 4517 section 4.2.26. RFC 4512 section 3.3 (the 'objectClass' attribute) does not special-case this. What makes slapd work is that it also disobeys RFC 4512 section 3.3: "When creating an entry or adding an 'objectClass' value to an entry, all superclasses of the named classes SHALL be implicitly added as well if not already present." This doesn't say the classes shall be considered to be implicitly present, like slapd does. Instead slapd should add the missing classes to the actual object, just like it adds some other attribute/values implicitly (createTimestamp, subschemaSubentry, etc). I don't know what to do about it now though. Will replication work between current servers and servers which obeys the RFCs? Is this a RE25 fix, so we should stay with fixed like previously suggested in RE24? Or yet another thing to do with the last RE23, for the sake of replication? -- Hallvard

1 0

Re: (ITS#5517) add superclass of existing class fails
by ando＠sys-net.it 24 May '08

24 May '08

ando(a)sys-net.it wrote: > ando(a)sys-net.it wrote: >> h.b.furuseth(a)usit.uio.no wrote: >>> Full_Name: Hallvard B Furuseth >>> Version: HEAD >>> OS: Linux >>> URL: >>> Submission from: (NULL) (129.240.6.233) >>> Submitted by: hallvard >>> >>> >>> If objectclass B is a subclass of A, and an entry contains objectclass B >>> but not A, slapd returns attributeOrValueExists to a request to add A. >>> OTOH it allows replace(objectClass: <A, B>), and after that it allows >>> delete(objectClass: A). This is inconsistent. >>> >>> If the objectClass attribute contains B, does it "really" contain A as >>> well? I couldn't find such a statement in the RFCs, so my guess is >>> that add(objectClass: A) should be allowed. Though I haven't looked >>> all that hard. >> I believe the actual implementation should be... implementation >> dependent :), provided it is consistent. Right now, the issue you >> noticed is caused by the fact that the presence of the value being added >> is checked by using the objectClass attribute equality rule implemented >> in objectSubClassMatch(), which (correctly) returns a match both for >> exact and inherited match. However, this does not allow to discriminate >> the actual presence of an objectClass from its inherited presence. We >> should either: >> >> a) use a separate matching rule when checking for value presence, or >> >> b) always remove superior objectClasses, and transparently ignore any >> attempt to add them to an entry (the operation succeeds, but nothing is >> actually written). >> >> In any case, the code as is now seems to be inconsistent, as it does not >> allow a modification that should be perfectly legitimate, regardless of >> how it is actually dealt with by the implementation. >> >> I vote in favor of option (b). > > Probably, the "right" fix requires to extend the concept of equality > match, to distinguish between "match" in the sense of filtering and > "match" in the sense of literal match. Something like that already > occurs: see SLAP_MR_VALUE_OF_ASSERTION_SYNTAX vs. > SLAP_MR_VALUE_OF_ATTRIBUTE_SYNTAX. The issue right now is caused by the > fact that comparing present values with the asserted one causes > objectSubClassMatch() to check for match including superiors. Match > functions should be able to return an indication about whether the match > was literal or not, sort of a return flag indicating if the match was > SLAP_MR_VALUE_OF_ATTRIBUTE_SYNTAX or SLAP_MR_VALUE_OF_ASSERTION_SYNTAX. > This will probably require some significant API change in the match > routines, unless the related information can be safely ORed to the > return value. Quick hack along the lines of option (a): diff -u -r1.65 mods.c --- servers/slapd/mods.c 7 Jan 2008 23:20:08 -0000 1.65 +++ servers/slapd/mods.c 24 May 2008 13:09:44 -0000 @@ -99,7 +99,13 @@ * server (whether from LDAP or from the underlying * database). */ - flags = SLAP_MR_EQUALITY | SLAP_MR_VALUE_OF_ASSERTION_SYNTAX; + if ( a->a_desc == slap_schema.si_ad_objectClass ) { + /* Needed by ITS#5517 */ + flags = SLAP_MR_EQUALITY | SLAP_MR_VALUE_OF_ATTRIBUTE_SYNTAX; + + } else { + flags = SLAP_MR_EQUALITY | SLAP_MR_VALUE_OF_ASSERTION_SYNTAX; + } if ( mod->sm_nvalues ) { flags |= SLAP_MR_ASSERTED_VALUE_NORMALIZED_MATCH | SLAP_MR_ATTRIBUTE_VALUE_NORMALIZED_MATCH; 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#5517) add superclass of existing class fails
by ando＠sys-net.it 24 May '08

24 May '08

ando(a)sys-net.it wrote: > h.b.furuseth(a)usit.uio.no wrote: >> Full_Name: Hallvard B Furuseth >> Version: HEAD >> OS: Linux >> URL: >> Submission from: (NULL) (129.240.6.233) >> Submitted by: hallvard >> >> >> If objectclass B is a subclass of A, and an entry contains objectclass B >> but not A, slapd returns attributeOrValueExists to a request to add A. >> OTOH it allows replace(objectClass: <A, B>), and after that it allows >> delete(objectClass: A). This is inconsistent. >> >> If the objectClass attribute contains B, does it "really" contain A as >> well? I couldn't find such a statement in the RFCs, so my guess is >> that add(objectClass: A) should be allowed. Though I haven't looked >> all that hard. > > I believe the actual implementation should be... implementation > dependent :), provided it is consistent. Right now, the issue you > noticed is caused by the fact that the presence of the value being added > is checked by using the objectClass attribute equality rule implemented > in objectSubClassMatch(), which (correctly) returns a match both for > exact and inherited match. However, this does not allow to discriminate > the actual presence of an objectClass from its inherited presence. We > should either: > > a) use a separate matching rule when checking for value presence, or > > b) always remove superior objectClasses, and transparently ignore any > attempt to add them to an entry (the operation succeeds, but nothing is > actually written). > > In any case, the code as is now seems to be inconsistent, as it does not > allow a modification that should be perfectly legitimate, regardless of > how it is actually dealt with by the implementation. > > I vote in favor of option (b). Probably, the "right" fix requires to extend the concept of equality match, to distinguish between "match" in the sense of filtering and "match" in the sense of literal match. Something like that already occurs: see SLAP_MR_VALUE_OF_ASSERTION_SYNTAX vs. SLAP_MR_VALUE_OF_ATTRIBUTE_SYNTAX. The issue right now is caused by the fact that comparing present values with the asserted one causes objectSubClassMatch() to check for match including superiors. Match functions should be able to return an indication about whether the match was literal or not, sort of a return flag indicating if the match was SLAP_MR_VALUE_OF_ATTRIBUTE_SYNTAX or SLAP_MR_VALUE_OF_ASSERTION_SYNTAX. This will probably require some significant API change in the match routines, unless the related information can be safely ORed to the return value. 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#5505) Attribute value for 'modifiersName' in case of overlays
by ando＠sys-net.it 24 May '08

24 May '08

ando(a)sys-net.it wrote: >> Just a feature request for convenience: >> >> Would it be possible to set the value of attribute 'modifiersName' to the >> DN of >> the overlays' configuration entry under cn=config if an entry was modified >> by an >> overlay? In this case one would have a direct link to the configuration if >> needed. Currently 'cn=<overlay name>' (e.g cn=Referential Integrity >> Overlay) is >> added which does not refer to an existing entry at all. > > Technically, I don't see any problem, except that overlays (and software > modules, in general) do not hold a direct reference to their config > entry's DN, if any (e.g. when back-config is not in use, the data > structure is in place, but not in LDIF form; please correct me if I'm > wrong). I wonder whether exposing such detail makes sense, or risks > breaking any security. Probably I'm getting paranoid... As a quick fix to your legitimate issue, I've added to HEAD the refint_modifiersname parameter that allows to customize the name used for internal modifications. Please test. 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#5517) add superclass of existing class fails
by ando＠sys-net.it 24 May '08

24 May '08

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: Linux > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > If objectclass B is a subclass of A, and an entry contains objectclass B > but not A, slapd returns attributeOrValueExists to a request to add A. > OTOH it allows replace(objectClass: <A, B>), and after that it allows > delete(objectClass: A). This is inconsistent. > > If the objectClass attribute contains B, does it "really" contain A as > well? I couldn't find such a statement in the RFCs, so my guess is > that add(objectClass: A) should be allowed. Though I haven't looked > all that hard. I believe the actual implementation should be... implementation dependent :), provided it is consistent. Right now, the issue you noticed is caused by the fact that the presence of the value being added is checked by using the objectClass attribute equality rule implemented in objectSubClassMatch(), which (correctly) returns a match both for exact and inherited match. However, this does not allow to discriminate the actual presence of an objectClass from its inherited presence. We should either: a) use a separate matching rule when checking for value presence, or b) always remove superior objectClasses, and transparently ignore any attempt to add them to an entry (the operation succeeds, but nothing is actually written). In any case, the code as is now seems to be inconsistent, as it does not allow a modification that should be perfectly legitimate, regardless of how it is actually dealt with by the implementation. I vote in favor of option (b). 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#5527) Segmentation fault in dynlist.c
by hyc＠symas.com 23 May '08

23 May '08

zulcss(a)ubuntu.com wrote: > Full_Name: Chuck Short > Version: 3.2.7 > OS: Ubuntu > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.142.121.161) > > > Hello, > > We have recieved a bug report about a segmentation fault using dynlist. You can > find the bug report at: > > http://bugs.launchpad.net/bugs/218734 > > If you have any questions please feel free to ask. I was able to reproduce your crash in 2.4.7 but not in 2.4.9. 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#5526) Another segmentation fault
by hyc＠symas.com 23 May '08

23 May '08

quanah(a)zimbra.com wrote: > --On Friday, May 23, 2008 9:02 AM +0000 zulcss(a)ubuntu.com wrote: > >> Full_Name: Chuck Short >> Version: 3.2.7 >> OS: Ubuntu >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (82.142.121.161) >> >> >> Hello, >> >> We received another report of a segmentation fault in openldap 3.2.7. The >> bug report with the test case can be found at: >> >> http://bugs.launchpad.net/bugs/234196 >> >> If you have any questions please let me know. > > Sure. What is OpenLDAP 3.2.7? And the bug reported here was already fixed > in OpenLDAP 2.4.9 IIRC. Please validate bugs against 2.4.9 before filing > an ITS. Actually no, this particular bug was still present in 2.4.9. A patch is in HEAD and still needs testing. Some of the other recently filed ones were already fixed though. -- -- 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#5526) Another segmentation fault
by quanah＠zimbra.com 23 May '08

23 May '08

--On Friday, May 23, 2008 8:09 AM -0700 Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Friday, May 23, 2008 9:02 AM +0000 zulcss(a)ubuntu.com wrote: > >> Full_Name: Chuck Short >> Version: 3.2.7 >> OS: Ubuntu >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (82.142.121.161) >> >> >> Hello, >> >> We received another report of a segmentation fault in openldap 3.2.7. The >> bug report with the test case can be found at: >> >> http://bugs.launchpad.net/bugs/234196 >> >> If you have any questions please let me know. > > Sure. What is OpenLDAP 3.2.7? And the bug reported here was already > fixed in OpenLDAP 2.4.9 IIRC. Please validate bugs against 2.4.9 before > filing an ITS. Okay, ignore me. I was thinking of a different assertion failure fixed by 2.4.9. :P But 3.2.7 still is not a valid OpenLDAP release. ;) --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5526) Another segmentation fault
by quanah＠zimbra.com 23 May '08

23 May '08

--On Friday, May 23, 2008 9:02 AM +0000 zulcss(a)ubuntu.com wrote: > Full_Name: Chuck Short > Version: 3.2.7 > OS: Ubuntu > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.142.121.161) > > > Hello, > > We received another report of a segmentation fault in openldap 3.2.7. The > bug report with the test case can be found at: > > http://bugs.launchpad.net/bugs/234196 > > If you have any questions please let me know. Sure. What is OpenLDAP 3.2.7? And the bug reported here was already fixed in OpenLDAP 2.4.9 IIRC. Please validate bugs against 2.4.9 before filing an ITS. Thanks, Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5506) syncprov crash with RE24 CVS
by hyc＠symas.com 23 May '08

23 May '08

Mark Cave-Ayland wrote: > Mark Cave-Ayland wrote: > >> Okay. I've arranged for a set of new packages (based upon HEAD) to be >> built and installed tomorrow, so will feedback on progress in a few days >> after the new packages have had time to settle in. > > Just to feedback on this bug: we have been running packages from CVS > HEAD dated 2008-05-14 on our client setup (which is basically openldap > 2.4.9 plus fixes for ITS#5503 and ITS#5506), and I am pleased to report > that we have had no more core files produced since the packages were > installed in the middle of last week. > > I'm happy for this ticket to be closed, plus I would suggest closing > ITS#5501, which since it hasn't occurred since, is likely to be another > symptom of this bug. Thanks for the followup. We'll close this and #5501 with 2.4.10. -- -- 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#5506) syncprov crash with RE24 CVS
by mark.cave-ayland＠siriusit.co.uk 23 May '08

23 May '08

Mark Cave-Ayland wrote: > Okay. I've arranged for a set of new packages (based upon HEAD) to be > built and installed tomorrow, so will feedback on progress in a few days > after the new packages have had time to settle in. Just to feedback on this bug: we have been running packages from CVS HEAD dated 2008-05-14 on our client setup (which is basically openldap 2.4.9 plus fixes for ITS#5503 and ITS#5506), and I am pleased to report that we have had no more core files produced since the packages were installed in the middle of last week. I'm happy for this ticket to be closed, plus I would suggest closing ITS#5501, which since it hasn't occurred since, is likely to be another symptom of this bug. Thanks once again for your help, Mark. -- Mark Cave-Ayland Sirius Corporation - The Open Source Experts http://www.siriusit.co.uk T: +44 870 608 0063

1 0

(ITS#5527) Segmentation fault in dynlist.c
by zulcss＠ubuntu.com 23 May '08

23 May '08

Full_Name: Chuck Short Version: 3.2.7 OS: Ubuntu URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.142.121.161) Hello, We have recieved a bug report about a segmentation fault using dynlist. You can find the bug report at: http://bugs.launchpad.net/bugs/218734 If you have any questions please feel free to ask. Thanks chuck

1 0

(ITS#5526) Another segmentation fault
by zulcss＠ubuntu.com 23 May '08

23 May '08

Full_Name: Chuck Short Version: 3.2.7 OS: Ubuntu URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.142.121.161) Hello, We recieved another report of a segmentation fault in openldap 3.2.7. The bug report with the test case can be found at: http://bugs.launchpad.net/bugs/234196 If you have any questions please let me know. Thanks chuck

1 0

Re: (ITS#5518) Assertion error in io.c:234: ber_flush2
by hyc＠symas.com 23 May '08

23 May '08

Howard Chu wrote: > paul(a)mad-scientist.us wrote: >> Hi all; I just posted a new bug 5525 that describes exactly how this >> happens and where the bug is. I came to this conclusion while trying to >> find a crasher in Evolution Exchange: I ran it under valgrind to find >> the use of freed memory. >> >> Hopefully this will provide us with a quick fix! > > Thanks for tracking this down Paul. I think you've nailed it for us, we should > be able to patch this pretty soon. > I replied to #5525 that a patch for this is now in HEAD. Please test. I've now closed #5525 as a dup of this bug. -- -- 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#5429) component Matching
by hyc＠symas.com 23 May '08

23 May '08

ron(a)zytrax.com wrote: > Full_Name: Ron Aitchison > Version: 2.4.8 > OS: FreeBSD (5.4/6.2) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (209.148.181.131) > > > Component matching (RFC 3687) is defined to be released with 2.4.8. However it > is conditionally compiled from the variable LDAP_COMP_MATCH which is only set > (in servers/slapd/slap.h) if LDAP_DEVEL is set. LDAP_DEVEL is not set by default > in a normal build. The net result is that component matching is not included in > an OpenLDAP build. It's not clear that this feature is safe for use. It's certain that indexing for component matching in back-bdb is broken. Unindexed matching may or may not work. The lead developer on this feature is gone, so until someone else comes along to adopt the code it's going to remain DEVEL-only. -- -- 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#5525) libldap causes a core dump due to accessing freed memory
by hyc＠symas.com 23 May '08

23 May '08

paul(a)mad-scientist.us wrote: > Full_Name: Paul Smith > Version: 2.4.7 > OS: Ubuntu 8.04 > URL: > Submission from: (NULL) (65.78.30.67) > If you check ldap_free_connection() you'll see that it removes the LDAPConn > pointer "lc" from the list of connections before it is freed. > > BUT! The ldap_free_connection() function never does anything with the > ld->ld_defconn pointer, so if the connection we just freed is the one pointed to > by ld->ld_defconn, it is now pointing to freed memory. And that causes the > problem detected above by valgrind, or causing an assert later on: accessing > freed memory. > > I'm not really sure what the right thing to do here is, or I'd provide a patch. > Should we set ld_defconn to NULL? Is that ever a valid state? Or should we > just pick another connection from the list (and what if there isn't one?) A fix is now in HEAD, please test. The solution sets ld_defconn to NULL, and also closes ld->ld_sb if necessary. In that case, ldap_send_initial_request will create a new defconn before calling ldap_send_server_request. -- -- 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

Permission denied while opening odbcinst.ini
by Andreas Backman 23 May '08

23 May '08

Hi all! I'm trying to configure an OpenLDAP server with a mySQL server as back-end. This is what happens when i try to start the server. root@ldap:~# slapd -d1 --------- backsql_open_db_handle(): SQLConnect() to database "MySQL" failed. Return code: -1 nativeErrCode=0 SQLengineState=IM002 msg="[unixODBC][Driver Manager]Data source name not found, and no default driver specified" --------- I couldn't find anything wrong with my configuration (see odbc.ini and odbcinst.ini below) so i tried strace: root@ldap:~# strace -o /tmp/out.txt slapd root@ldap:~# grep odbc /tmp/out.txt open("/usr/lib/libodbc.so.1", O_RDONLY) = 3 open("/etc/odbcinst.ini", O_RDONLY) = -1 EACCES (Permission denied) access("/etc/odbc.ini", F_OK) = 0 stat64("/etc/odbc.ini", {st_mode=S_IFREG|0644, st_size=598, ...}) = 0 open("/etc/odbcinst.ini", O_RDONLY) = -1 EACCES (Permission denied) Permissions of odbc.ini and odbcinst.ini root@ldap:/etc# ls odbc*.ini -l -rw-r--r-- 1 root root 598 2008-05-23 08:50 odbc.ini -rw-r--r-- 1 root root 549 2008-05-23 08:49 odbcinst.ini Contents of my odbc.ini and odbcinst.ini: odbc.ini: --------- [MySQL] Description = MySQL test database Driver = MySQL SERVER = 192.168.100.38 USER = root PASSWORD = *** PORT = 3306 DATABASE = kplatsen ---------- odbsinst.ini ---------- [MySQL] Description = MySQL driver for Linux & Win32 Driver = /usr/lib/odbc/libmyodbc3.so Setup = /usr/lib/odbc/libmyodbc3S.so FileUsage = 1 [Default] Driver = /usr/lib/odbc/libmyodbc.so UsageCount = 1 ---------- I've tested the ODBC-connection with: root@ldap:~# isql MySQL and it works... Please help!

1 0

Re: (ITS#5518) Assertion error in io.c:234: ber_flush2
by hyc＠symas.com 23 May '08

23 May '08

paul(a)mad-scientist.us wrote: > Hi all; I just posted a new bug 5525 that describes exactly how this > happens and where the bug is. I came to this conclusion while trying to > find a crasher in Evolution Exchange: I ran it under valgrind to find > the use of freed memory. > > Hopefully this will provide us with a quick fix! Thanks for tracking this down Paul. I think you've nailed it for us, we should be able to patch this pretty soon. -- -- 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#5522) Quarantine causes segmentation fault
by quanah＠zimbra.com 23 May '08

23 May '08

--On Thursday, May 22, 2008 3:11 PM +0000 andrew.graham(a)agustawestland.com wrote: > Full_Name: Drew Graham > Version: 2.4.9 > OS: SUSE 10 > URL: > Submission from: (NULL) (194.169.32.250) > ******************* > > Slapd then exits with Segmentation Fault. Gdb shows... This bug has been patched by Pierangelo in HEAD, and it will be in the 2.3.42 and 2.4.10 releases. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5518) Assertion error in io.c:234: ber_flush2
by paul＠mad-scientist.us 23 May '08

23 May '08

Hi all; I just posted a new bug 5525 that describes exactly how this happens and where the bug is. I came to this conclusion while trying to find a crasher in Evolution Exchange: I ran it under valgrind to find the use of freed memory. Hopefully this will provide us with a quick fix!

1 0

(ITS#5525) libldap causes a core dump due to accessing freed memory
by paul＠mad-scientist.us 23 May '08

23 May '08

Full_Name: Paul Smith Version: 2.4.7 OS: Ubuntu 8.04 URL: Submission from: (NULL) (65.78.30.67) I've been trying to track down a crasher in Evolution's Exchange server backend, and I believe it's a bug in OpenLDAP's libldap. The core manifests as an assert() in io.c:ber_flush2(), but by using valgrind I can see that the real problem is using already-freed memory. You can see various backtraces and valgrind outputs in the Gnome bug tracking system here: http://bugzilla.gnome.org/show_bug.cgi?id=512605 Note that the later stack traces are better as I've installed debugging versions of OpenLDAP so there are better symbols shown. In Evolution we have a loop we use to look up global contacts, which looks like this: for (try = 0; try < 2; try++) { ldap_error = get_gc_connection (gc, op); if (ldap_error != LDAP_SUCCESS) return ldap_error; ldap_error = ldap_search_ext (gc->priv->ldap, base, scope, filter, (char **)attrs, FALSE, NULL, NULL, NULL, 0, &msgid); if (ldap_error == LDAP_SERVER_DOWN) continue; else if (ldap_error != LDAP_SUCCESS) return ldap_error; ldap_error = gc_ldap_result (gc->priv->ldap, op, msgid, msg); if (ldap_error == LDAP_SERVER_DOWN) continue; else if (ldap_error != LDAP_SUCCESS) return ldap_error; return LDAP_SUCCESS; } where get_gc_connection() eventually calls ldap_ntlm_bind() and where gc_ldap_result() calls ldap_result(). When the core happens, the first trip through the for loop here gives an error LDAP_SERVER_DOWN as the return code from ldap_result(). We go back to the top of the loop, and ldap_ntlm_bind() is called. That eventually ends up in ldap_send_initial_request() which invokes ldap_send_server_request() like this: rc = ldap_send_server_request( ld, ber, msgid, NULL, NULL, NULL, NULL ); Inside ldap_send_server_request() we need to find an LDAPConn* structure, but the one passed in is NULL as is the srvlist, so, we use the default connection: if ( lc == NULL ) { if ( srvlist == NULL ) { lc = ld->ld_defconn; Valgrind reports that the very next line, attempting to access lc->lconn_status, is referencing freed memory: if ( lc != NULL && lc->lconn_status == LDAP_CONNST_CONNECTING ) { So, basically, we know that ld->ld_defconn is a non-NULL pointer pointing to already freed memory. This seems like it is a buggy state. How did we get here? In ldap_result() we get into this loop invoking try_read1msg() (I'm removing the mutex locking for readability, even though it IS enabled in my version of libldap): for ( lc = ld->ld_conns; rc == LDAP_MSG_X_KEEP_LOOKING && lc != NULL; ) { if ( lc->lconn_status == LDAP_CONNST_CONNECTED && ldap_is_read_ready( ld, lc->lconn_sb ) ) { rc = try_read1msg( ld, msgid, all, &lc, result ); if ( lc == NULL ) { /* if lc gets free()'d, * there's no guarantee * lc->lconn_next is still * sane; better restart * (ITS#4405) */ lc = ld->ld_conns; /* don't get to next conn! */ break; } } /* next conn */ lc = lc->lconn_next; } Inside try_read1msg() we call "tag = ber_get_next( lc->lconn_sb, &len, ber );" and if the tag we get back is LBER_DEFAULT, then we declare an error and we free the connection and set the pointer to NULL: case LBER_DEFAULT: ld->ld_errno = LDAP_SERVER_DOWN; ldap_free_connection( ld, lc, 1, 0 ); lc = *lcp = NULL; return -1; If you check ldap_free_connection() you'll see that it removes the LDAPConn pointer "lc" from the list of connections before it is freed. BUT! The ldap_free_connection() function never does anything with the ld->ld_defconn pointer, so if the connection we just freed is the one pointed to by ld->ld_defconn, it is now pointing to freed memory. And that causes the problem detected above by valgrind, or causing an assert later on: accessing freed memory. I'm not really sure what the right thing to do here is, or I'd provide a patch. Should we set ld_defconn to NULL? Is that ever a valid state? Or should we just pick another connection from the list (and what if there isn't one?)

1 0

Re: (ITS#5523) BDB 4.7 support
by hyc＠symas.com 22 May '08

22 May '08

hyc(a)symas.com wrote: > Hooray, they've finally got a partitioned lock manager. The lock subsystem has > always been a huge bottleneck in previous releases... (Relatively speaking. Back in OpenLDAP 2.0 we had plenty of other problems, but today most of those are gone, and BerkeleyDB's lock manager is quite conspicuous in current profile results...) -- -- 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#5523) BDB 4.7 support
by hyc＠symas.com 22 May '08

22 May '08

quanah(a)zimbra.com wrote: > --On Thursday, May 22, 2008 7:28 PM +0000 quanah(a)OpenLDAP.org wrote: > > Change log at: > > <http://www.oracle.com/technology/documentation/berkeley-db/db/ref/changelog…> Hooray, they've finally got a partitioned lock manager. The lock subsystem has always been a huge bottleneck in previous releases... The last time I looked at 4.7, the main problem was that they stopped exporting the __lock_getlocker() function. As a quick hack to allow testing the rest of OpenLDAP, I just patched it back in to my copy. The clean approach would be to once again resurrect the long-lived read-transaction code that we dropped a long time back. -- -- 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#5523) BDB 4.7 support
by quanah＠zimbra.com 22 May '08

22 May '08

--On Thursday, May 22, 2008 7:28 PM +0000 quanah(a)OpenLDAP.org wrote: Change log at: <http://www.oracle.com/technology/documentation/berkeley-db/db/ref/changelog…> --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5524) Additions to the Security section of the Admin Guide
by andrew.findlay＠skills-1st.co.uk 22 May '08

22 May '08

Full_Name: Andrew Findlay Version: 2.4.9 OS: Linux URL: http://www.skills-1st.co.uk/pub/code/openldap-guide-patch-20080522 Submission from: (NULL) (88.97.25.132) This patch adds text to the Security chapter in the Admin Guide. It describes the password storage schemes, including the {SASL} scheme that triggers pass-through authentication. The latter facility has existed since version 2.0 but has never been mentioned in the docs, so I have included a section with an example of its use.

1 0

(ITS#5523) BDB 4.7 support
by quanah＠OpenLDAP.org 22 May '08

22 May '08

Full_Name: Quanah Gibson-Mount Version: HEAD/RE24 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.23.156.219) BDB 4.7 is officially released. We should add support for it.

1 0

(ITS#5522) Quarantine causes segmentation fault
by andrew.graham＠agustawestland.com 22 May '08

22 May '08

Full_Name: Drew Graham Version: 2.4.9 OS: SUSE 10 URL: Submission from: (NULL) (194.169.32.250) I've set up a meta directory with openldap, which has worked flawlessly until now. If I set the 'quarantine' directive slapd fails to start, giving a segmentation fault. This occurs every time I use quarantine, on two different distros, on any version of openldap that I've tested (2.3.39, 2.3.41, 2.4.9), with both my usual config file and a very simple config file. As an example, I built openldap 2.4.9 on suse 10 with the following configure line... # ./configure --prefix=/usr/local/ldap3 --enable-meta --enable-ldap Slapd.conf looks like... ******************* include /usr/local/ldap/etc/openldap/schema/core.schema include /usr/local/ldap/etc/openldap/schema/cosine.schema include /usr/local/ldap/etc/openldap/schema/inetorgperson.schema pidfile /usr/local/ldap/var/run/slapd.pid argsfile /usr/local/ldap/var/run/slapd.args database meta suffix "dc=example,dc=com" rootdn "cn=manager,dc=example,dc=com" rootpw "secret" quarantine 1800,3 uri "ldap://ldap.example.com/dc=example,dc=com" ******************* Obviously my normal config looks nothing like this, but running this config gets the same result. the last few lines that slapd will output with full debug gives... ****************** line 9 (pidfile /usr/local/ldap/var/run/slapd.pid) line 9 (pidfile /usr/local/ldap/var/run/slapd.pid) line 9 (pidfile /usr/local/ldap/var/run/slapd.pid) line 10 (argsfile /usr/local/ldap/var/run/slapd.args) line 13 (database meta) line 14 (suffix "dc=example,dc=com") >>> dnPrettyNormal: <dc=example,dc=com> => ldap_bv2dn(dc=example,dc=com,0) <= ldap_bv2dn(dc=example,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=example,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=example,dc=com)=0 <<< dnPrettyNormal: <dc=example,dc=com>, <dc=example,dc=com> line 16 (rootdn "cn=manager,dc=example,dc=com") >>> dnPrettyNormal: <cn=manager,dc=example,dc=com> => ldap_bv2dn(cn=manager,dc=example,dc=com,0) <= ldap_bv2dn(cn=manager,dc=example,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=manager,dc=example,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=manager,dc=example,dc=com)=0 <<< dnPrettyNormal: <cn=manager,dc=example,dc=com>, <cn=manager,dc=example,dc=co m> line 17 (rootpw ***) line 19 (quarantine 1800,3) ******************* Slapd then exits with Segmentation Fault. Gdb shows... ****************** Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1211279696 (LWP 19080)] 0x081296d0 in ?? () ****************** Thanks is advance! Drew Graham

1 0

Segmentation fault with quarantine
by Andrew Graham 22 May '08

22 May '08

*** Before acting on this email or opening any attachment you are advised to read the disclaimer at the end of this email *** I've set up a meta directory with openldap, which has worked flawlessly until now. If I set the 'quarantine' directive slapd fails to start, giving a segmentation fault. This occurs every time I use quarantine, on two different distros, on any version of openldap that I've tested (2.3.39, 2.3.41, 2.4.9), with both my usual config file and a very simple config file. As an example, I built openldap 2.4.9 on suse 10 with the following configure line... # ./configure --prefix=/usr/local/ldap3 --enable-meta --enable-ldap Slapd.conf looks like... ******************* include /usr/local/ldap/etc/openldap/schema/core.schema include /usr/local/ldap/etc/openldap/schema/cosine.schema include /usr/local/ldap/etc/openldap/schema/inetorgperson.schema pidfile /usr/local/ldap/var/run/slapd.pid argsfile /usr/local/ldap/var/run/slapd.args database meta suffix "dc=example,dc=com" rootdn "cn=manager,dc=example,dc=com" rootpw "secret" quarantine 1800,3 uri "ldap://ldap.example.com/dc=example,dc=com" ******************* Obviously my normal config looks nothing like this, but running this config gets the same result. the last few lines that slapd will output with full debug gives... ****************** line 9 (pidfile /usr/local/ldap/var/run/slapd.pid) line 9 (pidfile /usr/local/ldap/var/run/slapd.pid) line 9 (pidfile /usr/local/ldap/var/run/slapd.pid) line 10 (argsfile /usr/local/ldap/var/run/slapd.args) line 13 (database meta) line 14 (suffix "dc=example,dc=com") >>> dnPrettyNormal: <dc=example,dc=com> => ldap_bv2dn(dc=example,dc=com,0) <= ldap_bv2dn(dc=example,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=example,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=example,dc=com)=0 <<< dnPrettyNormal: <dc=example,dc=com>, <dc=example,dc=com> line 16 (rootdn "cn=manager,dc=example,dc=com") >>> dnPrettyNormal: <cn=manager,dc=example,dc=com> => ldap_bv2dn(cn=manager,dc=example,dc=com,0) <= ldap_bv2dn(cn=manager,dc=example,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=manager,dc=example,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=manager,dc=example,dc=com)=0 <<< dnPrettyNormal: <cn=manager,dc=example,dc=com>, <cn=manager,dc=example,dc=co m> line 17 (rootpw ***) line 19 (quarantine 1800,3) ******************* Before exiting with Segmentation Fault. Gdb shows... ****************** Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1211279696 (LWP 19080)] 0x081296d0 in ?? () ****************** Is this a bug or some mistake I'm making? Thanks is advance! Drew Graham *** Disclaimer *** The information contained in this E-Mail and any subsequent correspondence may be subject to the Export Control Act (ECA) 2002. The content is private and is intended solely for the recipient(s). For those other than the recipient any disclosure, copying, distribution, or action taken, or omitted to be taken, in reliance on such information is prohibited and may be unlawful. If received in error please return to sender immediately. Under the laws of England misuse of information that is subject to the ECA 2002, is a criminal offence. Westland Helicopters Ltd Lysander Road Yeovil BA20 2YB England Registered in England under No 604352

2 1

(ITS#5521) Can't change indexing of an attribute within a single modification
by rhafer＠suse.de 21 May '08

21 May '08

Full_Name: Ralf Haferkamp Version: HEAD, RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (85.8.89.54) The following modification to add an additional index an attribute fails with the error messages pasted below: -------------------------- dn: olcDatabase={1}bdb,cn=config changetype: modify delete: olcdbindex olcDbIndex: cn pres,eq - add: olcdbindex olcDbIndex: cn pres,eq,sub -------------------------- modifying entry "olcDatabase={1}bdb,cn=config" ldap_modify: Other (e.g., implementation specific) error (80) additional info: <olcDbIndex> handler exited with 1 As far as I can see it fails because the old indexmask hat not yet been deleted from the bdb-struct. The ainfo_insert()-call in back-bdb/attr.c(bdb_attr_index_config()) returns with -1. Splitting the above modification in two separate operations works around that problem.

1 0

Re: (ITS#5520) infinite recursion in syncrepl overlay
by quanah＠zimbra.com 21 May '08

21 May '08

--On Tuesday, May 20, 2008 11:37 PM +0000 jeff(a)jeffrodriguez.com wrote: > Full_Name: Jeff Rodriguez > Version: 2.3.30 > OS: Debian etch > URL: ftp://ftp.openldap.org/incoming/jeff-rodriguez-080520.tgz > Submission from: (NULL) (208.48.140.97) 2.3.30 is an extremely old release. Please re-test with 2.3.41. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5520) infinite recursion in syncrepl overlay
by jeff＠jeffrodriguez.com 21 May '08

21 May '08

Full_Name: Jeff Rodriguez Version: 2.3.30 OS: Debian etch URL: ftp://ftp.openldap.org/incoming/jeff-rodriguez-080520.tgz Submission from: (NULL) (208.48.140.97) syncprov seems to be causing a segfault when importing kerberos entries. slapd.conf, LDIFs, heimdal kerberos schema, and logs included. These are live files I was used to generate the segfault. It's also reproducible with the conf and ldif files customized to the environment. Commenting out syncprov and related lines in the conf eliminates the segfault. 1. stop slapd 2. wipe out current database 3. slapadd schema.ldif and chown the database to openldap user and group 4. start slapd with: /usr/sbin/slapd -g openldap -u openldap -d 1 -h "ldap:/// ldapi:///" 5. add ldif entries live: ldapadd -H ldapi:///var/run/ldapi -D cn=admin,o=example -w CHANGE_THIS_PASSWORD -f bugged.ldif 6. segfault uname -a: Linux ds1.phx2 2.6.18-6-xen-amd64 #1 SMP Sun Feb 10 18:02:52 UTC 2008 x86_64 GNU/Linux

1 0

Re: (ITS#5518) Assertion error in io.c:234: ber_flush2
by hyc＠symas.com 20 May '08

20 May '08

zulcss(a)ubuntu.com wrote: > Full_Name: Chuck Short > Version: 2.4.7 > OS: Ubuntu > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.142.121.161) > > > We are getting assertion errors in libraries/liblber/io.c. The original bug > report is located at the following: > > http://bugs.launchpad.net/bugs/215904 I've requested some more information on the above bug report. Looking back over ITS, it seems this has been a long-standing problem with nss-ldap. http://www.openldap.org/its/index.cgi/Incoming?id=3874;expression=liblber http://www.openldap.org/its/index.cgi/Incoming?id=4014;expression=liblber https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=124549 http://www.openldap.org/its/index.cgi/Incoming?id=4445;expression=liblber Unfortunately the information in the other reports is a bit confusing; e.g. the redhat bug indicates that a kernel update fixed the issue. That doesn't really make any sense. Hopefully we can get some consistent info to track it down this time. -- -- 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#5519) Compilation fails when linking with ldap threading symbols
by h.b.furuseth＠usit.uio.no 20 May '08

20 May '08

fredme writes: > Ldap compilation fails when I am trying to compile with-threads and > back_shell enabled. I think you mean --without-threads broke it... BTW, note that --enable-backends and --enable-overlays enable all backends/overlays, you don't need --enable-<individual backend/overlay> switches in addition. And to drop the shell backend as Howard suggests, you'd then override with --disable-shell. -- Hallvard

1 0

Re: (ITS#5519)
by hyc＠symas.com 20 May '08

20 May '08

fredme(a)gmail.com wrote: > All works fine if I change the flags to --with-threads and --disable-shell. This is now fixed in CVS HEAD. It's probably best that you build with --disable-shell anyway though. Migrate to back-sock instead... -- -- 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs