openldap-bugs August 2013

openldap-bugs@openldap.org

23 participants
68 discussions

RE: (ITS#7673) rwm and bad ACL evaluation
by Russell.Mosemann＠cune.edu 31 Aug '13

31 Aug '13

Further testing confirms that the filter for the ACL is not being applied correctly when rwm is used. Turning the rewriteEngine off has no effect. All lines referring to rwm must be commented. Interestingly, performing the query without specifying any attribute succeeds. All allowed attributes are returned. ldapsearch -D "qmailGID=306,ou=accounts,o=cune" -w password \ -E 2.16.840.1.113730.3.4.2 -b "ou=accounts,o=cune" "(uid=Test.Entry)" # extended LDIF # # LDAPv3 # base <ou=accounts,o=cune> with scope subtree # filter: (uid=Test.Entry) # requesting: ALL # # 2, accounts, cune dn: qmailUID=2,ou=accounts,o=cune objectClass: pilotPerson objectClass: qmailUser objectClass: PureFTPdUser cn: Test Entry sn: Entry uid: Test.Entry accountStatus: active mail: test.entry(a)cune.org userClass: stu # search result search: 2 result: 0 Success Specifying an allowed attribute or no attributes (1.1) causes the query to fail. For example, ldapsearch -D "qmailGID=306,ou=accounts,o=cune" -w password \ -E 2.16.840.1.113730.3.4.2 -b "ou=accounts,o=cune" "(uid=Test.Entry)" cn ldapsearch -D "qmailGID=306,ou=accounts,o=cune" -w password \ -E 2.16.840.1.113730.3.4.2 -b "ou=accounts,o=cune" "(uid=Test.Entry)" 1.1 # extended LDIF # # LDAPv3 # base <ou=accounts,o=cune> with scope subtree # filter: (uid=Test.Entry) # requesting: cn # # search result search: 2 result: 32 No such object # numResponses: 1 Removing the filter from the ACL allows the query to succeed. access to dn.subtree="ou=accounts,o=cune" attrs=cn,entry,mail,objectClass,sn,uid,userClass,accountStatus by dn="qmailGID=306,ou=accounts,o=cune" read by peername.ip=127.0.0.0%255.255.255.0 read by peername.ip=10.0.0.0%255.255.192.0 read by * none In summary, slapd is unable to apply the filter for an ACL correctly when rwm is being used and an attribute (or no attributes) is specified with the query.

1 0

Re: (ITS#7676) OpenLDAP 2.4.36 slapd crash with "assertion failed" message
by hyc＠symas.com 30 Aug '13

30 Aug '13

frederic.poisson(a)admin.gmessaging.net wrote: > Full_Name: Frederic POISSON > Version: 2.4.36 > OS: RHEL 6.2 > URL: ftp://ftp.openldap.org/incoming/slapcat_cn_config.ldif ftp://ftp.openldap.org/incoming/slapd_debug_255.txt ftp://ftp.openldap.org/incoming/gdb_output.txt > Submission from: (NULL) (57.250.229.136) Thanks for the report, this is now fixed in git master. > > I'm testing the latest release of OpenLDAP 2.4.36 and my slapd crash while i'm > doing a change on cn=config. > My tests are with my own compilation of OpenLDAP on a RHEL6 server but i see the > same problem with "LTB project RPMs" > http://ltb-project.org/wiki/download#openldap with RHEL6 package. > My aim is to modify cn=config like this in order to implement TLS, here is my > ldap modify command with ldif : > # /usr/local/openldap/bin/ldapmodify -f /tmp/ldif -h "localhost" -p "25389" -D > "cn=root DN,cn=config" -w "secret" > modifying entry "cn=config" > ldap_result: Can't contact LDAP server (-1) > > # cat /tmp/ldif > dn: cn=config > changetype: modify > add: olcTLSRandFile > olcTLSRandFile: /dev/random > > The server shutdown when i add this entry and with slapd option "-d 255" i have > : > slapd: result.c:813: slap_send_ldap_result: Assertion `!((rs->sr_err)<0)' > failed. > /etc/init.d/slapd: line 285: 5461 Aborted $SLAPD_BIN -h > "$SLAPD_SERVICES" $SLAPD_PARAMS > > Notice that i test this ldif modification on release 2.4.35 without problem. > > I put on your ftp three files, the file slapcat_cn_config.ldif corresponding to > configuration, the file slapd_debug_255.txt which correspond to the slapd > process with debug set to 255 with only the part corresponding to the moment i > launch ldapmodify action, the file gdb_output.txt corresponding to the full > backtrace i run when doing the ldapmodify action. > > And so the credentials are "cn=root DN,cn=config" with password secret. > > -- -- 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#7677) slapd crashes when modifying cn=config
by hyc＠symas.com 30 Aug '13

30 Aug '13

grimeton(a)gmx.net wrote: > Full_Name: Oliver Loch > Version: 2.4.36 > OS: Ubuntu 13.04 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (88.134.35.240) > > > Hi, > > when chaning TLS related configuration in cn=config, slapd crashes. > It looks pretty similar to ITS#7676. Yes, now fixed in master. Closing this as a dup of #7676. > > If you have questions, feel free to contact me. > > KR, > > Oliver > > -- -- 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#7677) slapd crashes when modifying cn=config
by grimeton＠gmx.net 30 Aug '13

30 Aug '13

Full_Name: Oliver Loch Version: 2.4.36 OS: Ubuntu 13.04 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.134.35.240) Hi, when chaning TLS related configuration in cn=config, slapd crashes. The slapd version 2.4.36 I'm using are packages that I built on my own with the help of the original Debian (!) source packages for 2.4.35. Even if the source packages come from Debian, they have been built on Ubuntu 13.04 and are used on Ubuntu 13.04. There are no "binary parts" of Debian involved in any way. If you want the source packages, just let me know. I kicked a lot of patches including the GNUTLS stuff and linked against OpenSSL. # ldd $(which slapd) linux-vdso.so.1 => (0x00007fffeddfe000) libldap_r-2.4.so.2 => /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 (0x00007f0a66da9000) liblber-2.4.so.2 => /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2 (0x00007f0a66b9b000) libslp.so.1 => /usr/lib/libslp.so.1 (0x00007f0a66988000) libsasl2.so.2 => /usr/lib/x86_64-linux-gnu/libsasl2.so.2 (0x00007f0a6676d000) libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007f0a66534000) libslapi-2.4.so.2 => /usr/lib/x86_64-linux-gnu/libslapi-2.4.so.2 (0x00007f0a66315000) libltdl.so.7 => /usr/lib/x86_64-linux-gnu/libltdl.so.7 (0x00007f0a6610b000) libwrap.so.0 => /lib/x86_64-linux-gnu/libwrap.so.0 (0x00007f0a65f01000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f0a65ce3000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f0a6591b000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f0a65701000) libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007f0a654a3000) libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007f0a650c8000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f0a64ec4000) libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x00007f0a64ca9000) /lib64/ld-linux-x86-64.so.2 (0x00007f0a6738c000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f0a64a92000) # I'm able to change any of the olcTLS* attributes in cn=config and only "olcTLSCACertificateFile" crashes slapd. When adding, the data is written to the cn=config backend and stored there (data available after a restart), when deleting, slapd crashes before the data has been written back. The LDIF file looks like this: ===== SNIP ===== 8< ======== dn: cn=config changetype: modify add: olcTLSCACertificateFile olcTLSCACertificateFile: /etc/ssl/certs/some.cert.pem - add: olcTLSCertificateFile olcTLSCertificateFile: /etc/ssl/private/cert.server.pem - add: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/ssl/private/key.server.pem - add: olcTLSDHParamFile olcTLSDHParamFile: /etc/ssl/private/system.dhparam - add: olcTLSVerifyClient olcTLSVerifyClient: allow - add: olcTLSCRLCheck olcTLSCRLCheck: all - add: olcTLSCRLFile olcTLSCRLFile: /etc/ssl/certs/somecrl.crl.pem - ======= >8 ======= SNAP ======== The files do all exist and can be accessed by slapd. The error message before slapd core dumps: slapd: ../../../../servers/slapd/result.c:813: slap_send_ldap_result: Assertion `!((rs->sr_err)<0)' failed. Aborted (core dumped) It looks pretty similar to ITS#7676. If you have questions, feel free to contact me. KR, Oliver

1 0

(ITS#7676) OpenLDAP 2.4.36 slapd crash with "assertion failed" message
by frederic.poisson＠admin.gmessaging.net 30 Aug '13

30 Aug '13

Full_Name: Frederic POISSON Version: 2.4.36 OS: RHEL 6.2 URL: ftp://ftp.openldap.org/incoming/slapcat_cn_config.ldif ftp://ftp.openldap.org/incoming/slapd_debug_255.txt ftp://ftp.openldap.org/incoming/gdb_output.txt Submission from: (NULL) (57.250.229.136) I'm testing the latest release of OpenLDAP 2.4.36 and my slapd crash while i'm doing a change on cn=config. My tests are with my own compilation of OpenLDAP on a RHEL6 server but i see the same problem with "LTB project RPMs" http://ltb-project.org/wiki/download#openldap with RHEL6 package. My aim is to modify cn=config like this in order to implement TLS, here is my ldap modify command with ldif : # /usr/local/openldap/bin/ldapmodify -f /tmp/ldif -h "localhost" -p "25389" -D "cn=root DN,cn=config" -w "secret" modifying entry "cn=config" ldap_result: Can't contact LDAP server (-1) # cat /tmp/ldif dn: cn=config changetype: modify add: olcTLSRandFile olcTLSRandFile: /dev/random The server shutdown when i add this entry and with slapd option "-d 255" i have : slapd: result.c:813: slap_send_ldap_result: Assertion `!((rs->sr_err)<0)' failed. /etc/init.d/slapd: line 285: 5461 Aborted $SLAPD_BIN -h "$SLAPD_SERVICES" $SLAPD_PARAMS Notice that i test this ldif modification on release 2.4.35 without problem. I put on your ftp three files, the file slapcat_cn_config.ldif corresponding to configuration, the file slapd_debug_255.txt which correspond to the slapd process with debug set to 255 with only the part corresponding to the moment i launch ldapmodify action, the file gdb_output.txt corresponding to the full backtrace i run when doing the ldapmodify action. And so the credentials are "cn=root DN,cn=config" with password secret.

1 0

Re: (ITS#7675) Crash on mtestx.exe
by hyc＠symas.com 28 Aug '13

28 Aug '13

tghill(a)hotmail.com wrote: > Full_Name: TG Hill > Version: LMDB_0.9.7 > OS: Windows 7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (216.211.58.121) > > > I frequently (but not always) get a crash when I run mtest(x).exe. It always > works after I delete data.mdb. It's normal. None of the test programs do any error checking, and they are not meant to be run. They are meant to be single-stepped under a debugger, and a developer is meant to examine the result of each call, manually. If you're not an LMDB developer you should just ignore these. Closing this ITS. > > The line causing the crash is listed below. > > rc = mdb_txn_begin(env, NULL, 0, &txn); > > > The binary was compiled using mingw gcc 4.6.2. > > I modified the makefile to use -lpthread or -mthreads so it would compile. Both > versions would periodically crash. > > Any ideas? > > Thanks! > > -- -- 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#7675) Crash on mtestx.exe
by tghill＠hotmail.com 28 Aug '13

28 Aug '13

Full_Name: TG Hill Version: LMDB_0.9.7 OS: Windows 7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (216.211.58.121) I frequently (but not always) get a crash when I run mtest(x).exe. It always works after I delete data.mdb. The line causing the crash is listed below. rc = mdb_txn_begin(env, NULL, 0, &txn); The binary was compiled using mingw gcc 4.6.2. I modified the makefile to use -lpthread or -mthreads so it would compile. Both versions would periodically crash. Any ideas? Thanks!

1 0

Re: (ITS#7674) Configure Mirror Mode Replication
by quanah＠zimbra.com 27 Aug '13

27 Aug '13

--On Tuesday, August 27, 2013 11:19 PM +0000 cpetty(a)luthresearch.com wrote: > Full_Name: Clint Petty > Version: 2.4.23 > OS: CentOS 6.4 The ITS system is for bug reports. Help requests such as this should be sent to openldap-technical(a)openldap.org I would note the release you are using is ancient, and it is well known that the build from RedHat/CentOS has numerous problems and is quite broken. You would be best served to build a current release of OpenLDAP yourself, or grab the package from <http://ltb-project.org/wiki/download#openldap> for OpenLDAP 2.4.36. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Lead Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7674) Configure Mirror Mode Replication
by cpetty＠luthresearch.com 27 Aug '13

27 Aug '13

Full_Name: Clint Petty Version: 2.4.23 OS: CentOS 6.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (65.44.192.153) I am wanting to implement Mirror Mode Replication. I am using OpenLDAP 2.4.23 which uses cn=config format, that does not have a slapd.conf file. The instructions say to add the following to the slapd.conf file: database bdb suffix dc=Example,dc=com rootdn dc=Example,dc=com directory /var/ldap/db index objectclass,entryCSN,entryUUID eq overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 MirrorMode node 1: # Global section serverID 1 # database section # syncrepl directive syncrepl rid=001 provider=ldap://ldap-sid2.example.com bindmethod=simple binddn="cn=mirrormode,dc=example,dc=com" credentials=mirrormode searchbase="dc=example,dc=com" schemachecking=on type=refreshAndPersist retry="60 +" mirrormode on MirrorMode node 2: # Global section serverID 2 # database section # syncrepl directive syncrepl rid=001 provider=ldap://ldap-sid1.example.com bindmethod=simple binddn="cn=mirrormode,dc=example,dc=com" credentials=mirrormode searchbase="dc=example,dc=com" schemachecking=on type=refreshAndPersist retry="60 +" mirrormode on Since there is no slapd.conf file, how do I configure replication in a cn=config format? Do I need to run a slapadd or ldapadd command? Syntax? What files do I need to create, and where? Thanks in advance.

1 0

(ITS#7673) rwm and bad ACL evaluation
by Russell.Mosemann＠cune.edu 27 Aug '13

27 Aug '13

Full_Name: Russell Mosemann Version: 2.4.36 OS: Debian 6 and 7 URL: Submission from: (NULL) (192.160.64.50) Including rwm directives causes ACL evaluation to be incorrectly performed. rwm plays no role in rewriting any part of the incoming query or outgoing results. Simply commenting the rwm lines without making any other configuration changes permits the query to succeed. The query is coming from an authenticated entry that is allowed to search the subtree. # rwm configuration - Commenting the follow lines allows the query to succeed. overlay rwm rwm-rewriteEngine on rwm-rewriteMap slapd flt2dn "ldap:///ou=accounts,o=cune?dn?sub" rwm-rewriteContext bindDN rwm-rewriteRule "^(mail=[a-z0-9-]+\\.[a-z0-9-]+(a)cune\\.org),ou=People,o=cune$" "${flt2dn((\&($1)(accountStatus=active)(userClass=stu)))}" ":@I" # There are only 4 ACLs. # Allow authentication access to dn.subtree="ou=accounts,o=cune" attrs=userPassword by self write by peername.ip=127.0.0.0%255.255.255.0 search by peername.ip=10.0.0.0%255.255.192.0 search by anonymous auth # Allow reading of certain attributes. access to dn.subtree="ou=accounts,o=cune" filter=(&(userClass=stu)(accountStatus=active)) attrs=cn,entry,mail,objectClass,sn,uid,userClass,accountStatus by dn="qmailGID=306,ou=accounts,o=cune" read by peername.ip=127.0.0.0%255.255.255.0 read by peername.ip=10.0.0.0%255.255.192.0 read by * none # Search access to the base is required to search children. access to dn.base="ou=accounts,o=cune" by dn="qmailGID=306,ou=accounts,o=cune" search by peername.ip=127.0.0.0%255.255.255.0 read by peername.ip=10.0.0.0%255.255.192.0 read by * none # No access to other parts. access to dn.subtree="o=cune" by dn="qmailGID=306,ou=accounts,o=cune" none by peername.ip=127.0.0.0%255.255.255.0 read by peername.ip=10.0.0.0%255.255.192.0 read by * none The query is from the authenticated entry "qmailGID=306,ou=accounts,o=cune" searching the base "ou=accounts,o=cune" with the filter "(uid=Test.Entry)". This is the debugging output when the rwm lines above are commented. The query succeeds. 521cdb75 => send_search_entry: conn 1001 dn="qmailUID=2,ou=accounts,o=cune" 521cdb75 => access_allowed: read access to "qmailUID=2,ou=accounts,o=cune" "entry" requested 521cdb75 => dn: [1] ou=accounts,o=cune 521cdb75 => acl_get: [1] matched 521cdb75 => dn: [2] ou=accounts,o=cune 521cdb75 => acl_get: [2] matched 521cdb75 => test_filter 521cdb75 AND 521cdb75 => test_filter_and 521cdb75 => test_filter 521cdb75 EQUALITY 521cdb75 => access_allowed: search access to "qmailUID=2,ou=accounts,o=cune" "userClass" requested 521cdb75 <= test_filter 6 521cdb75 => test_filter 521cdb75 EQUALITY 521cdb75 => access_allowed: search access to "qmailUID=2,ou=accounts,o=cune" "accountStatus" requested 521cdb75 <= test_filter 6 521cdb75 <= test_filter_and 6 521cdb75 <= test_filter 6 521cdb75 => acl_get: [2] attr entry 521cdb75 => acl_mask: access to entry "qmailUID=2,ou=accounts,o=cune", attr "entry" requested 521cdb75 => acl_mask: to all values by "qmailGID=306,ou=accounts,o=cune", (=0) 521cdb75 <= check a_dn_pat: qmailGID=306,ou=accounts,o=cune 521cdb75 <= acl_mask: [1] applying read(=rscxd) (stop) 521cdb75 <= acl_mask: [1] mask: read(=rscxd) 521cdb75 => slap_access_allowed: read access granted by read(=rscxd) 521cdb75 => access_allowed: read access granted by read(=rscxd) ber_flush2: 40 bytes to sd 22 0000: 30 26 02 01 02 64 21 04 1d 71 6d 61 69 6c 55 49 0&...d!..qmailUI 0010: 44 3d 32 2c 6f 75 3d 61 63 63 6f 75 6e 74 73 2c D=2,ou=accounts, 0020: 6f 3d 63 75 6e 65 30 00 o=cune0. ldap_write: want=40, written=40 0000: 30 26 02 01 02 64 21 04 1d 71 6d 61 69 6c 55 49 0&...d!..qmailUI 0010: 44 3d 32 2c 6f 75 3d 61 63 63 6f 75 6e 74 73 2c D=2,ou=accounts, 0020: 6f 3d 63 75 6e 65 30 00 o=cune0. 521cdb75 <= send_search_entry: conn 1001 exit. 521cdb75 send_ldap_result: conn=1001 op=1 p=3 521cdb75 send_ldap_result: err=0 matched="" text="" 521cdb75 send_ldap_response: msgid=2 tag=101 err=0 This is the debugging output after uncommenting the rwm lines and making no other configuration changes. Search access allowed in the second ACL is not found, and it proceeds to the fourth ACL where all access is denied. 521cdd96 => send_search_entry: conn 1004 dn="qmailUID=2,ou=accounts,o=cune" 521cdd96 => access_allowed: read access to "qmailUID=2,ou=accounts,o=cune" "entry" requested 521cdd96 => dn: [1] ou=accounts,o=cune 521cdd96 => acl_get: [1] matched 521cdd96 => dn: [2] ou=accounts,o=cune 521cdd96 => acl_get: [2] matched 521cdd96 => test_filter 521cdd96 AND 521cdd96 => test_filter_and 521cdd96 => test_filter 521cdd96 EQUALITY 521cdd96 => access_allowed: search access to "qmailUID=2,ou=accounts,o=cune" "userClass" requested 521cdd96 <= test_filter 5 521cdd96 <= test_filter_and 5 521cdd96 <= test_filter 5 521cdd96 => dn: [3] ou=accounts,o=cune 521cdd96 => dn: [4] o=cune 521cdd96 => acl_get: [4] matched 521cdd96 => acl_get: [4] attr entry 521cdd96 => acl_mask: access to entry "qmailUID=2,ou=accounts,o=cune", attr "entry" requested 521cdd96 => acl_mask: to all values by "qmailGID=306,ou=accounts,o=cune", (=0) 521cdd96 <= check a_dn_pat: qmailGID=306,ou=accounts,o=cune 521cdd96 <= acl_mask: [1] applying none(=0) (stop) 521cdd96 <= acl_mask: [1] mask: none(=0) 521cdd96 => slap_access_allowed: read access denied by none(=0) 521cdd96 => access_allowed: no more rules 521cdd96 send_search_entry: conn 1004 access to entry (qmailUID=2,ou=accounts,o=cune) not allowed 521cdd96 send_ldap_result: conn=1004 op=1 p=3 521cdd96 send_ldap_result: err=0 matched="" text="" 521cdd96 send_ldap_response: msgid=2 tag=101 err=0 There is nothing special about the LDAP entry for Test.Entry. dn: qmailUID=2,ou=accounts,o=cune objectClass: pilotPerson objectClass: qmailUser objectClass: PureFTPdUser cn: Test Entry sn: Entry uid: Test.Entry qmailUID: 2 accountStatus: active mail: test.entry(a)cune.org userClass: stu Please let me know if you require any other information. Thank you. Russell Mosemann

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs August 2013