openldap-bugs June 2012

openldap-bugs@openldap.org

29 participants
84 discussions

(ITS#7316) [PATCH 5/5] MozNSS: do not retry when reading the pin from file
by jvcelak＠redhat.com 22 Jun '12

22 Jun '12

Full_Name: Jan Vcelak Version: git master OS: Linux URL: http://jvcelak.fedorapeople.org/openldap-patches/jvcelak-120622-0005-MozNSS… Submission from: (NULL) (209.132.186.34) If the password file contains invalid PIN for a certain token we should not retry the authentication, otherwise we can lock the token. Patch could not upload to OpenLDAP FTP server due to "No space left on device. Therefore I have uploaded the patch to fedorapeople.org. The patch is also available in 'moznss' branch of git://github.com/fcelda/openldap.git repository. The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Jan Vcelak am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

(ITS#7315) [PATCH 4/5] MozNSS: do not authenticate to a slot manually
by jvcelak＠redhat.com 22 Jun '12

22 Jun '12

Full_Name: Jan Vcelak Version: git master OS: Linux URL: http://jvcelak.fedorapeople.org/openldap-patches/jvcelak-120622-0004-MozNSS… Submission from: (NULL) (209.132.186.34) We cannot rely on the value of ctx->tc_certificate->slot because it might refer to a wrong slot when the certificate is loaded multiple times. This can happen in multi-threaded applications. Instead of authenticating to a slot implicitly, we can leave the decision on Mozilla NSS library, which will initiate authentication to a proper slot when needed. Patch could not upload to OpenLDAP FTP server due to "No space left on device. Therefore I have uploaded the patch to fedorapeople.org. The patch is also available in 'moznss' branch of git://github.com/fcelda/openldap.git repository. The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Jan Vcelak am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

(ITS#7314) [PATCH 3/5] MozNSS: lock whole init and clenaup process
by jvcelak＠redhat.com 22 Jun '12

22 Jun '12

Full_Name: Jan Vcelak Version: git master OS: Linux URL: http://jvcelak.fedorapeople.org/openldap-patches/jvcelak-120622-0003-MozNSS… Submission from: (NULL) (209.132.186.34) This patch changes the mutex locking during Mozilla NSS context initialization and shutdown. When multiple TLS contexts are created in multi-threaded application (like slapd with syncrepl), certificate, private key, or slot lookup errors appeared from time to time when other thread was loading the certificates. This patch makes the process safe as much as possible by protecting the whole context initialization and shutdown. Unfortunatelly, identifying the unsafe operations can be tricky with MozNSS. This patch should not cause any performance drawback, because the initialization is run just once per context. Patch could not upload to OpenLDAP FTP server due to "No space left on device. Therefore I have uploaded the patch to fedorapeople.org. The patch is also available in 'moznss' branch of git://github.com/fcelda/openldap.git repository. The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Jan Vcelak am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

(ITS#7313) [PATCH 2/5] MozNSS: store certificate object instead of nickname in ctx
by jvcelak＠redhat.com 22 Jun '12

22 Jun '12

Full_Name: Jan Vcelak Version: git master OS: Linux URL: http://jvcelak.fedorapeople.org/openldap-patches/jvcelak-120622-0002-MozNSS… Submission from: (NULL) (209.132.186.34) PEM certificates should not be referenced by nicknames, because the nicknames are derived from basename of the cerificate file and in general are not easy-predictable. The code of Mozilla NSS backend depends on some aspects of PEM module and tries to guess the nicknames correctly. In some cases the guessing is wrong. This patch changes this approach and the PEM certificates are no longer referenced by nicknames. DER value of the certificate is extracted when the PEM file is loaded into the database and this DER value is then used to retrieve the certificate object. When certificate database is used (not PEM), certificates are retrieved using nickname as before. The retrieved certificate objects (and associated private keys) are now stored directly in the tlsm_ctx structure and the nickname (certname) disappears. The changes are quite broad, but the code was simplified on many places. This approach was recommended by Mozilla NSS developers and was recently implemented for example in CURL. Patch could not upload to OpenLDAP FTP server due to "No space left on device. Therefore I have uploaded the patch to fedorapeople.org. The patch is also available in 'moznss' branch of git://github.com/fcelda/openldap.git repository. The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Jan Vcelak am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

(ITS#7312) [PATCH 1/5] MozNSS: context specific token description for certdb
by jvcelak＠redhat.com 22 Jun '12

22 Jun '12

Full_Name: Jan Vcelak Version: git master OS: Linux URL: http://jvcelak.fedorapeople.org/openldap-patches/jvcelak-120622-0001-MozNSS… Submission from: (NULL) (209.132.186.34) Prior to this patch, certificate lookup in Mozilla NSS certificate database by certificate nickname failed, if multiple certdbs were opened. This can happen in certain configurations of replication. Or when an application which links libldap, uses Mozilla NSS library as well. With this patch, all certdbs are opened explicitly with SECMOD_OpenUserDB() call. This allows us to specify a token description, which is later used as a prefix for the certificate nickname. The token description is unique for each TLS context created in OpenLDAP. Patch could not upload to OpenLDAP FTP server due to "No space left on device. Therefore I have uploaded the patch to fedorapeople.org. The patch is also available in 'moznss' branch of git://github.com/fcelda/openldap.git repository. The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Jan Vcelak am authorized by Red Hat, my employer, to release this work under the following terms. The attached modifications to OpenLDAP Software are subject to the following notice: Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#7311) Use JDBC-LDAP driver with Sybase Unwired Platform
by quanah＠zimbra.com 21 Jun '12

21 Jun '12

--On Thursday, June 21, 2012 10:31 AM +0000 iavdeev(a)nvg.ru wrote: > Full_Name: Igor G. Avdeev > Version: 2.4.21 > OS: Linux 2.6.32-41-server x86_64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (213.221.17.130) > > Could you help me create such a properties file for the jdbc-ldap driver? > This ITS system is for filing bug reports. If you have questions, then use the openldap-technical mailing list. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7311) Use JDBC-LDAP driver with Sybase Unwired Platform
by iavdeev＠nvg.ru 21 Jun '12

21 Jun '12

Full_Name: Igor G. Avdeev Version: 2.4.21 OS: Linux 2.6.32-41-server x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.221.17.130) Hello, I use the jdbc-ldap driver to connect to the OpenLDAP server with Sybase Unwired Platform. Sybase Unwired Platform to create the data source uses a properties file. Here is an example of such a file: #Instance Properties #Mon Jun 18 12:06:21 MSD 2012 driverClass=com.extendedsystems.jdbc.advantage.ADSDriver ant.project=default-jmsbridge databaseURL=jdbc\:extendedsystems\:advantage\://${serverName}\:${portNumber};catalog \= ${databaseName} Could you help me create such a properties file for the jdbc-ldap driver?

1 0

Re: (ITS#7168) [PATCH] Fix count constraint when using multiple modifications
by jsynacek＠redhat.com 18 Jun '12

18 Jun '12

On 06/07/2012 03:00 PM, Howard Chu wrote: > jsynacek(a)redhat.com wrote: >> Full_Name: Jan Synacek >> Version: 2.4.29 >> OS: Fedora 16 >> URL: http://jsynacek.fedorapeople.org/openldap/jsynacek-20120216-constraint-coun… >> Submission from: (NULL) (209.132.186.34) >> >> >> Constraint overlay doesn't take into account multiple modifications when using >> count. >> >> Example: If count for 'description' attribute is set e.g. to 2, the following >> results in a constraint violation: >> >> dn: cn=usr2, dc=my-domain,dc=com >> add: description >> description: d1 >> description: d2 >> description: d3-viol >> >> However, this passes: >> >> dn: cn=usr2, dc=my-domain,dc=com >> add: description >> description: d1 >> - >> add: description >> description: d2 >> - >> add: description >> description: d3 >> >> This patch fixes the behavior in case multiple modifications are used. >> >> Original bug report: https://bugzilla.redhat.com/show_bug.cgi?id=742163 >> >> The patch is uploaded on fedorapeople.org: >> http://jsynacek.fedorapeople.org/openldap/jsynacek-20120216-constraint-coun… >> >> I wasn't able to use ftp.openldap.org due to 'No space left' error. > > This code (and the original) don't seem to properly take deletes into account. It resets the ce counter to 0 on any delete op, but it should be decrementing based on the number of values provided. (And of course, it can only do that if the specified value is actually present in the attribute.) > I've updated the patch: http://jsynacek.fedorapeople.org/openldap/jsynacek-20120619-constraint-coun… Also, I've uploaded the tests I use: http://jsynacek.fedorapeople.org/openldap/constraint-count-tests.tar.bz2 -- Jan Synacek Software Engineer, BaseOS team Brno, Red Hat

1 0

Re: (ITS#7168) [PATCH] Fix count constraint when using multiple modifications
by jsynacek＠redhat.com 18 Jun '12

18 Jun '12

On 06/07/2012 03:00 PM, Howard Chu wrote: > jsynacek(a)redhat.com wrote: >> Full_Name: Jan Synacek >> Version: 2.4.29 >> OS: Fedora 16 >> URL: http://jsynacek.fedorapeople.org/openldap/jsynacek-20120216-constraint-coun… >> Submission from: (NULL) (209.132.186.34) >> >> >> Constraint overlay doesn't take into account multiple modifications when using >> count. >> >> Example: If count for 'description' attribute is set e.g. to 2, the following >> results in a constraint violation: >> >> dn: cn=usr2, dc=my-domain,dc=com >> add: description >> description: d1 >> description: d2 >> description: d3-viol >> >> However, this passes: >> >> dn: cn=usr2, dc=my-domain,dc=com >> add: description >> description: d1 >> - >> add: description >> description: d2 >> - >> add: description >> description: d3 >> >> This patch fixes the behavior in case multiple modifications are used. >> >> Original bug report: https://bugzilla.redhat.com/show_bug.cgi?id=742163 >> >> The patch is uploaded on fedorapeople.org: >> http://jsynacek.fedorapeople.org/openldap/jsynacek-20120216-constraint-coun… >> >> I wasn't able to use ftp.openldap.org due to 'No space left' error. > > This code (and the original) don't seem to properly take deletes into account. It resets the ce counter to 0 on any delete op, but it should be decrementing based on the number of values provided. (And of course, it can only do that if the specified value is actually present in the attribute.) I'll fix the patch. I tested only deletes with no additional values. -- Jan Synacek Software Engineer, BaseOS team Brno, Red Hat

1 0

Re: (ITS#7299) Memory leaks when using ldapmodify to add members to groupOfNames objectclass
by hyc＠symas.com 18 Jun '12

18 Jun '12

Jan Synacek wrote: > On 06/15/2012 03:16 PM, hyc(a)symas.com wrote: >> jsynacek(a)redhat.com wrote: >>> Full_Name: Jan Synacek >>> Version: git (c73ec15) >>> OS: linux-fedora17 >>> URL: http://jsynacek.fedorapeople.org/openldap/leak/openldap-mmr-leak.tar.gz >>> Submission from: (NULL) (209.132.186.34) >>> >>> >>> I'm using a 2-node mmr setup on my local machine - configuration files and >>> 'uploader' scripts are provided in the archive. >>> >>> 1) I have the two nodes running. >>> 2) Execute run.sh (only a wrapper for ldapusradm.sh) and start monitoring >>> slapd's memory usage. >>> 3) After some time (at about 2k users on my system), slapd consumes a large >>> amount of memory which is still growing >>> >>> Note that not using ldapmodify to add members to 'cn=users,dc=yes,dc=my', but >>> using it e.g. for modifying each user's email, does NOT result in any memory >>> leakage. >>> >>> I have also created a massif output using valgrind's massif tool: >>> http://jsynacek.fedorapeople.org/openldap/leak/massif.out.17906 >>> >>> I found a very similar bug (#7292), but I'm not sure if it's related. >> >> Running RE24 with valgrind --leak-check=full I see no leak when running your >> test. That should be the same as git c73ec15. No idea what leak you're seeing. >> > > The memory consumption still grows and slapd eventually gets killed by oom-killer. Perhaps you're seeing fragmentation in the glibc malloc library. Please test RE24, and try with some other malloc (e.g. tcmalloc). I've run your entire test with both valgrind and with tcmalloc's heap checker and neither one shows any leak. -- -- 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

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs June 2012