openldap-bugs April 2010

openldap-bugs@openldap.org

45 participants
233 discussions

Re: (ITS#6506) Use of back-perl in slapd.conf in subordinate database causes slapcat to segfault
by mark.cave-ayland＠siriusit.co.uk 06 Apr '10

06 Apr '10

masarati(a)aero.polimi.it wrote: > ^^^ I think the culprit is here. No point in tracking down further this > issue unless you re-link as recommended by this message. > > p. Sorry - I experienced the error on a production box running Debian packages, and re-built from source on my local machine just to confirm the bug still exists. However, my local machine already has other LDAP libraries installed which seems to have resulted in some of the wrong libraries being picked up at compile time. I've now removed all pre-built openldap packages, re-built again from source and can confirm that the bug still stands since the "ldap_int_global_options" warning has now disappeared: zeno:/home/build/rel-openldap# ./sbin/slapcat Here in new Posix Var 8192 and 4096 bdb_db_open: database "dc=my-domain,dc=com": unclean shutdown detected; attempting recovery. bdb_db_open: warning - no DB_CONFIG file found in directory /home/build/rel-openldap/var/openldap-data: (2). Expect poor performance for suffix "dc=my-domain,dc=com". bdb_db_open: database "dc=my-domain,dc=com": recovery skipped in read-only mode. Run manual recovery if errors are encountered. bdb_monitor_db_open: monitoring disabled; configure monitor database to enable dn: dc=my-domain,dc=com objectClass: top objectClass: dcObject objectClass: organization o:: bXlkb21haW4uY29tIA== dc: my-domain structuralObjectClass: organization entryUUID: 0bdc2650-d5c0-102e-9fe7-3350c645132d creatorsName: cn=Manager,dc=my-domain,dc=com createTimestamp: 20100406120241Z entryCSN: 20100406120241.310422Z#000000#000#000000 modifiersName: cn=Manager,dc=my-domain,dc=com modifyTimestamp: 20100406120241Z dn: ou=real,dc=my-domain,dc=com objectClass: organizationalUnit objectClass: top structuralObjectClass: organizationalUnit entryUUID: 5644fb04-d5c0-102e-9c04-81e0ba1bb1f2 creatorsName: cn=Manager,dc=my-domain,dc=com createTimestamp: 20100406120446Z ou: real entryCSN: 20100406120458.545769Z#000000#000#000000 modifiersName: cn=Manager,dc=my-domain,dc=com modifyTimestamp: 20100406120458Z *** glibc detected *** ./sbin/slapcat: free(): invalid pointer: 0x00000000009c4fd3 *** ======= Backtrace: ========= /lib/libc.so.6[0x7f4ea6fd0948] /lib/libc.so.6(cfree+0x76)[0x7f4ea6fd2a56] ./sbin/slapcat[0x42c11d] ./sbin/slapcat[0x42c1c9] ./sbin/slapcat[0x481448] ./sbin/slapcat[0x484c93] ./sbin/slapcat[0x4874b9] ./sbin/slapcat[0x408d40] /lib/libc.so.6(__libc_start_main+0xe6)[0x7f4ea6f7b1a6] ./sbin/slapcat[0x4087d9] Many thanks, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs

1 0

Re: (ITS#6506) Use of back-perl in slapd.conf in subordinate database causes slapcat to segfault
by masarati＠aero.polimi.it 06 Apr '10

06 Apr '10

> Full_Name: Mark Cave-Ayland > Version: 2.4.21 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.187.123.11) > > > Hi there, > > Having implemented a custom perl module as a subordinate with back-perl, > we've > found a segfault when using slapcat to dump the database. The backtrace > looks > like this: > > > zeno:/home/build/rel-openldap# ./sbin/slapcat > ./sbin/slapcat: Symbol `ldap_int_global_options' has different size in > shared > object, consider re-linking ^^^ I think the culprit is here. No point in tracking down further this issue unless you re-link as recommended by this message. p. > Here in new > Posix Var 8192 and 4096 > bdb_db_open: warning - no DB_CONFIG file found in directory > /home/build/rel-openldap/var/openldap-data: (2). > Expect poor performance for suffix "dc=my-domain,dc=com". > bdb_monitor_db_open: monitoring disabled; configure monitor database to > enable > dn: dc=my-domain,dc=com > objectClass: top > objectClass: dcObject > objectClass: organization > o:: bXlkb21haW4uY29tIA== > dc: my-domain > structuralObjectClass: organization > entryUUID: 0bdc2650-d5c0-102e-9fe7-3350c645132d > creatorsName: cn=Manager,dc=my-domain,dc=com > createTimestamp: 20100406120241Z > entryCSN: 20100406120241.310422Z#000000#000#000000 > modifiersName: cn=Manager,dc=my-domain,dc=com > modifyTimestamp: 20100406120241Z > > dn: ou=real,dc=my-domain,dc=com > objectClass: organizationalUnit > objectClass: top > structuralObjectClass: organizationalUnit > entryUUID: 5644fb04-d5c0-102e-9c04-81e0ba1bb1f2 > creatorsName: cn=Manager,dc=my-domain,dc=com > createTimestamp: 20100406120446Z > ou: real > entryCSN: 20100406120458.545769Z#000000#000#000000 > modifiersName: cn=Manager,dc=my-domain,dc=com > modifyTimestamp: 20100406120458Z > > *** glibc detected *** ./sbin/slapcat: free(): invalid pointer: > 0x00000000009c5063 *** > ======= Backtrace: ========= > /lib/libc.so.6[0x7f1adc150948] > /lib/libc.so.6(cfree+0x76)[0x7f1adc152a56] > ./sbin/slapcat[0x42c11d] > ./sbin/slapcat[0x42c1c9] > ./sbin/slapcat[0x481448] > ./sbin/slapcat[0x484c93] > ./sbin/slapcat[0x4874b9] > ./sbin/slapcat[0x408d40] > /lib/libc.so.6(__libc_start_main+0xe6)[0x7f1adc0fb1a6] > ./sbin/slapcat[0x4087d9] > > > Looks like an invalid pointer is being deferenced when running slapcat. > > > ATB, > > Mark. > > >

1 0

Re: (ITS#6506) Use of back-perl in slapd.conf in subordinate database causes slapcat to segfault
by mark.cave-ayland＠siriusit.co.uk 06 Apr '10

06 Apr '10

Here is the slapd.conf used in the test: # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /home/build/rel-openldap/etc/openldap/schema/core.schema # Define global ACLs to disable default read access. # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org pidfile /home/build/rel-openldap/var/run/slapd.pid argsfile /home/build/rel-openldap/var/run/slapd.args # Load dynamic backend modules: # modulepath /home/build/rel-openldap/libexec/openldap # moduleload back_bdb.la # moduleload back_hdb.la # moduleload back_ldap.la # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to dn.base="cn=Subschema" by * read # access to * # by self write # by users read # by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! database perl suffix "ou=perl,dc=my-domain,dc=com" subordinate perlModulePath /home/build/rel-openldap/etc/openldap perlModule SampleLDAP ####################################################################### # BDB database definitions ####################################################################### database bdb suffix "dc=my-domain,dc=com" rootdn "cn=Manager,dc=my-domain,dc=com" # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw secret # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /home/build/rel-openldap/var/openldap-data # Indices to maintain index objectClass eq And here is the slapcat output when the perl database is disabled in slapd.conf to prevent the crash: dn: dc=my-domain,dc=com objectClass: top objectClass: dcObject objectClass: organization o:: bXlkb21haW4uY29tIA== dc: my-domain structuralObjectClass: organization entryUUID: 0bdc2650-d5c0-102e-9fe7-3350c645132d creatorsName: cn=Manager,dc=my-domain,dc=com createTimestamp: 20100406120241Z entryCSN: 20100406120241.310422Z#000000#000#000000 modifiersName: cn=Manager,dc=my-domain,dc=com modifyTimestamp: 20100406120241Z dn: ou=real,dc=my-domain,dc=com objectClass: organizationalUnit objectClass: top structuralObjectClass: organizationalUnit entryUUID: 5644fb04-d5c0-102e-9c04-81e0ba1bb1f2 creatorsName: cn=Manager,dc=my-domain,dc=com createTimestamp: 20100406120446Z ou: real entryCSN: 20100406120458.545769Z#000000#000#000000 modifiersName: cn=Manager,dc=my-domain,dc=com modifyTimestamp: 20100406120458Z dn: ou=perl,dc=my-domain,dc=com objectClass: organizationalUnit objectClass: top ou: perl structuralObjectClass: organizationalUnit entryUUID: 6438973e-d5c0-102e-9c05-81e0ba1bb1f2 creatorsName: cn=Manager,dc=my-domain,dc=com createTimestamp: 20100406120509Z entryCSN: 20100406120509.555750Z#000000#000#000000 modifiersName: cn=Manager,dc=my-domain,dc=com modifyTimestamp: 20100406120509Z ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs

1 0

(ITS#6506) Use of back-perl in slapd.conf in subordinate database causes slapcat to segfault
by mark.cave-ayland＠siriusit.co.uk 06 Apr '10

06 Apr '10

Full_Name: Mark Cave-Ayland Version: 2.4.21 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.187.123.11) Hi there, Having implemented a custom perl module as a subordinate with back-perl, we've found a segfault when using slapcat to dump the database. The backtrace looks like this: zeno:/home/build/rel-openldap# ./sbin/slapcat ./sbin/slapcat: Symbol `ldap_int_global_options' has different size in shared object, consider re-linking Here in new Posix Var 8192 and 4096 bdb_db_open: warning - no DB_CONFIG file found in directory /home/build/rel-openldap/var/openldap-data: (2). Expect poor performance for suffix "dc=my-domain,dc=com". bdb_monitor_db_open: monitoring disabled; configure monitor database to enable dn: dc=my-domain,dc=com objectClass: top objectClass: dcObject objectClass: organization o:: bXlkb21haW4uY29tIA== dc: my-domain structuralObjectClass: organization entryUUID: 0bdc2650-d5c0-102e-9fe7-3350c645132d creatorsName: cn=Manager,dc=my-domain,dc=com createTimestamp: 20100406120241Z entryCSN: 20100406120241.310422Z#000000#000#000000 modifiersName: cn=Manager,dc=my-domain,dc=com modifyTimestamp: 20100406120241Z dn: ou=real,dc=my-domain,dc=com objectClass: organizationalUnit objectClass: top structuralObjectClass: organizationalUnit entryUUID: 5644fb04-d5c0-102e-9c04-81e0ba1bb1f2 creatorsName: cn=Manager,dc=my-domain,dc=com createTimestamp: 20100406120446Z ou: real entryCSN: 20100406120458.545769Z#000000#000#000000 modifiersName: cn=Manager,dc=my-domain,dc=com modifyTimestamp: 20100406120458Z *** glibc detected *** ./sbin/slapcat: free(): invalid pointer: 0x00000000009c5063 *** ======= Backtrace: ========= /lib/libc.so.6[0x7f1adc150948] /lib/libc.so.6(cfree+0x76)[0x7f1adc152a56] ./sbin/slapcat[0x42c11d] ./sbin/slapcat[0x42c1c9] ./sbin/slapcat[0x481448] ./sbin/slapcat[0x484c93] ./sbin/slapcat[0x4874b9] ./sbin/slapcat[0x408d40] /lib/libc.so.6(__libc_start_main+0xe6)[0x7f1adc0fb1a6] ./sbin/slapcat[0x4087d9] Looks like an invalid pointer is being deferenced when running slapcat. ATB, Mark.

1 0

Re: (ITS#6504) Corrupted control value when using pagedresults with subordinate *ldap* database
by masarati＠aero.polimi.it 05 Apr '10

05 Apr '10

>> Well, I've just fixed it. When changing database, I modified the paged >> results control value by setting the page size to pagesize - >> rs->sr_nentries, with an empty cookie. I'll commit tomorrow, as now I >> only have http access. > > Speedy patch - thank you! Just tried it out, and it works great for the > issue I reported. > > Testing further shows a limitation in crossing databases though. A > search that spans over two glued ldap databases, returns n < pagesize > results from the first, and continues over to the second, returning > pagesize-n results from it, making pagesize results all together. So > far, so good. > > However, the subsequent search with the returned pagedresults cookie > just starts a new search over, returning the same set of results. So it > works fine for one page max. > > But it doesn't look simple to solve this issue, unless backglue starts > recording pagedresults cookies, etc... > > Anyway, great improvement on not sending back free'd cookie :-) I see the issue, and it seems to be not related to my patch. Don't know how to fix it (yet). It'll probably need a separate ITS. p.

1 0

Re: (ITS#6504) Corrupted control value when using pagedresults with subordinate *ldap* database
by jonathan＠phillipoux.net 05 Apr '10

05 Apr '10

Le 02/04/2010 06:44, masarati(a)aero.polimi.it a écrit : >> masarati(a)aero.polimi.it wrote: >>>> masarati(a)aero.polimi.it wrote: >>>>>> Also, I note that the glued paged response seems to work incorrectly. >>>>>> I >>>>>> made a simple test system, where the root database contains exactly >>>>>> one >>>>>> entry (the suffix) and a back-ldap is glued on top. If I request >>>>>> entries >>>>>> with a page size of 2, searching the suffix return 3 entries; >>>>>> subsequent >>>>>> searches return 2 entries from the proxy. I haven't figured out yet >>>>>> where >>>>>> the issue is. >>>>> >>>>> I figured out how to fix the issue you reported. It is related to the >>>>> fact that slapd internally assumes that ldctl_oid values are constant >>>>> strings, so it doesn't duplicate nor free them. However, control OIDs >>>>> returned by back-ldap (and friends) have been decoded from the wire by >>>>> the >>>>> client library, so they are actually malloc'ed. That's why backglue >>>>> ends >>>>> up with a dangling pointer. >>>>> >>>>> I'm fixing it by having backglue duplicate (and free) control OIDs >>>>> consistently. Another option would be to replace those values with >>>>> constant strings for known control values. This would prevent gluing >>>>> for >>>>> unknown proxied controls. >>>> >>>> Or just tmpalloc them and don't bother to clean them up. >>> >>> Yes, I've reworked all the temporary controls allocation using tmpalloc. >>> Too bad OIDs are char* and not bervals. >>> >>> With respect to the other issue, to honor the requested pagesize we'd >>> need >>> to intercept pagedresult requests, modify the page size in the request >>> when a page crosses two databases, requesting the original page size >>> minus >>> entries already returned. I wonder whether it's worth the effort, >>> though. >> >> IMO pagedresults should be a (global) overlay, and backends shouldn't do >> anything about it. Note that the sssvlv overlay already intercepts >> pagedresults, it's impossible to handle things correctly otherwise. > > Well, I've just fixed it. When changing database, I modified the paged > results control value by setting the page size to pagesize - > rs->sr_nentries, with an empty cookie. I'll commit tomorrow, as now I > only have http access. Speedy patch - thank you! Just tried it out, and it works great for the issue I reported. Testing further shows a limitation in crossing databases though. A search that spans over two glued ldap databases, returns n < pagesize results from the first, and continues over to the second, returning pagesize-n results from it, making pagesize results all together. So far, so good. However, the subsequent search with the returned pagedresults cookie just starts a new search over, returning the same set of results. So it works fine for one page max. But it doesn't look simple to solve this issue, unless backglue starts recording pagedresults cookies, etc... Anyway, great improvement on not sending back free'd cookie :-) -- -------------------------------------------------------------- Jonathan Clarke - jonathan(a)phillipoux.net -------------------------------------------------------------- Ldap Synchronization Connector (LSC) - http://lsc-project.org --------------------------------------------------------------

1 0

RE: (ITS#6505) ldap_search_* functions missing const qualifiers
by EHASZLA＠transunion.com 05 Apr '10

05 Apr '10

>From: masarati(a)aero.polimi.it [mailto:masarati@aero.polimi.it] > >> hmm... I'm not quite sure how to attach a file to a ticket through the >> web interface, > >In general, upload to ftp.openldap.org according to contribution >instructions, and post a message with the URL; the way you provided it >makes it pretty unusable. Fwiw, I uploaded the two patches as ehaszla-ldap.h-20100405.patch and ehaszla-search.c-20100405.patch eric

1 0

RE: (ITS#6505) ldap_search_* functions missing const qualifiers
by masarati＠aero.polimi.it 05 Apr '10

05 Apr '10

> Anyway, if the change doesn't get accepted it won't be the end of the > world, but obviously I'm hoping you find the above convincing. Just to clarify: if I were to design the API from scratch, I'd CONST those args... so I agree with your suggestion. p.

1 0

RE: (ITS#6505) ldap_search_* functions missing const qualifiers
by EHASZLA＠transunion.com 04 Apr '10

04 Apr '10

This is a multi-part message in MIME format. ------_=_NextPart_001_01CAD483.E1DB174F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable -----Original Message----- >From: masarati(a)aero.polimi.it [mailto:masarati@aero.polimi.it] >In general, upload to ftp.openldap.org according to contribution >instructions, and post a message with the URL; the way you provided it >makes it pretty unusable. I saw the instructions about using the ftp site some time after I sent = the patches. Sorry. The patch was just the obvious, mechanical change to add const to the attrs parameter in the functions that have it. Maybe a reminder to keep reading the rest of the page in the section on "patches" would be helpful. I got to the part that started talking = about attribution of large changes, and assumed the rest of the page wasn't relevant to what I was trying to do. >However, I think your patch will not be considered, although in = principle >perfectly acceptable, because an API change of this type would probably >break a lot of code out there, without significant advantages. Well, a couple of observations: 1) At least one other ldap implementation already does this. 2) I consider being able to turn on the compiler warnings that tell you = about parameters that might be changed when do don't expect them to be = a significant advantage. For many of the source trees I've worked on, = doing so (and treating warnings as errors, to force them to be fixed)=20 has helped uncover a variety of bugs. 3) If you're not being pedantic about warnings, and causing them to be=20 treated as errors, this API change just results in an extra warning,=20 which wouldn't actually break any code. 4) Adding "const" effectively and simply documents the fact that those=20 parameters aren't going to be changed. If the API doesn't say so, it would be nice if that was at least explicitly mentions in the man = page. At the moment, I had to go read an analyze the ldap code to figure that out. I'd rather spend my time working on my own code instead, = and be able to simply use the great library you guys have created. :) Anyway, if the change doesn't get accepted it won't be the end of the world, but obviously I'm hoping you find the above convincing. eric ------_=_NextPart_001_01CAD483.E1DB174F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Diso-8859-1"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = 6.5.7654.12"> <TITLE>RE: (ITS#6505) ldap_search_* functions missing const = qualifiers</TITLE> </HEAD> <BODY>  -----Original Message----- >From: masarati(a)aero.polimi.it [<A = HREF=3D"mailto:masarati@aero.polimi.it">mailto:masarati@aero.polimi.it</A= >] >In general, upload to ftp.openldap.org according to contribution >instructions, and post a message with the URL; the way you provided = it >makes it pretty unusable.   I saw the instructions about using the ftp site some time after I = sent the patches.  Sorry.  The patch was just the obvious, = mechanical change to add const to the attrs parameter in the functions that have it. Maybe a reminder to keep reading the rest of the page in the section = on "patches" would be helpful.  I got to the part that = started talking about attribution of large changes, and assumed the rest of the page = wasn't relevant to what I was trying to do. >However, I think your patch will not be considered, although in = principle >perfectly acceptable, because an API change of this type would = probably >break a lot of code out there, without significant advantages. Well, a couple of observations:  1) At least one other ldap implementation already does this.  2) I consider being able to turn on the compiler warnings that = tell you   about parameters that might be changed when do don't expect them = to be   a significant advantage.  For many of the source trees I've = worked on,   doing so (and treating warnings as errors, to force them to be = fixed)   has helped uncover a variety of bugs.  3) If you're not being pedantic about warnings, and causing them = to be   treated as errors, this API change just results in an extra = warning,   which wouldn't actually break any code.  4) Adding "const" effectively and simply documents the = fact that those   parameters aren't going to be changed.  If the API doesn't = say so, it   would be nice if that was at least explicitly mentions in the man = page.   At the moment, I had to go read an analyze the ldap code to = figure   that out.  I'd rather spend my time working on my own code = instead, and   be able to simply use the great library you guys have created. = :) Anyway, if the change doesn't get accepted it won't be the end of = the  world, but obviously I'm hoping you find the above convincing. eric </BODY> </HTML> ------_=_NextPart_001_01CAD483.E1DB174F--

1 0

Re: (ITS#6505) ldap_search_* functions missing const qualifiers
by masarati＠aero.polimi.it 02 Apr '10

02 Apr '10

> hmm... I'm not quite sure how to attach a file to a ticket through the > web interface, In general, upload to ftp.openldap.org according to contribution instructions, and post a message with the URL; the way you provided it makes it pretty unusable. However, I think your patch will not be considered, although in principle perfectly acceptable, because an API change of this type would probably break a lot of code out there, without significant advantages. p.

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 April 2010