openldap-bugs January 2011

openldap-bugs@openldap.org

36 participants
177 discussions

Re: (ITS#6811) Patch - Mozilla NSS - disable pkcs11 fork checking for the software token
by hyc＠symas.com 29 Jan '11

29 Jan '11

rmeggins(a)redhat.com wrote: > Full_Name: Rich Megginson > Version: 2.4.23 (current CVS HEAD) > OS: RHEL6 > URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-moznss-disable-nofork-20110… > Submission from: (NULL) (76.113.111.209) > > > There are some applications that acquire a crypto context in the parent process > and expect that crypto context to work after a fork(). This does not work > with MozNSS using strict PKCS11 compliance mode. We set the environment > variable NSS_STRICT_NOFORK=DISABLED in tlsm_init() to tell the software > encryption module/token to allow crypto contexts to persist across a fork(). > However, if you are using some other module or encryption device that supports > and expects full PKCS11 semantics, the only recourse is to modify the > application to use atfork() handlers to save the crypto context in the parent > and restore (and SECMOD_RestartModules) the context in the child. Sounds like this is a followon to #6802. Is this really critical at this point? We really need to close the window on RE24 patches so we can actually cut a release. But if ITS#6802 is actually incomplete, I guess we should roll this in. > These patch files are 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, Rich Megginson 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. > -- -- 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#6814) back-ldap does not handle undefined objectClass values in search filters
by masarati＠aero.polimi.it 29 Jan '11

29 Jan '11

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2.40.14.92) Submitted by: ando A fix is coming. p.

1 0

