openldap-bugs

openldap-bugs@openldap.org

1 participants
21000 discussions

Start a nNew thread

ITS#6886
by masarati＠aero.polimi.it 30 Jun '11

30 Jun '11

(should be) fixed in master, please test. p.

1 0

ITS#6873
by masarati＠aero.polimi.it 30 Jun '11

30 Jun '11

Fixed in master, please test. p.

1 0

Re: (ITS#6925) [PATCH] Use inet_ntop for server when available
by Pierangelo Masarati 30 Jun '11

30 Jun '11

Please provide patch as a file, not embedded in email. Upload instructions here <http://www.openldap.org/devel/contributing.html#submitting>. p.

1 0

"database monitor" documentation
by Dan Pritts 30 Jun '11

30 Jun '11

Hi, Looking for docs for the monitor datbase backend, i found this: http://www.openldap.org/devel/admin/monitoringslapd.html Like most other database backends, the monitor backend does honor slapd(8) access and other administrative controls. As some monitor information may be sensitive, it is generally recommend access to cn=monitor be restricted to directory administrators and their monitoring agents. Adding an access directive immediately below the database monitor directive is a clear and effective approach for controlling access. For instance, the addition of the following access directive immediately below the database monitor directive restricts access to monitoring information to the specified directory manager. access to * by dn.exact="cn=Manager,dc=example,dc=com by * none I have misunderstood acl and database config before, but I assume that the ACL here is in error, and something like this from slapd-monitor(5) is appropriate: access to dn.subtree="cn=Monitor" by dn.exact="uid=Admin,dc=my,dc=org" write by users read by * none Assuming I'm correct please update the web docs & let me know. thanks! danno -- Dan Pritts, Sr. Systems Engineer Internet2 office: +1-734-352-4953 | mobile: +1-734-834-7224

2 1

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

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