openldap-bugs June 2008

openldap-bugs@openldap.org

46 participants
176 discussions

(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

Re: (ITS#5553) Inconsistent sasl.c logging format
by hyc＠symas.com 12 Jun '08

12 Jun '08

unix.gurus(a)gmail.com wrote: > Full_Name: Sean Burford > Version: 2.4.8 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (72.14.227.1) > > > Most connection logs are of the format: > conn=\d+ fd=\d+ MSG > > sasl.c Debug logs are of the format: > SASL .*[conn=\d+]: MSG > > 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. > > This is not an important issue, just a small inconsistency. -- -- 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#5553) Inconsistent sasl.c logging format
by unix.gurus＠gmail.com 12 Jun '08

12 Jun '08

Full_Name: Sean Burford Version: 2.4.8 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (72.14.227.1) Most connection logs are of the format: conn=\d+ fd=\d+ MSG sasl.c Debug logs are of the format: SASL .*[conn=\d+]: MSG Would it be reasonable to change the 6 debug statements in sasl.c to use the first format? This is not an important issue, just a small inconsistency.

1 0

← Newer
1
...
11
12
13
14
15
16
17
18
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs June 2008