openldap-bugs February 2010

openldap-bugs@openldap.org

28 participants
69 discussions

(ITS#6475) SASL OTP and syncrepl
by manu＠netbsd.org 16 Feb '10

16 Feb '10

Full_Name: Emmanuel Dreyfus Version: any OS: any URL: ftp://ftp.openldap.org/incoming/ldapotp.tgz Submission from: (NULL) (213.41.141.172) When binding using SASL OTP to a replica, the bind works, but the cmusaslsecretOTP attribute is modified on the replica and fail to be propagated to the master. On the next modification, the master will overwrite the replica's updated cmusaslsecretOTP value. Here is a script that exhibit the behaviour: ftp://ftp.openldap.org/incoming/ldapotp.tgz That require SASL enabled OpenLDAP, with the OTP plugin installed. The PATH in run.sh must probably be adjusted.

1 0

(ITS#6474) test004 (hdb) crashes when slapd is compiled with -D_FORTIFY_SOURCE=2
by ralf＠OpenLDAP.org 15 Feb '10

15 Feb '10

Full_Name: Ralf Haferkamp Version: HEAD, RE24 OS: linux (gcc 4.5) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.207.32) Submitted by: ralf gcc 4.5 will do some stricter checks for buffer overflows when compiling with -D_FORTIFY_SOURCE=2. Current HEAD aborts in test004-modify with: *** buffer overflow detected ***: /usr/src/packages/BUILD/openldap-2.4.21/servers/slapd/.libs/slapd terminated ======= Backtrace: ========= #0 0x00007f207dc6b9c5 in raise () from /lib64/libc.so.6 #1 0x00007f207dc6ced6 in abort () from /lib64/libc.so.6 #2 0x00007f207dca6ba9 in __libc_message () from /lib64/libc.so.6 #3 0x00007f207dd20537 in __fortify_fail () from /lib64/libc.so.6 #4 0x00007f207dd1e2e0 in __chk_fail () from /lib64/libc.so.6 #5 0x00007f207fa89769 in strcpy () at dn2id.c:679 There is no real buffer overflow here AFAICS but the real problem is, that the destination of the strcpy() is defined as char[1] in this case (it's the nrdn member of a struct diskNode). The additional runtime check when compiling with -D_FORTIFY_SOURCE=2 sees that the destination data will not fit in there and aborts. The easiest fix here (apart from not building with -D_FORTIFY_SOURCE=2) is to use memcpy instead of strcpy here. I'll submit that later today.

1 0

Re: (ITS#6322) slapd suddenly stops working, and starts using 100% CPU
by helge＠monsternett.no 15 Feb '10

15 Feb '10

Hello again. We randomly tried to switch to LDAP without SSL last Friday (we used ldaps://..:636/ before), and the server hasn't crashed since! This is a good enough workaround for us, but I hope this information can help with fixing this bug, or help others with the same problem. On Wed, Dec 30, 2009 at 02:08:00PM +0100, Helge Milde wrote: >On Wed, Dec 30, 2009 at 09:04:12AM +0100, Helge Milde wrote: >>I just enabled trace loglevel, perhaps that might give us a clue on what's going on. > >Slapd just stopped working again. Here's the (annotated) log for viewing and/or downloading: >http://www.pastie.org/761198.txt > >Does this give you any clues? > >Tell me if I can do anything else to help. > >-- >Helge Milde, 69701808 >www.monsternett.no -- Helge Milde, 69701808 www.monsternett.no

1 0

Re: (ITS#6471) dynlist overlay only acknowledging last dynlist-attrset statement
by j＠gropefruit.com 14 Feb '10

14 Feb '10

If nothing else, if this is in fact some strange 'elusive' bug, someone = else experiencing it may find this thread useful or enlightening in some = way (or perhaps it may help them further identify the particulars of = this intermittent phenomenon). I too must avoid spending further time = on this issue, as my team considers it suitably fixed; thus not = requiring further invested resources on my part. Thanks for your time on this issue, I must move on now. J=

1 0

Re: (ITS#6471) dynlist overlay only acknowledging last dynlist-attrset statement
by masarati＠aero.polimi.it 14 Feb '10

14 Feb '10

> Interesting. I can't seem to imagine why this behaved the way it did = > (looking over my config again) I am just happy that moving it fixed = > the issue. Well, unless you can come up with a configuration AND a test case that is fully reproducible, I'd rather avoid spending further time on this issue. If the problem is related to intermixing configuration statements, then it is a bug, but it might only surface when something really odd happens (like one module mucking with some pointer somewhere and not restoring things as they should be). Then the only thing we can do is exactly track what caused this. However, in your case, you're not actually intermixing statements, but rather sort overlays differently: all dynlist related statements exactly follow the "overlay dynlist" statement, but different overlays are ordered differently. This calls for unexpected interaction between overlays stack execution that results in the odd behavior you observed. This should be a bug as well, unless there is a good reason for having different behavior when overlays are stacked differently (e.g. an overlay legally mucks with data that is later handled by another). Again, unless you can present a clearly reproducible case, it's quite hard to track, and likely impossible if it's data dependent. So I'm happy you solved your specific issue by rearranging the order of the overlays. p.

1 0

Re: (ITS#6471) dynlist overlay only acknowledging last dynlist-attrset statement
by j＠gropefruit.com 14 Feb '10

14 Feb '10

Interesting. I can't seem to imagine why this behaved the way it did = (looking over my config again) I am just happy that moving it fixed = the issue. On Feb 14, 2010, at 00:55 , masarati(a)aero.polimi.it wrote: >> First of all, I am paraphrasing. No one is hiding anything from you = =3D >> Pierre. You need only ask.=3D20 >>=20 >>> It is supposed to be a bug. It's also the reason I asked from the >>> beginning to see the real configuration, real data and real = operation >>> causing the issue. If you keep hiding essential details, and only =3D= >> provide >>> bits of information each time, it'll take ages to just discover = where =3D >> the >>> issue is. >>=20 >>=20 >>> So now the only way to keep this ITS open is to see your ENTIRE =3D >> slapd.conf >>> (except passwords, of course). An even better alternative would be = to >>> receive a sanitized slapd.conf, a LDIF and a search operation based = on >>> ldapsearch that clearly illustrates the issue, like what I posted a = =3D >> couple >>> of postings ago. >>=20 >> Here, the entire sanitized config. I left out the ACL file (the = include =3D >> statement at the very end), but the behavior in question was = happening =3D >> to the rootdn user as well, meaning ACLs weren't the culprit. I also = =3D >> removed 14 of 15 of the syncrepl stanzas for brevity, as they were = all =3D >> the same aside from hostname/IP. >>=20 >> NOTE the sections labeled WORKS HERE, and BROKEN HERE, which denote = the =3D >> original (dysfunctional) position vs the current (functional) = position. >=20 > I can't see any difference in behavior with the configuration in > <ftp://ftp.openldap.org/incoming/slapd-its6471-1.conf>, the data and = the > ldapsearch command described in my previous posting (the only = difference > is that now, after "./run -b hdb test003" you need to manually create > directory "testrun/db.2.a" for the log database, and bind as the = rootdn to > perform the search). I tried both HEAD and current re24 code, which > should not differ much from 2.4.21. The only modifications to > configuration are related to: statically built backends/overlays, no = ACLs, > no TLS. Also, valgrind does not show anything strange (like dangling > pointers or so) which could be symptoms of doing nasty things with = memory > that make my setup work "by chance". >=20 > p. >=20

1 0

Re: (ITS#6471) dynlist overlay only acknowledging last dynlist-attrset statement
by masarati＠aero.polimi.it 14 Feb '10

14 Feb '10

> First of all, I am paraphrasing. No one is hiding anything from you = > Pierre. You need only ask.=20 > >> It is supposed to be a bug. It's also the reason I asked from the >> beginning to see the real configuration, real data and real operation >> causing the issue. If you keep hiding essential details, and only = > provide >> bits of information each time, it'll take ages to just discover where = > the >> issue is. > > >> So now the only way to keep this ITS open is to see your ENTIRE = > slapd.conf >> (except passwords, of course). An even better alternative would be to >> receive a sanitized slapd.conf, a LDIF and a search operation based on >> ldapsearch that clearly illustrates the issue, like what I posted a = > couple >> of postings ago. > > Here, the entire sanitized config. I left out the ACL file (the include = > statement at the very end), but the behavior in question was happening = > to the rootdn user as well, meaning ACLs weren't the culprit. I also = > removed 14 of 15 of the syncrepl stanzas for brevity, as they were all = > the same aside from hostname/IP. > > NOTE the sections labeled WORKS HERE, and BROKEN HERE, which denote the = > original (dysfunctional) position vs the current (functional) position. I can't see any difference in behavior with the configuration in <ftp://ftp.openldap.org/incoming/slapd-its6471-1.conf>, the data and the ldapsearch command described in my previous posting (the only difference is that now, after "./run -b hdb test003" you need to manually create directory "testrun/db.2.a" for the log database, and bind as the rootdn to perform the search). I tried both HEAD and current re24 code, which should not differ much from 2.4.21. The only modifications to configuration are related to: statically built backends/overlays, no ACLs, no TLS. Also, valgrind does not show anything strange (like dangling pointers or so) which could be symptoms of doing nasty things with memory that make my setup work "by chance". p.

1 0

Re: (ITS#6471) dynlist overlay only acknowledging last dynlist-attrset statement
by j＠gropefruit.com 13 Feb '10

13 Feb '10

First of all, I am paraphrasing. No one is hiding anything from you = Pierre. You need only ask.=20 > It is supposed to be a bug. It's also the reason I asked from the > beginning to see the real configuration, real data and real operation > causing the issue. If you keep hiding essential details, and only = provide > bits of information each time, it'll take ages to just discover where = the > issue is. > So now the only way to keep this ITS open is to see your ENTIRE = slapd.conf > (except passwords, of course). An even better alternative would be to > receive a sanitized slapd.conf, a LDIF and a search operation based on > ldapsearch that clearly illustrates the issue, like what I posted a = couple > of postings ago. Here, the entire sanitized config. I left out the ACL file (the include = statement at the very end), but the behavior in question was happening = to the rootdn user as well, meaning ACLs weren't the culprit. I also = removed 14 of 15 of the syncrepl stanzas for brevity, as they were all = the same aside from hostname/IP. NOTE the sections labeled WORKS HERE, and BROKEN HERE, which denote the = original (dysfunctional) position vs the current (functional) position. ###### include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/misc.schema include /etc/ldap/schema/openldap.schema include /etc/ldap/schema/duaconf.schema include /etc/ldap/schema/dyngroup.schema include /etc/ldap/schema/ppolicy.schema include /etc/ldap/schema/sudo.schema include /etc/ldap/schema/dhcp.schema include /etc/ldap/schema/samba.schema include /usr/share/doc/libpam-ldap/ldapns.schema include /etc/ldap/schema/hdb.schema include /etc/ldap/schema/uber.schema include /etc/ldap/schema/nisdomainobject.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args tool-threads 4 loglevel stats stats2 sync ## Modules/Overlays modulepath /usr/lib/ldap moduleload back_hdb moduleload back_monitor.la moduleload syncprov moduleload accesslog moduleload dynlist.la serverID 100 ldap://10.94.100.100:3890/ TLSCertificateFile /etc/ldap/ssl/wildcard.example.com.crt TLSCertificateKeyFile /etc/ldap/ssl/wildcard.example.com.key TLSCACertificateFile /etc/ssl/certs/ca-example.cert TLSVerifyClient never ## Limits, Mandates & Allowances disallow bind_anon sizelimit unlimited timelimit unlimited security tls=3D0 access to dn.subtree=3D"cn=3DSubschema" by users read access to dn.base=3D"" by users read defaultSearchBase dc=3Dexample,dc=3Dcom sasl-realm EXAMPLE.COM sasl-host ds.example.com authz-regexp "uid=3D$.*$,cn=3DEXAMPLE.COM,cn=3Dgssapi,cn=3Dauth" "uid=3D$1,cn=3Dplain,cn=3Dauth,dc=3Dexample,dc=3Dcom" backend hdb ########### Monitoring Database - For slapd/hdb performance data database monitor rootdn uid=3Dmonitor,cn=3Dmonitor rootpw {SSHA}.... access to dn.subtree=3D"cn=3Dmonitor" by = group/groupOfUniqueNames/uniqueMember=3D"cn=3Dldapadmin,cn=3Dldap,cn=3Dgro= ups,dc=3Dexample,dc=3Dcom" read ########### Example Log database hdb suffix cn=3Dexamplelog rootdn "uid=3Dlog,cn=3Dexamplelog" rootpw {SSHA}.... directory /var/lib/ldap/examplelog index reqStart,objectClass,entryCSN,reqResult eq dbconfig set_cachesize 0 4097152 0 dbconfig set_lg_regionmax 1048576 dbconfig set_lg_max 1048576 dbconfig set_lg_dir /var/lib/ldap/examplelog dbconfig set_tmp_dir /tmp overlay syncprov syncprov-nopresent TRUE syncprov-reloadhint TRUE access to dn.subtree=3D"cn=3Dexamplelog" by = group/groupOfUniqueNames/uniqueMember=3D"cn=3Dldapadmin,cn=3Dldap,cn=3Dgro= ups,dc=3Dexample,dc=3Dcom" read ########### Example.Com database hdb idlcachesize 4000 suffix "dc=3Dexample,dc=3Dcom" checksum checkpoint 10 1 cachefree 20 rootdn "uid=3Drootdn,cn=3Dplain,cn=3Dauth,dc=3Dexample,dc= =3Dcom" rootpw {SSHA}.... monitoring on lastmod on directory "/var/lib/ldap/example" dncachesize 1000 dbconfig set_cachesize 1 0 2 dbconfig set_lg_max 10485760 dbconfig set_lg_regionmax 40485760 dbconfig set_flags db_log_autoremove dbconfig set_lg_bsize 20971520 dbconfig set_lk_max_objects 5500 dbconfig set_lk_max_locks 5500 dbconfig set_lk_max_lockers 5500 index objectClass eq =20 index entryCSN,entryUUID eq =20 index cn,uid,memberUid eq index uidNumber,gidNumber eq ############### ### WORKS HERE overlay dynlist dynlist-attrset groupOfURLs memberURL memberUid dynlist-attrset posixGroup memberURL memberUid:uid ## There were 15 of these, removed 14 for brevity. syncrepl rid=3D001 provider=3Dldap://10.94.100.100:3890/ starttls=3Dyes bindmethod=3Dsimple binddn=3D"uid=3Dsyncrepl,cn=3Dplain,cn=3Dauth,dc=3Dexample,dc=3Dcom" credentials=3Dpassword scope=3Dsub filter=3D"(objectClass=3D*)" schemachecking=3Doff searchbase=3D"dc=3Dexample,dc=3Dcom" attrs=3D"*,+" retry=3D"12 +" sizelimit=3Dunlimited timeout=3D20 type=3DrefreshAndPersist mirrormode true overlay syncprov syncprov-sessionlog 10 syncprov-checkpoint 1 5 overlay accesslog logdb cn=3Dexamplelog logops writes logold (objectclass=3D*) logpurge 7+00:00 2+00:00 logsuccess TRUE ################## ### IS BROKEN HERE overlay dynlist dynlist-attrset groupOfURLs memberURL memberUid dynlist-attrset posixGroup memberURL memberUid:uid include /etc/ldap/acls

1 0

Re: (ITS#6471) dynlist overlay only acknowledging last dynlist-attrset statement
by masarati＠aero.polimi.it 13 Feb '10

13 Feb '10

> Actually, maybe I wasn't totally wrong. There MAY be a bug at work, = > just not the one I initially thought .... > > 1.) Implemented your exact working example on my dev server. Worked. > 2.) Implemented same example on my QA server. Worked. > 3.) Implemented on a production server. Failed. > > I then realized the dynlist-attrset was listed as follows: > > syncrepl params > accesslog params > dynlist-attrset params > > I then moved the slapd.conf dynlist configuration lines ABOVE syncrepl = > lines (below my indexes for this DB). > > Example then worked in production. > > Is THAT a bug? That its behavior changes depending on where it is placed = > inside of a given 'database' section? > > Thanks, sorry to keep bugging you with this .... GUESSING what you meant above is something like this (as you keep writing things like "accesslog parameters" instead of the real thing) <slapd.conf excerpt> database bdb suffix "dc=example,dc=com" rootdn "cn=Manager,dc=example,dc=com" rootpw secret #null#bind on directory testrun/db.1.a index objectClass eq index cn,sn,uid pres,eq,sub overlay dynlist dynlist-attrset groupOfURLs memberURL memberUid overlay syncprov overlay accesslog logdb cn=log logops writes reads logold (objectclass=person) dynlist-attrset posixGroup memberURL memberUid:uid </slapd.conf excerpt> or any permutation of the dynlist-attrset statement, like both before overlay syncprov, or both at the end, or anywhere between "overlay syncrepl" and the last "log*" statement, I get the expected result. So now the only way to keep this ITS open is to see your ENTIRE slapd.conf (except passwords, of course). An even better alternative would be to receive a sanitized slapd.conf, a LDIF and a search operation based on ldapsearch that clearly illustrates the issue, like what I posted a couple of postings ago. p.

1 0

Re: (ITS#6471) dynlist overlay only acknowledging last dynlist-attrset statement
by masarati＠aero.polimi.it 13 Feb '10

13 Feb '10

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs February 2010