openldap-bugs

openldap-bugs@openldap.org

1 participants
20966 discussions

Re: (ITS#6830) slapo-ppolicy.5 has incorrect schema fragments
by andrew.findlay＠skills-1st.co.uk 30 Jun '11

30 Jun '11

On Thu, Jun 30, 2011 at 03:11:05AM -0700, Howard Chu wrote: > Well since you raise the question, what do you think is the more > sensible approach to all of this? I was the one who argued in > ldapext that these attributes should be no-user-modification but > perhaps that makes them too inconvenient to administer. I think that the best approach would be to make no change in 2.4 code but to flag in the docs that the behaviour will change for 2.5. The NO-USER-MODIFICATION flags have been in draft-behera since 2005, but draft-zeilenga-ldap-relax has only been around since 2007. The latter document says that rules may not be relaxed unless there is a document saying that they may be. pwdAccountLockedTime is not mentioned in draft-zeilenga-ldap-relax and the relax control is not mentioned in draft-behera-ldap-password-policy, so one of those docs needs updating to make the behaviour legal. It would be interesting to survey other LDAP implementations to see how they currently treat the password-policy attributes. This is already a minefield due to uncertainties and variations in the replication process. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

Re: (ITS#6830) slapo-ppolicy.5 has incorrect schema fragments
by hyc＠symas.com 30 Jun '11

30 Jun '11

Andrew Findlay wrote: > On Thu, Jun 09, 2011 at 01:45:17AM -0700, Howard Chu wrote: > >> I note that in ppolicy.c we have: >> >> { "( 1.3.6.1.4.1.42.2.27.8.1.17 " >> "NAME ( 'pwdAccountLockedTime' ) " >> "DESC 'The time an user account was locked' " >> "EQUALITY generalizedTimeMatch " >> "ORDERING generalizedTimeOrderingMatch " >> "SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 " >> "SINGLE-VALUE " >> #if 0 >> /* Not until Relax control is released */ >> "NO-USER-MODIFICATION " >> #endif >> "USAGE directoryOperation )", >> >> We have in fact released support for the Relax control, so it's >> probably time to unifdef these bits and go back to the documented >> behavior. > > That seems reasonable in the long term, though it will break many sites' > existing password management procedures. The change will have to be > mentioned in the updated manpage, noting the version at which it takes > effect. > > Should I produce an updated version of the manpage patch? Well since you raise the question, what do you think is the more sensible approach to all of this? I was the one who argued in ldapext that these attributes should be no-user-modification but perhaps that makes them too inconvenient to administer. -- -- 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#6981) slapd crashes when using sssvlv and pcache overlays
by ctcard＠hotmail.com 30 Jun '11

30 Jun '11

Full_Name: Chris Card Version: HEAD as of 28 Jun 2011 OS: centos 5.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (91.194.158.133) I am running slapd with pcache and sssvlv overlays and back-sql backend. With an empty cache, when I do a request like this: ldapsearch -h localhost -x -b "............" -D "............" -w ........ '(o=.....)' -E \!sss=mail:CaseIgnoreIA5Match slapd crashes in pcache_op_cleanup(), line 2369: /* check for malformed entries: attrs with no values */ { Attribute *a = rs->sr_entry->e_attrs; /* <-- HERE */ because rs->sr_entry is NULL. This appears to be because of the call to rs_flush_entry() in result.c line 1408 which sets rs->sr_entry to NULL prior to the call to pcache_op_cleanup(). The relevant part of my slapd.conf looks like this: database sql suffix "......" rootdn "......" rootpw ...... dbname MySQL dbuser ...... subtree_cond "ldap_entries.dn like CONCAT('%',?)" insentry_stmt "INSERT INTO ldap_entries (dn,oc_map_id,parent,keyval) VALUES (?,?,?,?)" has_ldapinfo_dn_ru no baseobject upper_func UPPER autocommit yes overlay pcache pcache bdb 10000 1 50 100 pcacheAttrset 0 * + pcacheTemplate (objectClass=) 0 60 pcacheTemplate (o=) 0 60 ... pcache-directory /var/tmp/cache pcache-cachesize 100 pcache-index objectClass eq,pres overlay sssvlv sssvlv-max 10 sssvlv-maxpercon 5

1 0

Re: (ITS#6830) slapo-ppolicy.5 has incorrect schema fragments
by andrew.findlay＠skills-1st.co.uk 30 Jun '11

30 Jun '11

On Thu, Jun 09, 2011 at 01:45:17AM -0700, Howard Chu wrote: > I note that in ppolicy.c we have: > > { "( 1.3.6.1.4.1.42.2.27.8.1.17 " > "NAME ( 'pwdAccountLockedTime' ) " > "DESC 'The time an user account was locked' " > "EQUALITY generalizedTimeMatch " > "ORDERING generalizedTimeOrderingMatch " > "SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 " > "SINGLE-VALUE " > #if 0 > /* Not until Relax control is released */ > "NO-USER-MODIFICATION " > #endif > "USAGE directoryOperation )", > > We have in fact released support for the Relax control, so it's > probably time to unifdef these bits and go back to the documented > behavior. That seems reasonable in the long term, though it will break many sites' existing password management procedures. The change will have to be mentioned in the updated manpage, noting the version at which it takes effect. Should I produce an updated version of the manpage patch? Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

(ITS#6980) Patch - Mozilla NSS - memleak - have to free the return from SSL_PeerCertificate
by rmeggins＠redhat.com 29 Jun '11

29 Jun '11

Full_Name: Rich Megginson Version: 2.4.25 (current CVS HEAD) OS: RHEL6 URL: ftp://ftp.openldap.org/incoming/openldap-2.4.25-moznss-free-return-of-SSL_P… Submission from: (NULL) (76.113.106.30) In tlsm_auth_cert_handler, we get the peer's cert from the socket using SSL_PeerCertificate. This value is allocated and/or cached. We must destroy it using CERT_DestroyCertificate. 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

Re: (ITS#6828) TLS fails to start when LDAP_OPT_CONNECT_ASYNC is used
by hyc＠symas.com 27 Jun '11

27 Jun '11

Ian Puleston wrote: > There is something missing from the fix. I just had a problem where an asynchronous connect was failing and the result was continuous looping with repeated calls to ldap_sasl_bind. > > The problem is that if the connect fails, ldap_int_poll called from ldap_int_check_async_open gets an error and returns -1, and then -1 is returned up the stack ldap_int_check_async_open -> ldap_send_initial_request -> ldap_sasl_bind. But when ldap_sasl_bind gets that -1 return from ldap_send_initial_request it returns ld->ld_errno, and nowhere have we set that. In fact, ld->ld_errno still contains LDAP_X_CONNECTING from when the initial connect was issued, and so ldap_sasl_bind returns LDAP_X_CONNECTING, and that is what leads to the infinite looping that I see. Thanks for the analysis and fix. Now patched in master. In the future please send actual diffs, as noted http://www.openldap.org/devel/contributing.html > What is missing is that in ldap_int_check_async_open this: > > default: > return -1; > > Should be changed to: > > default: > ld->ld_errno = LDAP_CONNECT_ERROR; > return -1; > > Ian -- -- 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#6828) TLS fails to start when LDAP_OPT_CONNECT_ASYNC is used
by ipuleston＠SonicWALL.com 27 Jun '11

27 Jun '11

There is something missing from the fix. I just had a problem where an asynchronous connect was failing and the result was continuous looping with repeated calls to ldap_sasl_bind. The problem is that if the connect fails, ldap_int_poll called from ldap_int_check_async_open gets an error and returns -1, and then -1 is returned up the stack ldap_int_check_async_open -> ldap_send_initial_request -> ldap_sasl_bind. But when ldap_sasl_bind gets that -1 return from ldap_send_initial_request it returns ld->ld_errno, and nowhere have we set that. In fact, ld->ld_errno still contains LDAP_X_CONNECTING from when the initial connect was issued, and so ldap_sasl_bind returns LDAP_X_CONNECTING, and that is what leads to the infinite looping that I see. What is missing is that in ldap_int_check_async_open this: default: return -1; Should be changed to: default: ld->ld_errno = LDAP_CONNECT_ERROR; return -1; Ian

1 0

Re: (ITS#6870) Undefined reference to ber_* with 2.4.24
by jvcelak＠redhat.com 27 Jun '11

27 Jun '11

LDIF functionality is included in libldif, but the interface is not provided (ldif.h is not installed by make install). This happens for RE24 branch, master branch is fine. Patch: ftp://ftp.openldap.org/incoming/jvcelak-20110627-export-ldif-h.patch Jan

1 0

RE: (ITS#6828) TLS fails to start when LDAP_OPT_CONNECT_ASYNC is used
by ipuleston＠SonicWALL.com 24 Jun '11

24 Jun '11

Thanks Howard. I pulled your change out of GIT and tested it, and it works fine for me. However, just as an FYI, this line in open.c results in a "suggest parentheses around && within ||" warning from gcc with the compiler options that we use to compile our OpenLDAP port, and that in turn results in a build failure (since we use -Werror): if (rc == 0 && ld->ld_options.ldo_tls_mode == LDAP_OPT_X_TLS_HARD || strcmp( srv->lud_scheme, "ldaps" ) == 0 ) The parentheses that I had in that line in my patch avoided that. Ian

1 0

Re: (ITS#6828) TLS fails to start when LDAP_OPT_CONNECT_ASYNC is used
by hyc＠symas.com 24 Jun '11

24 Jun '11

Ian Puleston wrote: >> -----Original Message----- >> From: Howard Chu [mailto:hyc@symas.com] >> Sent: Wednesday, June 08, 2011 5:47 PM >> >> I'm pretty sure that this chunk can never do anything useful. >> ... >> The connection has just been created, asynchronously, so there's no way >> that >> the TLS layer was already started when it got here. > > After re-reviewing it I think you are correct. I put that in because I thought there may be a chance that ldap_int_tls_start could get called from ldap_int_open_connection if the connect completed very quickly in the underlying layers. But even if it did there has been no call to ldap_int_poll to check for it having completed. ldap_pvt_connect and then ldap_connect_to_host return -2 to ldap_int_open_connection on an async connect. And the latter then only calls ldap_int_tls_start if rc == 0, so that call will not happen. > >> Also, I suggest that you only check for CONNST_CONNECTING in the >> callers, and do the TLS check in the check function > > Yes, good idea. I guess that the way I have it allows it to start up TLS immediately if using TLS and the connect completes immediately, but if not using TLS it will return LDAP_X_CONNECTING. What you are suggesting means that if not using TLS and the connect completes immediately then it will be able to go ahead and send the request rather than retuning LDAP_X_CONNECTING. > > I will update the fix and supply a new patch shortly. No need, I already committed a fix to git. It is also in RE24. > > Thanks > Ian > > > > > > > -- -- 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs