openldap-bugs October 2010

openldap-bugs@openldap.org

38 participants
86 discussions

(ITS#6691) error 4 in slapd: segfault with back-sql in debian amd64
by andresmarenco＠gmail.com 29 Oct '10

29 Oct '10

Full_Name: Andrés Marenco Zúñiga Version: 2.4.23 (20100719) OS: Debian 5.06 amd64 URL: Submission from: (NULL) (201.198.99.66) I'm getting a segfault while doing any search in openldap. This is my configuration: Debian 5.06 amd64 (kernel 2.6.26-2-amd64) OpenLDAP 2.4.23 (20100719) UnixODBC 2.3.0 PostgreSQL 8.2.10 psqlodbc 09.00.0101 ############################################################################# slapd.conf (the relevant parts) ############################################################################# include /var/lib/openldap/etc/openldap/schema/core.schema include /var/lib/openldap/etc/openldap/schema/cosine.schema include /var/lib/openldap/etc/openldap/schema/inetorgperson.schema pidfile /var/lib/openldap/var/slapd.pid argsfile /var/lib/openldap/slapd.args database sql suffix "dc=example,dc=com" rootdn "cn=root,dc=example,dc=com" rootpw secret dbname PgSQL dbuser "" dbpasswd "" insentry_stmt "insert into ldap_entries (id,dn,oc_map_id,parent,keyval) values ((select max(id)+1 from ldap_entries),?,?,?,?)" upper_func "upper" strcast_func "text" concat_pattern "?||?" has_ldapinfo_dn_ru no lastmod off ############################################################################# odbcinst.ini ############################################################################# [PostgreSQL] Description=ODBC for PostgreSQL Driver=/usr/local/lib/psqlodbcw.so ############################################################################# odbc.ini ############################################################################# [PgSQL] Driver=/usr/local/lib/psqlodbcw.so Description=Connection to LDAP/POSTGRESQL Server=xxx.xxx.xxx.xxx Port=5432 Protocol=6.4 FetchBufferSize=99 Database=db Username=user ReadOnly=no CommLog=1 slapd starts fine, but when I make any search this is what I'm getting: <= send_search_entry: conn 1000 exit. send_ldap_result: conn=1000 op=2 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=3 tag=101 err=0 ber_flush2: 14 bytes to sd 11 0000: 30 0c 02 01 03 65 07 0a 01 00 04 00 04 00 0....e........ ldap_write: want=14, written=14 0000: 30 0c 02 01 03 65 07 0a 01 00 04 00 04 00 0....e........ conn=1000 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text= Segmentation Fault (Core Dumped) in the syslog this is what I have: Oct 29 17:53:17 td-server slapd[32026]: conn=1000 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text= Oct 29 17:53:17 td-server kernel: [10058.462325] slapd[32029]: segfault at ffffffde0274e4a0 ip 46c23b sp 425d7570 error 4 in slapd[400000+161000] and the gdb backtrace shows this: Core was generated by `/var/lib/openldap/libexec/slapd -d -1'. Program terminated with signal 11, Segmentation fault. [New process 31991] [New process 31987] [New process 31990] #0 0x000000000046c23b in ?? () #1 0x0000000000499903 in ?? () #2 0x000000000049e01b in ?? () #3 0x000000000041ed51 in ?? () #4 0x000000000041f54c in ?? () #5 0x000000000041cb5f in ?? () #6 0x000000000041d7dc in ?? () #7 0x00000000004c8760 in ?? () #8 0x00007fe1a4861fc7 in start_thread () from /lib/libpthread.so.0 #9 0x00007fe1a45d764d in clone () from /lib/libc.so.6 #10 0x0000000000000000 in ?? () Everything works fine in 32bits (Debian 5.0 i386), but it fails with 64bits. Any idea?

1 0

(ITS#6690) ldap_result & LDAP_TIMEOUT
by greg.silverman＠webex.com 29 Oct '10

29 Oct '10

Full_Name: Greg Silverman Version: 2.4.23 OS: CentOS 5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.69.115.12) At result.c, line 438, ldap_result will return 0==LDAP_SUCCESS even though there was a timeout error, ld_errno==LDAP_TIMEOUT

1 0

Re: (ITS#6688) OpenLDAP 2.4.23 doesn't enforce ACLs on back-perl subordinate database
by mark.cave-ayland＠siriusit.co.uk 29 Oct '10

29 Oct '10

Hi all, An update on this bug report: with a modified slapd.conf and a small patch to the back-perl module, I can use the ACL mask to ensure that the perl search function doesn't get invoked if disallowed by the ACLs. The patch works by creating a "fake" empty entry whose DN is the base of the search, and then passing this entry into access_allowed() using code borrowed from one of the other backends to either deny or allow access. http://pastebin.siriusit.co.uk/perlacl/slapd2.conf http://pastebin.siriusit.co.uk/perlacl/openldap-backperl-acls.patch Is this something that could be considered for inclusion upstream or does it require more work? 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

Re: (ITS#6686) VLV overlay fails to handle multiple search operations per LDAP connection
by hyc＠symas.com 29 Oct '10

29 Oct '10

Sebastien Bahloul wrote: > Hi Howard, > > Le mercredi 27 octobre 2010 15:03:36, Howard Chu a écrit : >> sebastien.bahloul(a)gmail.com wrote: >>> Full_Name: Sebastien Bahloul >>> Version: HEAD >>> OS: Linux RHEL 5 >>> URL: >>> Submission from: (NULL) (109.197.176.10) >>> >>> >>> Hi, >>> >>> I think there is a bug / limitation inside VLV implementation : it can >>> not handle multiple search operation on a single connection. The first >>> operation succeeds and next operations fail with the following message : >>> >>> LDAP: error code 51 - Other sort requests already in progress >>> >>> But I think this issue is more global. This implementation seems to be >>> able to only handle a single VLV context per connection. >> >> Correct, that is by design. >> >>> If I am right, this is related with the indexing method of sort_conns >>> structure which seems to be based only on the connection id. I suggest >>> to implement a double indexing array by connection id / VLV context id. >> >> I have no interest in extending this. It would require much more overhead >> to protect the slapd from getting overloaded by too many such requests. > > In fact my suggestion was a question : I would like to contribute a patch to > add support for this way of using VLV. Is this feature extension as a double > indexed array an acceptable implementation from your point of vue ? To avoid > encountering such performance issues, I would add a new sssvlv parameter that > would authorize by default only a single VLV search request per connection. I guess as long as you observe the svi_max config parameter, there's no reason not to adopt your suggestion. Feel free to followup here with your patch for review. -- -- 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#6689) Patch - Mozilla NSS - support cert database prefix
by hyc＠symas.com 29 Oct '10

29 Oct '10

rmeggins(a)redhat.com wrote: > Full_Name: Rich Megginson > Version: 2.4.23 (current CVS HEAD) > OS: RHEL5 > URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-moznssdbprefix-20101028.pat… > Submission from: (NULL) (76.113.111.209) Thanks for the patch, committed to HEAD. > > Mozilla NSS supports having multiple cert/key databases in the same directory, > each one having a unique string prefix e.g. > slapd-01-cert8.db - the prefix here is "slapd-01-" > This patch allows the user to pass in the prefix as the last part of the > cacertdir. If the given cacertdir does not exist (neither a file nor a > directory), and contains the platform's path separator character (e.g. '/'), > look at the last occurance of the path separator in the string - if it exists > and there is something after that, assume that is the prefix. > > This patch also cleans up some compiler warnings about unused variables and > signedness differences, and removes a very annoying debug message. > > This patch file is derived from OpenLDAP Software. All of the > modifications to OpenLDAP Software represented in the following > patch(es) were developed by Red Hat. Red Hat has not assigned rights > and/or interest in this work to any party. I, Rich Megginson am > authorized by Red Hat, my employer, to release this work under the > following terms. > > Red Hat hereby place the following modifications to OpenLDAP Software > (and only these modifications) into the public domain. Hence, these > modifications may be freely used and/or redistributed for any purpose > with or without attribution and/or other notice. > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6689) Patch - Mozilla NSS - support cert database prefix
by rmeggins＠redhat.com 28 Oct '10

28 Oct '10

Full_Name: Rich Megginson Version: 2.4.23 (current CVS HEAD) OS: RHEL5 URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-moznssdbprefix-20101028.pat… Submission from: (NULL) (76.113.111.209) Mozilla NSS supports having multiple cert/key databases in the same directory, each one having a unique string prefix e.g. slapd-01-cert8.db - the prefix here is "slapd-01-" This patch allows the user to pass in the prefix as the last part of the cacertdir. If the given cacertdir does not exist (neither a file nor a directory), and contains the platform's path separator character (e.g. '/'), look at the last occurance of the path separator in the string - if it exists and there is something after that, assume that is the prefix. This patch also cleans up some compiler warnings about unused variables and signedness differences, and removes a very annoying debug message. This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Rich Megginson am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#6660) paged result searches fail to deallocate memory until slapd shutdown
by quanah＠zimbra.com 28 Oct '10

28 Oct '10

--On Wednesday, October 27, 2010 4:54 PM +0000 quanah(a)zimbra.com wrote: > > If anyone else has some thoughts on why the entry cache is growing > unbounded, much appreciated. Just a further note -- To reproduce this, you have to have more than 2 cores. My system has 6, I don't know what the lower limit is (3,4, or 5) for reproduction. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6687) slaptest: bad configuration file!
by quanah＠zimbra.com 28 Oct '10

28 Oct '10

--On Wednesday, October 27, 2010 3:22 PM +0000 rakesh.rai(a)alico.com wrote: If you need help using and configuring OpenLDAP, then email openldap-technical(a)openldap.org. The ITS system is not the appropriate place for these types of questions. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6688) OpenLDAP 2.4.23 doesn't enforce ACLs on back-perl subordinate database
by mark.cave-ayland＠siriusit.co.uk 28 Oct '10

28 Oct '10

Full_Name: Mark Cave-Ayland Version: 2.4.23 OS: Linux/Debian URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.187.123.11) Hi all, We have an issue on one of our production systems whereby openldap is not enforcing the ACLs on a back-perl subordinate database. In this particular system, the membership of certain groups stored within LDAP is determined by some customised logic in a Perl module which dynamically generates LDAP objects with posixGroup/groupOfNames entries conditionally based upon the values of existing LDAP attributes within the tree. However, since these internal LDAP attribute lookups can be quite slow, we wish to hide them from all but a small minority of bind DNs. Unfortunately what we are finding is that the back-perl module is not respecting the ACLs in slapd.conf. The following files can be used to reproduce this issue with openldap 2.4.23: http://pastebin.siriusit.co.uk/perlacl/slapd.conf http://pastebin.siriusit.co.uk/perlacl/perlacl.ldif http://pastebin.siriusit.co.uk/perlacl/PerlACL.pm The password for both the "cn=admin,dc=my-domain,dc=com" and the "cn=restricted,dc=my-domain,dc=com" DNs is secret. The ACLs in the above slapd.conf look like this: access to dn.subtree="ou=perl,dc=my-domain,dc=com" by dn="cn=admin,dc=my-domain,dc=com" read by dn="cn=restricted,dc=my-domain,dc=com" none access to dn.subtree="ou=hidden,dc=my-domain,dc=com" by dn="cn=admin,dc=my-domain,dc=com" read by dn="cn=restricted,dc=my-domain,dc=com" none access to * by dn="cn=admin,dc=my-domain,dc=com" write by dn="cn=restricted,dc=my-domain,dc=com" read by * auth Using these ACLs, I would expect that cn=admin should be able to read the whole directory, whereas cn=restricted should not be able to see either the "ou=hidden,dc=my-domain,dc=com" DN subtree nor the "ou=perl,dc=my-domain,dc=com" DN subtree. However, performing an LDAP search binding as cn=restricted gives the following output: build@zeno:~$ ldapsearch -LLL -H ldap://localhost:10389 -D 'cn=restricted,dc=my-domain,dc=com' -b 'dc=my-domain,dc=com' -xW Enter LDAP Password: dn: dc=my-domain,dc=com objectClass: top objectClass: dcObject objectClass: organization o:: bXlkb21haW4uY29tIA== dc: my-domain dn: ou=real,dc=my-domain,dc=com objectClass: organizationalUnit objectClass: top ou: real dn: ou=realtest1,ou=real,dc=my-domain,dc=com objectClass: organizationalUnit objectClass: top ou: realtest1 dn: ou=realtest2,ou=real,dc=my-domain,dc=com objectClass: organizationalUnit objectClass: top ou: realtest2 dn: ou=realtest3,ou=real,dc=my-domain,dc=com objectClass: organizationalUnit objectClass: top ou: realtest3 dn: ou=realtest4,ou=real,dc=my-domain,dc=com objectClass: organizationalUnit objectClass: top ou: realtest4 dn: ou=realtest5,ou=real,dc=my-domain,dc=com objectClass: organizationalUnit objectClass: top ou: realtest5 dn: cn=restricted,dc=my-domain,dc=com objectClass: simpleSecurityObject objectClass: organizationalRole cn: restricted description: restricted user userPassword:: e1NIQX01ZW42RzZNZXpScm9UM1hLcWtkUE9tWS9CZlE9 dn: cn=admin,dc=my-domain,dc=com objectClass: simpleSecurityObject objectClass: organizationalRole cn:: YWRtaW4g description: admin user userPassword:: e1NIQX01ZW42RzZNZXpScm9UM1hLcWtkUE9tWS9CZlE9 dn: ou=perltest5,ou=perl,dc=my-domain,dc=com objectClass: organizationalUnit objectClass: top ou: perltest5 dn: ou=perltest4,ou=perl,dc=my-domain,dc=com objectClass: organizationalUnit objectClass: top ou: perltest4 dn: ou=perltest3,ou=perl,dc=my-domain,dc=com objectClass: organizationalUnit objectClass: top ou: perltest3 dn: ou=perltest2,ou=perl,dc=my-domain,dc=com objectClass: organizationalUnit objectClass: top ou: perltest2 dn: ou=perltest1,ou=perl,dc=my-domain,dc=com objectClass: organizationalUnit objectClass: top ou: perltest1 In other words, the "ou=hidden,dc=my-domain,dc=com" subtree is correctly hidden from the cn=restricted user, whereas the "ou=perl,dc=my-domain,dc=com" subtree is not.

1 0

Re: (ITS#6660) paged result searches fail to deallocate memory until slapd shutdown
by quanah＠zimbra.com 27 Oct '10

27 Oct '10

--On Thursday, September 30, 2010 4:59 PM +0000 quanah(a)zimbra.com wrote: > --On Thursday, September 30, 2010 11:14 AM +0000 masarati(a)aero.polimi.it > wrote: > >> There's no mention of overlays; I was wondering whether or not it could >> be related to some adverse interaction, e.g. with sssvlv, which has some >> paged-results specific code. Can you also post on overlays either global >> or specific to "olcDatabase={2}hdb"? > > There are no overlays being used. ;) As I said, a very vanilla config. Howard and I continue to examine this problem, but as yet, have found no solution nor insight into why the problem exists. It has nothing to do with paged results, and you can see the behavior relatively easily with a smaller DB than I was working with. Right now, I'm using a 1 million entry DB. If I execute two concurrent searches of the database with a 25,000 entry cache limit, that frees 1,000 entries on purge, at the end of those searches, we end up with: counted 1000087 entryInfos and 114476 entries, 0 notcached What this shows is that after the search completed, there are 114,476 entries in the entry cache, even though it only reports between 24,000 and 25,000. Repeated additional searches will continue to increase the number of cached entries until all memory is exhausted. The following code is used to count up the cached entries, and it is called from inside gdb via: call bdb_lru_count(&bdb->bi_cache) --- openldap-2.4.23/servers/slapd/back-bdb/cache.c.orig 2010-10-05 16:20:27.085259568 -0700 +++ openldap-2.4.23/servers/slapd/back-bdb/cache.c 2010-10-05 16:21:03.655255057 -0700 @@ -1530,6 +1530,35 @@ } #ifdef LDAP_DEBUG +static void +bdb_lru_count( Cache *cache ) +{ + EntryInfo *e; + int ei = 0, ent = 0, nc = 0; + + for ( e = cache->c_lrutail; ; ) { + ei++; + if ( e->bei_e ) { + ent++; + if ( e->bei_state & CACHE_ENTRY_NOT_CACHED ) + nc++; + } + e = e->bei_lrunext; + if ( e == cache->c_lrutail ) + break; + } + fprintf( stderr, "counted %d entryInfos and %d entries, %d notcached\n", + ei, ent, nc ); + ei = 0; + for ( e = cache->c_lrutail; ; ) { + ei++; + e = e->bei_lruprev; + if ( e == cache->c_lrutail ) + break; + } + fprintf( stderr, "counted %d entryInfos (on lruprev)\n", ei ); +} + #ifdef SLAPD_UNUSED static void bdb_lru_print( Cache *cache ) If anyone else has some thoughts on why the entry cache is growing unbounded, much appreciated. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs October 2010