openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

(ITS#6221) slapd segfault in SSL_CTX_set_info_callback
by steve＠falchion.com 20 Jul '09

20 Jul '09

Full_Name: Steve Paras-Charlton Version: 2.4.16 OS: AIX URL: ftp://ftp.openldap.org/incoming/spc-slapd-info.txt.1 Submission from: (NULL) (66.18.215.114) slapd works fine unless I enable TLS and give it certificates (self-signed). Segfault occurs after reading config and opening certificate files. built with: gcc 4.2.0, openssl 9.8.840 configure --enable-crypt --enable-modules --enable-overlays --with-tls=openssl --prefix=/usr/local backtrace, program trace and slapd.conf attached ftp://ftp.openldap.org/incoming/spc-slapd-info.txt.1

1 0

(ITS#6220) Problem with writetimeout
by moenoel＠informatik.uni-bremen.de 20 Jul '09

20 Jul '09

Full_Name: Christian Manal Version: 2.4.17 OS: SunOS 5.10 Generic_139556-08 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:638:708:30c9:221:85ff:fe3f:1775) Clients that take a long time to process search results are geting a writetimeout, even though the keyword is unset or 0 in slapd.conf. Setting the value to a big enough number solves the problem, but that behavior doesn't conform to the docs. Noticed through a Net::LDAP based Perl-scipt, which reads a big amount of entries from the directory, but failed sporadically on slow systems since updating to OpenLDAP 2.4.17. Backend is hdb using BDB 4.4 from opencsw repository. Server setup is one master and four slaves on Solaris 10. Sample of 'stats' log: Jul 20 11:42:43 ldapserver slapd[9053]: [ID 848112 local4.debug] conn=12479 fd=79 ACCEPT from IP=192.168.1.1:50210 (IP=0.0.0.0:389) Jul 20 11:42:43 ldapserver slapd[9053]: [ID 270379 local4.debug] conn=12479 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jul 20 11:42:43 ldapserver slapd[9053]: [ID 560212 local4.debug] conn=12479 op=0 STARTTLS Jul 20 11:42:43 ldapserver slapd[9053]: [ID 875301 local4.debug] conn=12479 op=0 RESULT oid= err=0 text= Jul 20 11:42:43 ldapserver slapd[9053]: [ID 105384 local4.debug] conn=12479 fd=79 TLS established tls_ssf=256 ssf=256 Jul 20 11:42:43 ldapserver slapd[9053]: [ID 215403 local4.debug] conn=12479 op=1 BIND dn="uid=dummyuser,ou=System,dc=example,dc=com" method=128 Jul 20 11:42:43 ldapserver slapd[9053]: [ID 600343 local4.debug] conn=12479 op=1 BIND dn="uid=dummyuser,ou=System,dc=example,dc=com" mech=SIMPLE ssf=0 Jul 20 11:42:43 ldapserver slapd[9053]: [ID 588225 local4.debug] conn=12479 op=1 RESULT tag=97 err=0 text= Jul 20 11:42:43 ldapserver slapd[9053]: [ID 469902 local4.debug] conn=12479 op=2 SRCH base="ou=people,dc=example,dc=com" scope=2 deref=2 filter="(objectClass=posixAccount)" Jul 20 11:42:43 ldapserver slapd[9053]: [ID 744844 local4.debug] conn=12479 op=2 SRCH attr=uid userpassword uidnumber gidnumber gecos homedirectory loginshell Jul 20 11:43:00 ldapserver slapd[9053]: [ID 485650 local4.debug] conn=12479 fd=79 closed (writetimeout) The (slightly modified) config files of the master and the slaves can be obtained here: http://www.informatik.uni-bremen.de/~moenoel/ldap/master.conf http://www.informatik.uni-bremen.de/~moenoel/ldap/slaves.conf

1 0

Re: (ITS#6218) MirrorMode documentation error?
by quanah＠zimbra.com 18 Jul '09

18 Jul '09

--On Friday, July 17, 2009 11:05 PM +0000 richard(a)theloop.eu wrote: > Full_Name: Richard Watson > Version: 2.4.16 > OS: Mac OS X > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (41.177.22.129) > > > In section 18.3.4 MirrorMode: > > MirrorMode node 1: ># Global section > serverID 1 ># database section ># syncrepl directive > syncrepl rid=001 > > > I believe this should end with "rid=002" Why? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6218) MirrorMode documentation error?
by richard＠theloop.eu 18 Jul '09

18 Jul '09

Full_Name: Richard Watson Version: 2.4.16 OS: Mac OS X URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (41.177.22.129) In section 18.3.4 MirrorMode: MirrorMode node 1: # Global section serverID 1 # database section # syncrepl directive syncrepl rid=001 I believe this should end with "rid=002"

1 0

(ITS#6217) proxycache not returning cached data
by w.van.keulen＠few.vu.nl 16 Jul '09

16 Jul '09

Full_Name: Jim van Keulen Version: 2.4.16 OS: Solaris 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (130.37.192.24) Using openldap-2.4.16 proxcache to search a SUN Directory Server for user data, a query identified by the proxycache server to be CACHEABLE and ANSWERABLE does not return data. For some users (uid's) the data is returned, while not for others. Config: database ldap suffix "dc=few,dc=vu,dc=nl" rootdn cn=Manager,dc=few,dc=vu,dc=nl rootpw secret tls start uri ldap://klondike.few.vu.nl acl-bind bindmethod=simple binddn="cn=sambaLdapManager,ou=Special Users,dc=few,dc=vu,dc=nl" credentials="xxx" sizelimit unlimited overlay pcache proxycache bdb 100000 10 1000 100 proxyAttrset 0 gidNumber sambaSID sambaGroupType sambaSIDList description displayName cn objectClass uid uidNumber homeDirectory sambaPwdLastSet sambaPwdCanChange sambaPwdMustChange sambaLogonTime sambaLogoffTime sambaKickoffTime sn sambaHomeDrive sambaHomePath sambaLogonScript sambaProfilePath sambaUserWorkstations sambaSID sambaPrimaryGroupSID sambaDomainName sambaAcctFlagssambaMungedDial sambaBadPasswordCount sambaBadPasswordTime sambaPasswordHistory modifyTimestamp sambaLogonHours modifyTimestamp sambaMaxPwdAge sambaPwdHistoryLength memberUid proxyTemplate (&(objectClass=)(uid=)) 0 1800 cachesize 10000 directory /var/opt/openldap/openldap-data/proxy access to * by * write index objectclass eq index cn pres,sub,eq index sn pres,sub,eq End Config I query with ldapsearch -x -h flits '(&(objectClass=sambaSamAccount)(uid=????))' uid This returns data when e.g. uid=jim, but not when e.g. uid=hbokman. I have no clue why it works for some users, but not for others. When I query the first time I get the requested data from the proxied server fine. It is cached, but not always retrieved. ldapsearch -x -h flits '(&(objectClass=sambaSamAccount)(uid=jim))' uid # extended LDIF # # LDAPv3 # base <> with scope subtree # filter: (&(objectClass=sambaSamAccount)(uid=jim)) # requesting: uid # # jim, People, few.vu.nl dn: uid=jim,ou=People,dc=few,dc=vu,dc=nl uid: jim # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 **** output from slapd -d4096 for query ****** query template of incoming query = (&(objectClass=)(uid=)) Entering QC, querystr = (&(objectClass=sambaSamAccount)(uid=jim)) Lock QC index = 31f738 QUERY ANSWERABLE ************************************** ldapsearch -x -h flits '(&(objectClass=sambaSamAccount)(uid=hbokman))' uid # extended LDIF # # LDAPv3 # base <> with scope subtree # filter: (&(objectClass=sambaSamAccount)(uid=hbokman)) # requesting: uid # # search result search: 2 result: 0 Success # numResponses: 1 ****** output form slapd -d4096 for query ****** query template of incoming query = (&(objectClass=)(uid=)) Entering QC, querystr = (&(objectClass=sambaSamAccount)(uid=hbokman)) Lock QC index = 31f738 QUERY ANSWERABLE ***************************************

1 0

Re: (ITS#6216) Slapd crashes when adding a backend without olcsuffix but with a olcsubordinate
by sebastien.bahloul＠gmail.com 16 Jul '09

16 Jul '09

--Boundary-00=_qWzXKhFjpfl1KM/ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Successfully tested with and without a valid olcSubordinate attribute. Thanks :) Le jeudi 16 juillet 2009 15:39:31, Pierangelo Masarati a =E9crit : > sebastien.bahloul(a)gmail.com wrote: > > Full_Name: Sebastien Bahloul > > Version: 2.X (HEAD from July, 15 2009) > > OS: Ubuntu 9.04 64 bits > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (80.65.230.146) > > > > > > It seems that slapd crashes when I try to add a simple hdb backend (also > > confirmed with a bdb) without an olcSuffix attribute but with an > > olcSubordinate attribute value : > > Fixed in HEAD, please test. > > Also, please note that olcSubordinate: FALSE is not valid; the > olcSubordinate can only be "TRUE" or "advertise". If you don't want a > database to be subordinate, simply omit the olcSubordinate attribute > from the configuration. > > p. --Boundary-00=_qWzXKhFjpfl1KM/ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-= html40/strict.dtd"><html><head><meta name=3D"qrichtext" content=3D"1" /><st= yle type=3D"text/css">p, li { white-space: pre-wrap; }</style></head><body = style=3D" font-family:'DejaVu Sans'; font-size:9pt; font-weight:400; font-s= tyle:normal;">Successfully tested with and without a valid olcSubordinate a= ttribute. Thanks :) Le jeudi 16 juillet 2009 15:39:31, Pierangelo Masarat= i a =E9crit : > sebastien.bahloul(a)gmail.com wrote: > > Full_Name: Sebastien Bahloul > > Version: 2.X (HEAD from July, 15 2009) > > OS: Ubuntu 9.04 64 bits > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (80.65.230.146) > > > > > > It seems that slapd crashes when I try to add a simple hdb backen= d (also > > confirmed with a bdb) without an olcSuffix attribute but with an<= br> > > olcSubordinate attribute value : > > Fixed in HEAD, please test. > > Also, please note that olcSubordinate: FALSE is not valid; the > olcSubordinate can only be "TRUE" or "advertise". If you don't want a= > database to be subordinate, simply omit the olcSubordinate attribute<b= r> > from the configuration. > > p. </body></html> --Boundary-00=_qWzXKhFjpfl1KM/--

1 0

Re: (ITS#6216) Slapd crashes when adding a backend without olcsuffix but with a olcsubordinate
by masarati＠aero.polimi.it 16 Jul '09

16 Jul '09

sebastien.bahloul(a)gmail.com wrote: > Full_Name: Sebastien Bahloul > Version: 2.X (HEAD from July, 15 2009) > OS: Ubuntu 9.04 64 bits > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (80.65.230.146) > > > It seems that slapd crashes when I try to add a simple hdb backend (also > confirmed with a bdb) without an olcSuffix attribute but with an olcSubordinate > attribute value : Fixed in HEAD, please test. Also, please note that olcSubordinate: FALSE is not valid; the olcSubordinate can only be "TRUE" or "advertise". If you don't want a database to be subordinate, simply omit the olcSubordinate attribute from the configuration. p.

1 0

(ITS#6216) Slapd crashes when adding a backend without olcsuffix but with a olcsubordinate
by sebastien.bahloul＠gmail.com 16 Jul '09

16 Jul '09

Full_Name: Sebastien Bahloul Version: 2.X (HEAD from July, 15 2009) OS: Ubuntu 9.04 64 bits URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.65.230.146) It seems that slapd crashes when I try to add a simple hdb backend (also confirmed with a bdb) without an olcSuffix attribute but with an olcSubordinate attribute value : dn: olcDatabase=hdb,cn=config objectclass: olcDatabaseConfig objectclass: olcConfig objectclass: olcHdbConfig objectclass: top olcdatabase: hdb olcdbdirectory: /tmp olcsubordinate: FALSE GDB Backtrace : conn=0 op=1 ADD dn="olcDatabase=hdb,cn=config" Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fd13c010950 (LWP 7210)] 0x0000000000482fd1 in glue_sub_attach (online=1) at backglue.c:1167 1167 Debug( LDAP_DEBUG_ANY, "glue: no superior found for sub %s!\n", (gdb) bt #0 0x0000000000482fd1 in glue_sub_attach (online=1) at backglue.c:1167 #1 0x0000000000408364 in config_subordinate (c=0x7fd13c00e5f0) at bconfig.c:2354 #2 0x0000000000415c33 in config_set_vals (Conf=0x7dbe20, c=0xffffffff) at config.c:325 #3 0x000000000041989d in config_parse_add (ct=0x7dbe20, c=0x7fd13c00e5f0, valx=<value optimized out>) at config.c:665 #4 0x000000000040fdea in config_add_internal (cfb=0x7e5680, e=0x19492f8, ca=0x7fd13c00e5f0, rs=<value optimized out>, renum=0x7fd13c00e5ec, op=<value optimized out>) at bconfig.c:4573 #5 0x00000000004109d3 in config_back_add (op=0x1a47b30, rs=0x7fd13c00fc70) at bconfig.c:4800 #6 0x000000000042695e in fe_op_add (op=0x1a47b30, rs=0x7fd13c00fc70) at add.c:334 #7 0x000000000042728f in do_add (op=0x1a47b30, rs=0x7fd13c00fc70) at add.c:194 #8 0x000000000041f7b7 in connection_operation (ctx=0x7fd13c00fdd0, arg_v=<value optimized out>) at connection.c:1115 #9 0x0000000000420455 in connection_read_thread (ctx=0x7fd13c00fdd0, argv=<value optimized out>) at connection.c:1251 #10 0x0000000000528010 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:685 #11 0x00007fd1526943ba in start_thread () from /lib/libpthread.so.0 #12 0x00007fd151c10fcd in clone () from /lib/libc.so.6 #13 0x0000000000000000 in ?? ()

1 0

Re: (ITS#5696) Patch - support Mozilla NSS for crypto operations
by hyc＠symas.com 14 Jul '09

14 Jul '09

Rich Megginson wrote: > Howard Chu wrote: >> Ok. The configure patches are in too, so moznss may be selected. But I >> think we'll wait on making this generally available until we know what >> the story will be for PEM and multi-init. > Ok Fyi, the code patches are in 2.4.17, but I held back the configure patches (which are only in HEAD). So you should be able to manually define HAVE_MOZNSS for testing purposes with this release. -- -- 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#6215) liblber problems
by h.b.furuseth＠usit.uio.no 14 Jul '09

14 Jul '09

Full_Name: Hallvard B Furuseth Version: OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard Given these declarations: #include <lber.h> #define LBER_EXBUFSIZ 4060 /* from liblber/io.c */ static char data[8000]; struct berval bv; BerElement *ber; Buffer overrun i ber_flatten(,,0): ber = der_alloc(); ber_printf(ber, "o", data, LBER_EXBUFSIZ - 4); ber_flatten2(ber, &bv, 0); ber_flatten2(,,0) \0-terminates the Ber buffer, but does not grow it first at need. Simplest fix is to allocate an extra byte in ber_realloc(), and reduce LBER_EXBUFSIZ by 1 to compensate. I don't know how kosher it is to write into the ber buffer in the first place though. Coredump - write through NULL pointer: ber_flatten2(der_alloc(), &bv, 0); A fresh Ber has no buffers yet, the buffer pointers are NULL. \0-terminating a NULL pointer doesn't work too well. Don't know if it should be called a bug though, since ber_flatten2() doesn't work right on an incomplete Ber element either (due to seqorset stuff). The NULL pointers in a fresh ber also mean ber_write, ber_len() & co do pointer arithmetic on NULL pointers, which is not valid. Oh well, it seems to work on most machines. Buffer overrun in ber_write(): ber = der_alloc(); ber_printf(ber, "{"); ber_write(ber, data, 6000, 0); ber_write() needs buffer space and calls ber_realloc(ber, 6000). However "{" has moved ber->ber_sos->sos_ptr (the write destination) 6 bytes beyond ber->ber_end, so 6006 bytes are actually needed. ber_realloc() does not know that, and allocates 6000 bytes. It cannot happen with ber_write() called from liblber: Next liblber write after "{" will be just a few bytes with the next element's tag. ber_realloc() always allocates 4060 bytes or more - moving sos_ptr beyond ber_end again. This can only happen if a caller outside liblber generates a complete "tag, length, contents" element >= 4060 bytes and ber_write()s it in one operation. There are ber_write()s in libldap and slapd/connection.c, but haven't checked if any are at risk. Don't know where to fix it: - in ber_realloc(), most techinically correct. - in ber_write() - simpler since it already knows about sos_ptr. - in ber_start_seqorset() - always alloc a buffer, never point beyond allocated data. Cleanest but most space-costly.

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