openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

(ITS#5557) memory leak in ACL sets
by hyc＠OpenLDAP.org 13 Jun '08

13 Jun '08

Full_Name: Howard Chu Version: 2.3.39/2.4/HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Submitted by: hyc slap_set_join() with an '|' operator will leak values if it detects a duplicate in the rset. A fix will be committed shortly.

1 0

(ITS#5556) ldapadd/slapadd create objects without RDN
by joshua＠itsecureadmin.com 13 Jun '08

13 Jun '08

Full_Name: Josh Miller Version: 2.4.10 OS: CentOS 5.1 URL: http://itsecureadmin.com/uid-test.txt Submission from: (NULL) (65.249.25.3) When adding an object with slapadd or ldapadd, it is possible to create an object which does not have an RDN, and therefore not searchable by RDN. Example data: dn: uid=nouiduser,ou=People,dc=openldap,dc=example,dc=com objectClass: mailAccount maildrop: nouiduser(a)nest.tld mailid: nouiduser(a)nest.tld maildir: nouiduser/ userPassword:: e2NyeXB0fSQxJERCQS5wdmZYJHU0eFp3TndSRDIwSDFkTDBrNmZMRi4= mailquota: 35969216S The above LDIF is added to the directory without any errors and is then missing the uid attribute. ldapsearch will not return any results when filtering on uid, ie: $ ldapsearch -xZZH ldap://server uid=nouiduser - Expected result - return the object. - Actual result - no object returned. - Workaround - use ldapmodify to add the uid attribute. Please see the attached URL for complete event details (add/search/modify).

1 0

(ITS#5555) authzTo ACL check for wrong principal
by andrew.findlay＠skills-1st.co.uk 13 Jun '08

13 Jun '08

Full_Name: Andrew Findlay Version: 2.4.10 OS: Linux: SuSE 10.2 URL: Submission from: (NULL) (88.97.25.132) When using "authz-policy to" I find that the entity that is trying to do an operation on behalf of another entity needs read access to its own authzTo attribute. This seems wrong: authzTo is defining what the user may do: I do not really want them to be able to see it. When doing a proxy authz I think ACLs for this attribute should not be checked at all as the access is effectively being done by the rootdn.

1 0

Re: (ITS#5554) slapd.conf man page missing TLSCipherSuite
by ghenry＠OpenLDAP.org 12 Jun '08

12 Jun '08

<quote who="Howard Chu"> > ghenry(a)OpenLDAP.org wrote: >> Full_Name: Gavin Henry >> Version: HEAD >> OS: >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (212.159.59.85) >> >> >> http://www.openldap.org/software/man.cgi?query=slapd.conf&sektion=5&apropos… >> missing TLSCipherSuite >> >> > No. The Admin Guide is missing the note about GnuTLS under the > TLSCipherSuite > description. The note is present in slapd.conf(5). I don't knwo what I was thinking when I wrote that, but I did mean what you've just wrote. Weird.

1 0

Re: (ITS#5554) slapd.conf man page missing TLSCipherSuite
by hyc＠symas.com 12 Jun '08

12 Jun '08

ghenry(a)OpenLDAP.org wrote: > Full_Name: Gavin Henry > Version: HEAD > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.159.59.85) > > > http://www.openldap.org/software/man.cgi?query=slapd.conf&sektion=5&apropos… > missing TLSCipherSuite > > > No. The Admin Guide is missing the note about GnuTLS under the TLSCipherSuite description. The note is present in slapd.conf(5). -- -- 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#5554) slapd.conf man page missing TLSCipherSuite
by ghenry＠OpenLDAP.org 12 Jun '08

12 Jun '08

Full_Name: Gavin Henry Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) http://www.openldap.org/software/man.cgi?query=slapd.conf&sektion=5&apropos… missing TLSCipherSuite

1 0

Re: (ITS#5551) assertion causes application failure
by ghenry＠OpenLDAP.org 12 Jun '08

12 Jun '08

> Is there debug output you would like from me? See http://www.openldap.org/faq/data/cache/59.html -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: (ITS#5540) Normalization assertion in attr.c
by h.b.furuseth＠usit.uio.no 12 Jun '08

12 Jun '08

hyc(a)symas.com writes: >>> monitorContext, readOnly and the olc* attributes are defined by OpenLDAP >>> (their OIDs start with 1.3.6.1.4.1.4203) and can be modified if we feel >>> like it. Personally I prefer attrs to have the matching rules they can >>> have unless there is a reason not to, but I didn't write these modules >>> so I don't know if there _is_ a reason not to. > > For the config attributes, I just assumed no one needs to search on > them (so no filter capability needed) and for single-valued > attributes, there's no need to consider modifies... Oh, good. No reason not to add matching rules then:-) I search for one config attrs or another once in a while. Mostly for olcSuffix and with presence filters, but it'd be nice if e.g. (olcAccess:caseIgnoreSubstringsMatch:=*userPassword*) worked. Also some day I'll want to use assertion controls as a check on modify operations someday. Still, I'm not proposing to add more work than necessary to this ITS. Get it right first, then think of "nice to have"-features if/when anyone bothers. -- Hallvard

1 0

Re: (ITS#5553) Inconsistent sasl.c logging format
by h.b.furuseth＠usit.uio.no 12 Jun '08

12 Jun '08

hyc(a)symas.com writes: >> Would it be reasonable to change the 6 debug statements in sasl.c to >> use the first format? > > I don't see any reason not to. I do: Currently that format is more or less reserved for loglevel stats/stats2, and is useful when grepping a more chatty log for stats. Though it could certainly be useful to normalize log formats a little. -- Hallvard

1 0

Re: (ITS#5540) Normalization assertion in attr.c
by hyc＠symas.com 12 Jun '08

12 Jun '08

unix.gurus(a)gmail.com wrote: >>> namingContexts >>> configContext >>> dynamicSubtrees >>> >>> These attributes do not have equality matching rules, but probably >>> should. I add 'EQUALITY distinguishedNameMatch' to them in >>> schema_prep.c. >> No, that breaks the definitions in the RFCs they come from. (See their >> DESC strings.) I don't know why they lack EQUALITY rules, maybe we just >> forgot when we defined them, but that's the way it is. Same with >> supportedControl. configContext is OpenLDAP-specific. It is also single-valued, so it seemed to me it did not need an EQ rule. > Ok, so we should not define nvals for them? No normalizer, therefore, cannot provide nval... >> monitorContext, readOnly and the olc* attributes are defined by OpenLDAP >> (their OIDs start with 1.3.6.1.4.1.4203) and can be modified if we feel >> like it. Personally I prefer attrs to have the matching rules they can >> have unless there is a reason not to, but I didn't write these modules >> so I don't know if there _is_ a reason not to. For the config attributes, I just assumed no one needs to search on them (so no filter capability needed) and for single-valued attributes, there's no need to consider modifies... -- -- 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