October 2011 - openldap-bugs

(ITS#7065) changeType: modify "replace/delete" trick causes segmentation fault in cn=config

by jeffreyc＠ucsc.edu

Full_Name: Jeffrey Crawford Version: 2.4.26 OS: FreeBSD 8.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (169.233.224.28) To guarantee the removal of an attribute when I don't know if the attribute exists already or not I often employ the following LDIF: ============== dn: cn=config changeType: modify replace: attrToDelete attrToDelete: dummy - delete: attrToDelete ============== Howver every time I run the above against cn=config it causes a segmentation fault. It does not cause any problems with a hdb backends. I like to set up ldifs that i can run generically without having to know if content is there or not so I do use this. I can work around it by just separating the above out into two "dn" instructions. but if for example one wanted to remove Indexes, that intermediate update might cause some process to start then abruptly stop or not stop. The above failure is consistant, so hopefully easy to find.

11 years, 11 months

1
0
0 / 0

(ITS#7064) moznss SEC_ERROR_BAD_SIGNATURE with a certificate trusted by OpenSSL

by massimo.gravino＠pd.infn.it

Full_Name: Massimo Gravino Version: 2.4.23-15 OS: Scientific Linux 6.1 URL: Submission from: (NULL) (192.84.143.111) We have an openldap server that uses LDAP over TLS/SSL and serves hundreds of clients. The CA used to sign the server certificate was created in 2005 with OpenSSL 0.9.7a. The CA self signed certificate and the server certificate have been used until now without any problem. In the server configuration (/etc/openldap/slapd.conf) we use TLSCertificateFile and TLSCertificateKeyFile to specify the path to the pem files of the certificate and private key of the server, and TLSCACertificateFile for the path to the pem file of the self signed certificate of the CA. In the client configuration (/etc/openldap/ldap.conf) we only define TLS_CACERT to specify the path to the pem file of the CA certificate. Now we are not able to use the the CA certificate on new Scientific Linux 6.1 clients with openldap 2.4.23-15: the problem appears with the standard openldap-2.4.23-15.el6 package that is compiled using MozNSS. If we recompile it using OpenSSL, the problem disappears (to recompile I simply edit the .spec file and omit -DHAVE_MOZNSS from the CFLAGS definition, change the --with-tls=no option to --with-tls=openssl and rebuild with rpmbuild -ba). This is the error obtained from the client with the original package when using ldapsearch: ldapsearch -x -d1 .... TLS: loaded CA certificate file /etc/openldap/cacerts/cacert.pem. TLS: certificate [CN=my.server.name,OU=Sezione di Padova,O=INFN,L=Padova,ST=Italia,C=IT] is not valid - error -8182:Unknown code ___f 10. TLS: error: connect - force handshake failure: errno 21 - moznss error -8182 TLS: can't connect: TLS error -8182:Unknown code ___f 10. ldap_err2string ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) The problem appears to be related to our particular CA, that uses a DSA key. I've never been able to reproduce the problem creating new CA with an rsa key; however if possible I'd not change the the CA that signes my server certificate, because in this case I should change the CA certificate on a lot of clients. Nor I would manually recompile every new version of openldap packages. So I collected all the steps necessary to reproduce this problem on Scientific linux 6.1 server and client, with openldap 2.4.23-15 and openssl 1.0.0-10, hoping that the problem will be considered a bug in MozNSS. Certification Authority creation -------------------------------- mkdir CA cd CA/ mkdir certs crl newcerts private touch index.txt echo "01" > serial edit /etc/pki/tls/openssl.cnf and change the dir definition in [ CA_default ] to point to the CA/ directory openssl dsaparam -out dsaparam.pem 2048 openssl req -new -x509 -keyout private/cakey.pem -out cacert.pem -newkey dsa:dsaparam.pem -days 5000 Server certificate creation and signing --------------------------------------- openssl req -new -keyout key.pem -out req.pem -newkey rsa:2048 -nodes openssl ca -policy policy_anything -out cert.pem -in req.pem Now copy cert.pem and key.pem on the server, and cacert.pem on the server and the client (may be the same machine) and change appropriately the values of TLSCertificateFile, TLSCertificateKeyFile and TLSCACertificateFile in the server configuration, and TLS_CACERT in the client configuration. Start the server with /usr/sbin/slapd -h ldaps:/// -u ldap -d 1 Then on the client use: ldapsearch -x -d1 On the server side you should see something like this: TLS: loaded CA certificate file /etc/openldap/cacerts/cacert.pem. TLS: certificate [E=admin(a)my.domain,CN=server.fqdn,OU=Sezione di Padova,O=INFN,L=Padova ,ST=Italia,C=IT] is valid TLS: error: accept - force handshake failure: errno 21 - moznss error -12271 TLS: can't accept: TLS error -12271:Unknown code ___P 17. connection_read(11): TLS accept failure error=-1 id=1000, closing connection_close: conn=1000 sd=11 And on the client side: TLS: loaded CA certificate file /etc/openldap/cacerts/cacert.pem. TLS: certificate [E=admin(a)my.domain,CN=server.fqdn,OU=Sezione di Padova,O=INFN,L=Padova,ST=Italia,C=IT] is not valid - error -8182:Unknown code ___f 10. TLS: error: connect - force handshake failure: errno 21 - moznss error -8182 TLS: can't connect: TLS error -8182:Unknown code ___f 10. ldap_err2string ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) Note that server says: certificate is valid but SSL peer cannot verify it (moznss error -12271: SSL_ERROR_BAD_CERT_ALERT) On the other side the client says: certificate is not valid because has an invalid signature (moznss error -8182: SEC_ERROR_BAD_SIGNATURE) As I said above, the problem disappears recompiling openldap with OpenSSL instead of MozNSS.

11 years, 11 months

1
0
0 / 0

Re: (ITS#6900) dnattr acl statement: users can produce dangling entries

by daniel＠pluta.biz

Hi Howard, as we've discussed during LDAPCon2011's get-together the following idea is currently not supported in slapd. For demonstration purposes I've introduced a <dnattrstyle> that only supports one style-descriptor called ".strict". It restricts "dnattr=..." ACL statements the way that self is not allowed to remove her own DN from dnattr. I've tested the patch with the following simple sample ACLs: to dn.base="ou=groups,dc=foo,dc=bar" attrs=children by users write to dn.onelevel="ou=groups,dc=foo,dc=bar" attrs=entry,@groupOfNames by dnattr.strict=owner write by users read According these two ACLs a group's owner is allowed to write the whole object (not only add, but also delete, aka in sum "write"). Nevertheless, because of the ".strict" the owner is not able to delete his own DN from the owner attribute. You can find an updated version of my patch here: ftp://ftp.openldap.org/incoming/Daniel-Pluta-111014.patch As it is still intended for demonstration purposes, the patch is highly probable suboptimal regarding its implementation, in particular regarding the chosen place within slapd's code. Instead of the <dnattrstyle> probably a new "<access>" called e.g. "writeToSelfButSelfNoDelete" or similar should be introduced instead. Unfortunately, I don't know how to code this correctly without changing/breaking the whole acl-engine and introducing various "funny" side-effects. Best regards Daniel P.S. Furthermore, and although I've no related scenario in mind, it perhaps could make sense to generalize this kind of behaviour also into direction to "writeToSelfButSelfNoAdd" etc. I'm not sure whether this would make sense, too.

11 years, 11 months

1
0
0 / 0

(ITS#7063) OpenLDAP don't provide some schema file in ldif format

by raphael.ouazana＠linagora.com

Full_Name: Raphael Ouazana Version: 2.4.26 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.41.232.151) Hi, Some schema files are missing from schema/ directory: collective.ldif corba.ldif duaconf.ldif java.ldif misc.ldif pmi.ldif ppolicy.ldif Regards, Raphaël Ouazana.

11 years, 11 months

1
0
0 / 0

(ITS#7062) writes from lost connections not increasing contextCSN

by ebackes＠symas.com

Full_Name: Emily Backes Version: 2.4.26 OS: any URL: Submission from: (NULL) (75.244.124.114) If a client connects and writes, e.g. ADDs entries, then disconnects before seeing the result, the writes are stored in the database but do not increment contextCSN. This can be seen without replicas being involved, but obviously still needs syncprov. $ ldapadd -x -D dc=example,dc=com -w secret -H ldap://localhost:1389/ -f people.ldif adding new entry "cn=1,ou=people,dc=example,dc=com" adding new entry "cn=2,ou=people,dc=example,dc=com" ... adding new entry "cn=22,ou=people,dc=example,dc=com" ^C $ ldapsearch -x -D dc=example,dc=com -w secret -H ldap://localhost:1389/ -b dc=example,dc=com -LLL '(cn=22)' entryCSN dn: cn=22,ou=people,dc=example,dc=com entryCSN: 20111011235653.469937Z#000000#001#000000 $ ldapsearch -x -D dc=example,dc=com -w secret -H ldap://localhost:1389/ -b dc=example,dc=com -LLL -s base contextCSN dn: dc=example,dc=com contextCSN: 20111011235653.380889Z#000000#001#000000 stats+sync log: conn=1000 op=21 ADD dn="cn=21,ou=people,dc=example,dc=com" slap_queue_csn: queing 0x105e00100 20111011235653.380889Z#000000#001#000000 conn=1000 op=21 RESULT tag=105 err=0 text= slap_graduate_commit_csn: removing 0x10178e0a0 20111011235653.380889Z#000000#001#000000 conn=1000 op=22 ADD dn="cn=22,ou=people,dc=example,dc=com" slap_queue_csn: queing 0x105e00100 20111011235653.469937Z#000000#001#000000 slap_graduate_commit_csn: removing 0x10178e520 20111011235653.469937Z#000000#001#000000 conn=1000 fd=10 closed (connection lost) The change isn't sent out to connected refreshAndPersist replicas either, and forcing them to reconnect doesn't help, as their contextCSNs still match across the board. This can cause persistent desynchronization of servers.

11 years, 11 months

1
0
0 / 0

Re: (ITS#6924) www.openldap.org and git.openldap.org serve different repositories

by ondra＠mistotebe.net

Note that openldap.git is not the only repository serving different history, e.g.: ---------------- 8< ---------------- $ git clone http://www.openldap.org/software/repo/openldap-jldap.git openldap-jldap.http $ cd openldap-jldap.http $ git log -1 commit 07fc2a4b6f20dfb3a171ee0fa4b66082358b8b53 Author: Nachiappan Palaniappan <npalani(a)openldap.org> Date: Mon Jul 6 08:43:38 2009 +0000 Updated version to 4.6. ---------------- 8< ---------------- Compare it to: ---------------- 8< ---------------- $ git clone git://git.openldap.org/openldap-jldap.git openldap-jldap.git $ cd openldap-jldap.git $ git log -1 commit bae9f556e97ad5bb0f76fe897c9b298a6021e244 Date: Mon Jul 6 08:43:38 2009 +0000 Updated version to 4.6. ---------------- 8< ---------------- Cheers, Ondrej Kuznik

11 years, 11 months

1
0
0 / 0

(ITS#7061) Only return requested attrs in sssvlv response

by ctcard＠hotmail.com

Full_Name: Chris Card Version: 2.4.26 + patch OS: Centos 5.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (91.194.158.133) There was a fix put into master on 18 Jul 2011 with subject "Only return requested attrs in sssvlv response" SHA: 8eecc9a017584ea0b56b25f0e4750e3b16929de6. I have patched openldap 2.4.26 with all the fixes to sssvlv.c, but there is still an issue with the attributes returned in an sssvlv response. On the first sssvlv request only the requested attributes are returned, but on subsequent sssvlv requests using the vlv context returned by the first requests, all the attributes are returned.

11 years, 11 months

1
0
0 / 0

(ITS#7060) Bad compare results with back-sock (and I suspect back-shell)

by maurice＠perry.ch

Full_Name: Maurice Perry Version: 2.4.26 OS: Linux (debian) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (160.53.250.126) The result code returned for the COMPARE operation with back-sock. The problem is due to a bug (two actually) in function str2result in servers/slapd/result.c: while ( isspace( (unsigned char) next[ 0 ] ) ) next++; if ( next[ 0 ] != '\0' ) { Debug( LDAP_DEBUG_ANY, "str2result (%s) extra cruft after value\n", s, 0, 0 ); rc = -1; continue; } /* FIXME: what if it's larger that max int? */ *code = (int)retcode; The code is not set properly if the code is not the last line of the result. I corrected the issue as follows: while ( isspace( (unsigned char) next[ 0 ] ) && next[ 0 ] != '\n' ) next++; if ( next[ 0 ] != '\0' && next[ 0 ] != '\n' ) { Debug( LDAP_DEBUG_ANY, "str2result (%s) extra cruft after value\n", s, 0, 0 ); rc = -1; continue; } /* FIXME: what if it's larger that max int? */ *code = (int)retcode;

11 years, 11 months

1
0
0 / 0

(ITS#7059) UTF8StringNormalize will overrun a zero-length value

by hyc＠OpenLDAP.org

Full_Name: Howard Chu Version: 2.4.x OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.94.188.8) Submitted by: hyc According to the commit history this bug has been present since 2003-04-07 (commit 67d6b23d). A patch is in git master, but I'm continuing to investigate and will update it further.

11 years, 11 months

1
0
0 / 0

Re: (ITS#6979) test062 portability

by richton＠nbcs.rutgers.edu

On Fri, 30 Sep 2011, Hallvard B Furuseth wrote: > I'm curious, what is this about - an observed bug, or not? There is > no function call here, 'wait' is checking a subprocess's exit status. > That's standard, and so is checking the return (not exit) status from > a function as far as I know, but I'm not surprised if some shells have > quirks. At the time I actually saw this on Solaris /bin/sh. I'll hopefully pull down a fresh copy and re-examine in a few days (I'm a bit backlogged at the moment trying to cram things in before I head to LDAPCon).

11 years, 11 months

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs October 2011