(ITS#6813) Error in ldap_int_connect_cbs call from ldap_connect_to_host
by ipuleston＠sonicwall.com 28 Jan '11

28 Jan '11

Full_Name: Ian Puleston Version: 2.4.23 OS: VxWorks URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (67.115.118.5) In function ldap_connect_to_host are two calls to ldap_int_connect_cbs. The first for "#if defined( HAVE_GETADDRINFO ) && defined( HAVE_INET_NTOP )" looks OK, but the 2nd for the #else case of that is this: i = ldap_int_connect_cbs( ld, sb, &s, srv, (struct sockaddr *)&sin ); if ( i ) rc = i; else break; But this is inside a for loop that uses i as a counter for the loop control. ldap_int_connect_cbs returns an error code so, unless I'm missing something, setting i to that will break the loop control.

1 0

Re: (ITS#6812) Confused syncprov return codes
by hyc＠symas.com 28 Jan '11

28 Jan '11

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > syncprov_state_ctrl(), syncprov_done_ctrl(), syncprov_sendinfo() and > thus findpres_cb() can return either an LDAP result code, or a negative > number on BER error. I see no code which expects both classes of error > codes. The first functions's callers set rs->sr_err = return value. > At best I guess it'll be ignored or interpreted as LDAP_SERVER_DOWN. I've fixed the return codes. They still get ignored in a few places. -- -- 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#6711) Problems with ppolicy_forward_updates and starttls with certificate-based auth
by hyc＠symas.com 28 Jan '11

28 Jan '11

subbarao(a)computer.org wrote: > Full_Name: Kartik Subbarao > Version: 2.4.23 > OS: Debian Linux 5.0.5 > URL: ftp://ftp.openldap.org/incoming/kartik_subbarao.101116.tgz > Submission from: (NULL) (76.99.175.5) > > > I'm trying to get a consumer server to forward ppolicy-related updates to its > provider server, and to use certificate-based authentication (SASL EXTERNAL) > over STARTTLS when authenticating to the provider. > > I'm running into multiple problems here. The core problem seems to be that > enabling ppolicy_forward_updates breaks the chaining overlay such that it binds > anonymously instead of with SASL EXTERNAL. That's because your authz-regexp is wrong. You mapped "cn=localhost" but when using SASL EXTERNAL, the user's DN is the complete certificate DN. In your case, "cn=localhost,o=OpenLDAP,st=Some-State,c=US" The reason this didn't break replication is because in this test, everything has anonymous read access so the consumer was able to pull what it needed. > Another problem is that bind > operations to the consumer server start to return two result messages -- one > with the error code of the chained operation, and one with the error code of the > bind operation. I didn't get this far because your test certificate is now expired. I guess I can substitute some other certs and look at it again, but I think the core issue is your misconfigured authz-regexp. > To simplify reproducing the problem, I've worked with test022-ppolicy in the > openldap test framework. Here, I ran into another issue. I can't seem to be able > to configure sasl external/starttls chaining properly with the cn=config style > configuration that test022-ppolicy applies. The self-signed cert that I'm using > works fine with replication, but it doesn't seem to work with chaining. This may > or may not be another issue that needs to be resolved. > > In any case, with the attached files in the ITS, I hope that what I'm trying to > do and the results that I'm getting should be as clear as possible. Better to rename your scripts when you modify one of our existing ones. E.g. test999-xxxxxx and just create new data files instead of modifying ours. -- -- 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#6806) Invalid ldapadd crashes openldap with ndb backend
by anderson＠vailsys.com 28 Jan '11

28 Jan '11

The same behavior happens with 2.4.23, I initially noticed the problem with 2.4.23, built from source on ubuntu server, and then tried with the rebuilt 2.4.19 rpm on rhel. both die with a bus error message when ldapadd is run on the invalid ldif. Nathanael On Fri, 2011-01-28 at 10:55 -0800, Quanah Gibson-Mount wrote: > --On Thursday, January 27, 2011 3:28 PM +0000 anderson(a)vailsys.com wrote: > > > Full_Name: Nathanael Anderson > > Version: 2.4.19 > > OS: RHEL 6 (Linux) > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (74.63.156.11) > > > Please use a current version of OpenLDAP 2.4 prior to filing a bug report > to ensure the issue has not been fixed in a subsequent release. The > current release is 2.4.23. > > --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

Re: (ITS#6806) Invalid ldapadd crashes openldap with ndb backend
by quanah＠zimbra.com 28 Jan '11

28 Jan '11

--On Thursday, January 27, 2011 3:28 PM +0000 anderson(a)vailsys.com wrote: > Full_Name: Nathanael Anderson > Version: 2.4.19 > OS: RHEL 6 (Linux) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (74.63.156.11) Please use a current version of OpenLDAP 2.4 prior to filing a bug report to ensure the issue has not been fixed in a subsequent release. The current release is 2.4.23. --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#6812) Confused syncprov return codes
by h.b.furuseth＠usit.uio.no 28 Jan '11

28 Jan '11

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard syncprov_state_ctrl(), syncprov_done_ctrl(), syncprov_sendinfo() and thus findpres_cb() can return either an LDAP result code, or a negative number on BER error. I see no code which expects both classes of error codes. The first functions's callers set rs->sr_err = return value. At best I guess it'll be ignored or interpreted as LDAP_SERVER_DOWN.

1 0

Re: (ITS#6684) Patch for autogroup overlay
by moenoel＠informatik.uni-bremen.de 28 Jan '11

28 Jan '11

Am 27.01.2011 16:38, schrieb moenoel(a)informatik.uni-bremen.de: >> 1) it should simply be comparing the AttributeDescription pointers >> 2) since the "memberof" attribute is actually configurable in the memberof >> overlay, there's no guarantee that this is the correct attribute to be looking >> for. It should also be configurable in your patch. >> >> You're using strcasecmp, but your inputs are already normalized values. You >> should just use ber_bvcmp. >> > > Since I am also interested in this, I took some time to make a new > patch. I took Norberts original patch, applied it to a current checkout > from HEAD and tried to fix the issues mentioned by Howard. My initial > tests are looking good. > > My C skills are rather mediocre, though, so I hope I didn't slaughter > the thing :-) > > http://www.informatik.uni-bremen.de/~moenoel/ldap/christian-manal-autogroup… > > > Regards, > Christian Manal > > I just noticed that I messed up the copyright notice. I fixed that and replaced the archive, so the link is still valid.

1 0

(ITS#6811) Patch - Mozilla NSS - disable pkcs11 fork checking for the software token
by rmeggins＠redhat.com 28 Jan '11

28 Jan '11

Full_Name: Rich Megginson Version: 2.4.23 (current CVS HEAD) OS: RHEL6 URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-moznss-disable-nofork-20110… Submission from: (NULL) (76.113.111.209) There are some applications that acquire a crypto context in the parent process and expect that crypto context to work after a fork(). This does not work with MozNSS using strict PKCS11 compliance mode. We set the environment variable NSS_STRICT_NOFORK=DISABLED in tlsm_init() to tell the software encryption module/token to allow crypto contexts to persist across a fork(). However, if you are using some other module or encryption device that supports and expects full PKCS11 semantics, the only recourse is to modify the application to use atfork() handlers to save the crypto context in the parent and restore (and SECMOD_RestartModules) the context in the child. These patch files are 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, Rich Megginson 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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs January 2011