openldap-bugs

openldap-bugs@openldap.org

1 participants
20964 discussions

Re: (ITS#6043) slapd segfaults in bdb_rdn_cmp
by luca.scamoni＠sys-net.it 10 Apr '09

10 Apr '09

luca.scamoni(a)sys-net.it ha scritto: > luca.scamoni(a)sys-net.it ha scritto: New update The problem is still there. Same call in bdb_rdn_cmp. strncmp fails because one of the berval passed to the function has inconsistent values between bv_len and bv_val Ing. Luca Scamoni Responsabile Ricerca e Sviluppo SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 0382 573859 (137) Fax: +39 0382 476497 Email: luca.scamoni(a)sys-net.it -----------------------------------

1 0

(ITS#6052) Small typo in SASL chapter (15) in administration guide
by kkalev＠gmail.com 10 Apr '09

10 Apr '09

Full_Name: Kostas Kalevras Version: 2.4 OS: FreeBSD URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (147.102.247.75) In OpenLDAP 2.4 Administration Guide, chapter 15 (Using SASL) in 15.3.3.1. Notes on Proxy Authorization Rules the documentation states that the administrator can use regular expression matching like: authzTo: dn.regex=^uid=[^,]*,dc=example,dc=com$ I believe the correct form should be: authzTo: dn.regex:"^uid=[^,]*,dc=example,dc=com$" Notice the : instead of = and the quotes around the regular expression.

1 0

(ITS#6051) JLDAP SASL issue
by hendrik.saly＠gmx.de 10 Apr '09

10 Apr '09

Full_Name: Hendrik Saly Version: JLDAP 4.3 OS: Linux 2.6, Sun JDK 1.5 URL: http://svn.muleforge.org/mule-transport-ldap/trunk/src/main/java/com/novell… Submission from: (NULL) (78.43.136.21) While trying to use SASL with JLDAP i encounter a potential minor bug in $OpenLDAP: pkg/jldap/com/novell/ldap/LDAPConnection.java,v 1.154 2006/02/09 08:43:45 sunilk Exp $ Seems the bind method on line 1730 fails to release the bind semaphore properly under some circumstances. I tried to use more than the wit JLDAP provided SASL mechanisms DIGESTMD5 and EXTERNAL by wrapping the novell sasl client with a Java 1.5 sasl client. All works very well but CRAM login for example fails. I have a workaround http://svn.muleforge.org/mule-transport-ldap/trunk/src/main/java/com/novell… but i thinks there are some problems with the bind semaphore. The wrapping code is here http://svn.muleforge.org/mule-transport-ldap/trunk/src/main/java/org/mule/t… If neccessary i can provide a test suite for this. Thanks Hendrik

1 0

Re: (ITS#6021) slapo-pcache/back-ldap slapd crashes
by hyc＠symas.com 09 Apr '09

09 Apr '09

toby(a)inf.ed.ac.uk wrote: > OK, this is my first crash since moving to 2.4.16: > > Slightly different from the previous ones, but is coming through > pcache.c:remove_from_template and, according to slapd log, was > removing queries from cache when crash occurred: > > Apr 9 05:05:18 rockingham slapd[6662]: Lock CR index = 0x94e70f0 > Apr 9 05:05:18 rockingham slapd[6662]: TEMPLATE 0x94e70f0 QUERIES-- 5 > Apr 9 05:05:18 rockingham slapd[6662]: Unlock CR index = 0x94e70f0 > Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, SIZE=0 > Apr 9 05:05:18 rockingham slapd[6662]: STORED QUERIES = 26 > Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, CACHE =17 > entries > Apr 9 05:05:18 rockingham slapd[6662]: Lock CR index = 0x94e70f0 > Apr 9 05:05:18 rockingham slapd[6662]: TEMPLATE 0x94e70f0 QUERIES-- 4 > Apr 9 05:05:18 rockingham slapd[6662]: Unlock CR index = 0x94e70f0 > Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, SIZE=0 > Apr 9 05:05:18 rockingham slapd[6662]: STORED QUERIES = 25 > Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, CACHE =17 > entries > Apr 9 05:05:18 rockingham slapd[6662]: Lock CR index = 0x94e70f0 > Apr 9 05:05:18 rockingham slapd[6662]: TEMPLATE 0x94e70f0 QUERIES-- 3 > Apr 9 05:05:18 rockingham slapd[6662]: Unlock CR index = 0x94e70f0 > Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, SIZE=0 > Apr 9 05:05:18 rockingham slapd[6662]: STORED QUERIES = 24 > Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, CACHE =17 > entries > Apr 9 05:05:18 rockingham slapd[6662]: Lock CR index = 0x94e70f0 > Apr 9 05:05:18 rockingham slapd[6662]: TEMPLATE 0x94e70f0 QUERIES-- 2 > Apr 9 05:05:18 rockingham slapd[6662]: Unlock CR index = 0x94e70f0 > Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, SIZE=0 > Apr 9 05:05:18 rockingham slapd[6662]: STORED QUERIES = 23 > Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, CACHE =17 > entries > Apr 9 05:05:18 rockingham slapd[6662]: Lock CR index = 0x94e70f0 > Apr 9 05:05:18 rockingham slapd[6662]: TEMPLATE 0x94e70f0 QUERIES-- 1 > Apr 9 05:05:18 rockingham slapd[6662]: Unlock CR index = 0x94e70f0 > Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, SIZE=0 > Apr 9 05:05:18 rockingham slapd[6662]: STORED QUERIES = 22 > Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, CACHE =17 > entries > Apr 9 05:05:18 rockingham slapd[6662]: Lock CR index = 0x94e70f0 > Apr 9 05:05:18 rockingham slapd[6662]: TEMPLATE 0x94e70f0 QUERIES-- 0 > Apr 9 05:05:18 rockingham slapd[6662]: Unlock CR index = 0x94e70f0 > Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, SIZE=0 > Apr 9 05:05:18 rockingham slapd[6662]: STORED QUERIES = 21 > Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, CACHE =17 > entries > Apr 9 05:05:18 rockingham slapd[6662]: Lock CR index = 0x94e6eb0 > > > Here's the backtrace: > > Program terminated with signal 11, Segmentation fault. > #0 0x081764ed in pcache_query_cmp (v1=0xb1f0e900, v2=0x83e58955) > at pcache.c:694 > 694 return pcache_filter_cmp( q1->first, q2->first ); > (gdb) bt > #0 0x081764ed in pcache_query_cmp (v1=0xb1f0e900, v2=0x83e58955) > at pcache.c:694 > #1 0x08199b6d in tavl_delete (root=0x825d7d0, data=0xb1f0e900, > fcmp=0x81764d8<pcache_query_cmp>) at tavl.c:202 > #2 0x08177ab4 in remove_from_template (qc=0xb1f0e900, > template=0x94e6eb0) > at pcache.c:1302 > #3 0x0817b57d in consistency_check (ctx=0xb44201d0, arg=0x9537c50) > at pcache.c:2597 > #4 0x0819fd01 in ldap_int_thread_pool_wrapper (xpool=0x94a8fa0) at > tpool.c:663 > #5 0x009c546b in start_thread () from /lib/libpthread.so.0 > #6 0x0091cdbe in clone () from /lib/libc.so.6 > (gdb) > (gdb) p q1->first > $3 = (Filter *) 0xb1f0d4c0 > (gdb) p q2->first > Cannot access memory at address 0x83e58959 > > Let me know what else would be useful from this backtrace. Nothing obvious is jumping out here. Can you run a few of these slapds with libefence or valgrind? -- -- 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#6050) make install overwrites schema dir
by hyc＠symas.com 09 Apr '09

09 Apr '09

tmackey(a)zetta.net wrote: > Full_Name: Theral Mackey > Version: 2.4.16 > OS: Linux/Debian > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (216.200.8.2) > > > Running make install leaves an existing slapd.conf alone, but happily nukes and > replaces the existing schema directory, taking with it any additional or custom > schema, leaving you with only the ones installed by default (hooray for svn and > backups!). No, it doesn't. > For consistency, it should probably either nuke slapd.conf as well, or leave an > existing schema dir alone (I vote for option 2). > fix should be as simple as an 'if [ ! -d $base/schema ] ; then (mkdir, cp > schemas, etc) ; fi' around where it drops the schemas in place in the Makefile Since you're already looking in the Makefile, you should see this for the install-schema: rule... ### install-schema: FORCE @if test -d $(DESTDIR)$(schemadir) ; then \ echo "MOVING EXISTING SCHEMA DIR to $(DESTDIR)$(schemadir).$$$$" ; \ mv $(DESTDIR)$(schemadir) $(DESTDIR)$(schemadir).$$$$ ; \ fi $(MKDIR) $(DESTDIR)$(schemadir) ### The existing schema directory is simply renamed / moved out of the way. If you had any custom schema files stored there, they are still there. 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

(ITS#6050) make install overwrites schema dir
by tmackey＠zetta.net 09 Apr '09

09 Apr '09

Full_Name: Theral Mackey Version: 2.4.16 OS: Linux/Debian URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (216.200.8.2) Running make install leaves an existing slapd.conf alone, but happily nukes and replaces the existing schema directory, taking with it any additional or custom schema, leaving you with only the ones installed by default (hooray for svn and backups!). For consistency, it should probably either nuke slapd.conf as well, or leave an existing schema dir alone (I vote for option 2). fix should be as simple as an 'if [ ! -d $base/schema ] ; then (mkdir, cp schemas, etc) ; fi' around where it drops the schemas in place in the Makefile

1 0

Re: (ITS#5856) adauth overlay contribution
by hyc＠symas.com 09 Apr '09

09 Apr '09

neil.dunbar(a)hp.com wrote: > On Tue, 2008-12-16 at 14:52 +0000, Neil Dunbar wrote: >> Andrew: >>> One suggestion following a very quick scan of the code: I think it >>> would be worth bringing the warning about turning off TLS checks >>> into the manual page. >> >> Agreed. Done. >> >>> In particular, there is no reason for this >>> to be AD-specific and it should be easy to adapt it to authenticate >>> against any [collection of] remote LDAP servers. >> >> Actually, it may not be AD specific as is. > > Are we any further forward to getting this rolled into contrib? Is there > more we need to do to make it fit better? The tarball has been sitting > there a while, it would seem. I've reviewed the package and have some comments. I'm puzzled by the design of this overlay; in ActiveDirectory a user can exist in only one domain and there is a one-to-one mapping between their domain name and the suffix of their LDAP DN. As such, the lookup of the adauth_domain_attribute seems clumsy and unnecessary. The adauth_default_realm and adauth_default_domain terms are confusing. Your adauth_default_realm item is really just the hostname of a particular server. Your use of the word "realm" is basically inconsistent with common usage of this term. The usage for adauth_mapping is clumsy; you could simply have made it a list of LDAP URLs and not bothered with an external file. Is there a commonly used external file that other software uses, that prompted this approach? The description of adauth_dn_attribute is misleading. Is it a DN, or is it a userPrincipalName? In what way is this a "map" at all? Examining the code, it is simply "the DN of the user to Bind against on the remote LDAP server" - it is not a map, nor is it a userPrincipalName. I wonder in what context this overlay is easily used. If I have 100,000 users in my LDAP directory, I don't want to maintain 100,000 AD_DN attributes for them; I want a simple rule that actually performs an algorithmic mapping of their local DN to their remote DN. I suppose using an AD_DN attribute for the users whose DNs don't easily map might be a good fallback, but it shouldn't be the primary mechanism for linking a local user to a remote user. I would re-use the authz-regexp machinery here. It seems there's a lot of AD-specific overhead in this code, for what is really a pretty simple and generic operation - passthru Bind to a remote LDAP server. I would have used the back-ldap/chain.c code instead, which would also provide connection pooling and the other benefits of back-ldap's already comprehensive support for communicating with remote LDAP servers. -- -- 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#6049) Client tools' help inaccurate
by jzeleny＠redhat.com 09 Apr '09

09 Apr '09

Full_Name: Jan Zeleny Version: 2.4.15 OS: Fedora 11 URL: http://jzeleny.fedorapeople.org/patches/openldap/openldap-options.patch Submission from: (NULL) (62.40.79.66) Client tools share a part of help printed to stdout. In this shared help, there are some options, even if they are not in fact supported by all client tools. I've made a simple patch to resolve this minor issue.

1 0

Re: (ITS#6021) slapo-pcache/back-ldap slapd crashes
by toby＠inf.ed.ac.uk 09 Apr '09

09 Apr '09

OK, this is my first crash since moving to 2.4.16: Slightly different from the previous ones, but is coming through pcache.c:remove_from_template and, according to slapd log, was removing queries from cache when crash occurred: Apr 9 05:05:18 rockingham slapd[6662]: Lock CR index = 0x94e70f0 Apr 9 05:05:18 rockingham slapd[6662]: TEMPLATE 0x94e70f0 QUERIES-- 5 Apr 9 05:05:18 rockingham slapd[6662]: Unlock CR index = 0x94e70f0 Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, SIZE=0 Apr 9 05:05:18 rockingham slapd[6662]: STORED QUERIES = 26 Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, CACHE =17 entries Apr 9 05:05:18 rockingham slapd[6662]: Lock CR index = 0x94e70f0 Apr 9 05:05:18 rockingham slapd[6662]: TEMPLATE 0x94e70f0 QUERIES-- 4 Apr 9 05:05:18 rockingham slapd[6662]: Unlock CR index = 0x94e70f0 Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, SIZE=0 Apr 9 05:05:18 rockingham slapd[6662]: STORED QUERIES = 25 Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, CACHE =17 entries Apr 9 05:05:18 rockingham slapd[6662]: Lock CR index = 0x94e70f0 Apr 9 05:05:18 rockingham slapd[6662]: TEMPLATE 0x94e70f0 QUERIES-- 3 Apr 9 05:05:18 rockingham slapd[6662]: Unlock CR index = 0x94e70f0 Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, SIZE=0 Apr 9 05:05:18 rockingham slapd[6662]: STORED QUERIES = 24 Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, CACHE =17 entries Apr 9 05:05:18 rockingham slapd[6662]: Lock CR index = 0x94e70f0 Apr 9 05:05:18 rockingham slapd[6662]: TEMPLATE 0x94e70f0 QUERIES-- 2 Apr 9 05:05:18 rockingham slapd[6662]: Unlock CR index = 0x94e70f0 Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, SIZE=0 Apr 9 05:05:18 rockingham slapd[6662]: STORED QUERIES = 23 Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, CACHE =17 entries Apr 9 05:05:18 rockingham slapd[6662]: Lock CR index = 0x94e70f0 Apr 9 05:05:18 rockingham slapd[6662]: TEMPLATE 0x94e70f0 QUERIES-- 1 Apr 9 05:05:18 rockingham slapd[6662]: Unlock CR index = 0x94e70f0 Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, SIZE=0 Apr 9 05:05:18 rockingham slapd[6662]: STORED QUERIES = 22 Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, CACHE =17 entries Apr 9 05:05:18 rockingham slapd[6662]: Lock CR index = 0x94e70f0 Apr 9 05:05:18 rockingham slapd[6662]: TEMPLATE 0x94e70f0 QUERIES-- 0 Apr 9 05:05:18 rockingham slapd[6662]: Unlock CR index = 0x94e70f0 Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, SIZE=0 Apr 9 05:05:18 rockingham slapd[6662]: STORED QUERIES = 21 Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, CACHE =17 entries Apr 9 05:05:18 rockingham slapd[6662]: Lock CR index = 0x94e6eb0 Here's the backtrace: Program terminated with signal 11, Segmentation fault. #0 0x081764ed in pcache_query_cmp (v1=0xb1f0e900, v2=0x83e58955) at pcache.c:694 694 return pcache_filter_cmp( q1->first, q2->first ); (gdb) bt #0 0x081764ed in pcache_query_cmp (v1=0xb1f0e900, v2=0x83e58955) at pcache.c:694 #1 0x08199b6d in tavl_delete (root=0x825d7d0, data=0xb1f0e900, fcmp=0x81764d8 <pcache_query_cmp>) at tavl.c:202 #2 0x08177ab4 in remove_from_template (qc=0xb1f0e900, template=0x94e6eb0) at pcache.c:1302 #3 0x0817b57d in consistency_check (ctx=0xb44201d0, arg=0x9537c50) at pcache.c:2597 #4 0x0819fd01 in ldap_int_thread_pool_wrapper (xpool=0x94a8fa0) at tpool.c:663 #5 0x009c546b in start_thread () from /lib/libpthread.so.0 #6 0x0091cdbe in clone () from /lib/libc.so.6 (gdb) (gdb) p q1->first $3 = (Filter *) 0xb1f0d4c0 (gdb) p q2->first Cannot access memory at address 0x83e58959 Let me know what else would be useful from this backtrace. Cheers Toby -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

Re: (ITS#6043) slapd segfaults in bdb_rdn_cmp
by luca.scamoni＠sys-net.it 08 Apr '09

08 Apr '09

luca.scamoni(a)sys-net.it ha scritto: > Howard Chu ha scritto: >> This trace is bogus, there's no call from slapd_daemon_destroy() to >> epoll_wait() in the code. And you wouldn't have gotten to >> slapd_daemon_destroy() unless you were shutting down. >> >> >> This is also bogus; is this an optimized compile? It's always hard to >> tell how much to trust the debugger here; if there are no further stack >> frames then possibly the stack was overwritten. But if you compiled with >> any type of optimization, and didn't use -fno-omit-frame-pointer, then >> that may be all that's happening here. >> > I managed to find out how to reproduce the issue. Now it's deterministic > and happens with openldap-2.4.16. > The segfault can be caused by performing an ldapmodify on a specific > entry replacing a binary attribute certificateRevocationList. > > I'm sending privately the backtrace analized with gdb and the slapd.conf > file Another update The issue seems to be in the order in which rwm and syncprov are invoked. If the slapd.conf file contains: database hdb [...] overlay rwm [...] overlay syncprov [...] the modification causes slapd to segfault if the two overlays are swapped database hdb [...] overlay syncprov [...] overlay rwm [...] it doesn't. So there is something wrong in the interaction between these two Ing. Luca Scamoni Responsabile Ricerca e Sviluppo SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 0382 573859 (137) Fax: +39 0382 476497 Email: luca.scamoni(a)sys-net.it -----------------------------------

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs