openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

Re: (ITS#6421) simple filter with no brackets breaks slapo-dynlist(5)
by h.b.furuseth＠usit.uio.no 07 Dec '09

07 Dec '09

masarati(a)aero.polimi.it writes: > This fix allows the overlay to use poorly formatted data > since we cannot prevent the user from using it. Which is what I suspect is a misfeature... > A better fix would be to intercept write operations that modify entries in > a manner that would trigger slapo-dynlist(5), and be picky about how URLs > are written. This would not fix existing databases, nor handle cases > where slapo-dynlist(5) is configured using slapd-config(5). Yesbut... LDAP URLs can come from many sources and be used in many contexts; I suppose this would in practice need to treat URL-valued attributes as if they had an URL syntax. I guess we could as an extension, turned on by default. > Or, we could simply become picky about how LDAP URIs are written in general. Yup. -- Hallvard

1 0

Re: (ITS#6421) simple filter with no brackets breaks slapo-dynlist(5)
by masarati＠aero.polimi.it 07 Dec '09

07 Dec '09

> masarati(a)aero.polimi.it writes: >> Well, the fact is that memberURL is stored in the data. As soon as we >> accept that value, we need to deal with it. The current behavior of >> slapo-dynlist(5) consists in ignoring it (the resulting filter cannot be >> parsed). We should rather reject values like this when written in the >> database, but this would probably break other applications. So I >> believe the fix is better than silently ignoring these values. > > I disagree. Data validation in LDAP is generally the user's job, LDAP > syntaxes are very rough in that regard. > > If this is a fix to make dynlist compatible with the rest of OpenLDAP's > handling of URLs in data (e.g. the ref attribute), then this is a good > fix and I'm way to late to complain. But in my view, if this fix is > introducing an incompatibility with the LDAP spec, then it's not. Data validation is the user's responsibility, but here we're using user data (an LDAP URI) to perform internal operations, so if we want to be strict, we should do it when the user writes the data, not when we are going to use it. This fix allows the overlay to use poorly formatted data since we cannot prevent the user from using it. A better fix would be to intercept write operations that modify entries in a manner that would trigger slapo-dynlist(5), and be picky about how URLs are written. This would not fix existing databases, nor handle cases where slapo-dynlist(5) is configured using slapd-config(5). Or, we could simply become picky about how LDAP URIs are written in general. p.

1 0

Re: (ITS#6421) simple filter with no brackets breaks slapo-dynlist(5)
by h.b.furuseth＠usit.uio.no 07 Dec '09

07 Dec '09

masarati(a)aero.polimi.it writes: > Well, the fact is that memberURL is stored in the data. As soon as we > accept that value, we need to deal with it. The current behavior of > slapo-dynlist(5) consists in ignoring it (the resulting filter cannot be > parsed). We should rather reject values like this when written in the > database, but this would probably break other applications. So I > believe the fix is better than silently ignoring these values. I disagree. Data validation in LDAP is generally the user's job, LDAP syntaxes are very rough in that regard. If this is a fix to make dynlist compatible with the rest of OpenLDAP's handling of URLs in data (e.g. the ref attribute), then this is a good fix and I'm way to late to complain. But in my view, if this fix is introducing an incompatibility with the LDAP spec, then it's not. -- Hallvard

1 0

Re: (ITS#6421) simple filter with no brackets breaks slapo-dynlist(5)
by masarati＠aero.polimi.it 07 Dec '09

07 Dec '09

> masarati(a)aero.polimi.it writes: >> When a memberURL contains a simple filter with no brackets, like >> >> ldap:///ou=People,dc=example,dc=com???objectClass=person >> slapo-dynlist(5) is unable to build the composite filter needed >> for the related internal search. >> >> A fix is coming. > > Are you sure that's a good idea to fix? > > It's not a valid LDAP filter, even though OpenLDAP accepts it in > many places. That we accept it from users in tools is fair enough, > but I'm not sure it's a good idea to accept them on the server side. > > Makes them one step closer to interoperability problems if they > reach other servers that do not slap on the necessary parens. Well, the fact is that memberURL is stored in the data. As soon as we accept that value, we need to deal with it. The current behavior of slapo-dynlist(5) consists in ignoring it (the resulting filter cannot be parsed). We should rather reject values like this when written in the database, but this would probably break other applications. So I believe the fix is better than silently ignoring these values. p.

1 0

Re: (ITS#6421) simple filter with no brackets breaks slapo-dynlist(5)
by h.b.furuseth＠usit.uio.no 07 Dec '09

07 Dec '09

masarati(a)aero.polimi.it writes: > When a memberURL contains a simple filter with no brackets, like > > ldap:///ou=People,dc=example,dc=com???objectClass=person > slapo-dynlist(5) is unable to build the composite filter needed > for the related internal search. > > A fix is coming. Are you sure that's a good idea to fix? It's not a valid LDAP filter, even though OpenLDAP accepts it in many places. That we accept it from users in tools is fair enough, but I'm not sure it's a good idea to accept them on the server side. Makes them one step closer to interoperability problems if they reach other servers that do not slap on the necessary parens. -- Hallvard

1 0

(ITS#6421) simple filter with no brackets breaks slapo-dynlist(5)
by masarati＠aero.polimi.it 07 Dec '09

07 Dec '09

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.149.38.247) Submitted by: ando When a memberURL contains a simple filter with no brackets, like ldap:///ou=People,dc=example,dc=com???objectClass=person slapo-dynlist(5) is unable to build the composite filter needed for the related internal search. A fix is coming. p.

1 0

Re: (ITS#6419) bindconf parser doesn't apply tls-defaults as documented
by quanah＠zimbra.com 07 Dec '09

07 Dec '09

--On Monday, December 07, 2009 2:24 PM +0000 rhafer(a)suse.de wrote: > ------------------------------------ > olcSyncrepl: {0}rid=1 provider="ldap://master/" searchbase="dc=test" > type="refreshAndPersist" starttls=critical bindmethod="simple" > binddn="uid=syncrepl,dc=test" credentials="XXXXXX" > ------------------------------------ > > Question is if this is a bug in the documentation or in the code. I think > it's the latter. Howard believes this is fixed in head with servers/slapd/config.c 1.508 -> 1.509. Can you please test and let us know the result? Thanks! --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6420) test058-syncrepl-asymmetric may not clean up
by h.b.furuseth＠usit.uio.no 07 Dec '09

07 Dec '09

Full_Name: Hallvard B Furuseth Version: RE24 OS: Linux URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard test058-syncrepl-asymmetric can leave slapd processes behind on failure. It tries to kill them with the command 'KILL' instead of 'kill'. Fixed in rev 1.4 in HEAD.

1 0

(ITS#6419) bindconf parser doesn't apply tls-defaults as documented
by rhafer＠suse.de 07 Dec '09

07 Dec '09

Full_Name: Ralf Haferkamp Version: 2.4.20, HEAD OS: any URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (92.252.43.63) The bindconf parse is used in a few places where remote connection to other server are to be configured (syncrepl, back-ldap, ...). The documented behavior is (from the syncrepl section in slapd-config(5)): "The tls_reqcert setting defaults to "demand" and the other TLS settings default to the same as the main slapd TLS settings." This does however only seem to work if at least one of the "tls_" appears in the bindconfig. E.g. the following syncrepl config doesn't have any "tls_" setting and should, according to the man-page work as if "tls_reqcert=demand" was set. However the actual behavior is like "tls_reqcert=never". ------------------------------------ olcSyncrepl: {0}rid=1 provider="ldap://master/" searchbase="dc=test" type="refreshAndPersist" starttls=critical bindmethod="simple" binddn="uid=syncrepl,dc=test" credentials="XXXXXX" ------------------------------------ Question is if this is a bug in the documentation or in the code. I think it's the latter.

1 0

Re: (ITS#5810) $BACKEND selections in make test
by h.b.furuseth＠usit.uio.no 06 Dec '09

06 Dec '09

All tests now check for backends they do _not_ support, not for which ones they do support. They note why backends get exluded. ./run -b ndb all" accordingly runs the following tests which it didn't before. If any of that was intentional, ndb needs to be re-excluded. test006-acls test018-syncreplication-persist test019-syncreplication-cascade test023-refint test033-glue-syncrepl test040-subtree-rename test041-aci test043-delta-syncrepl test045-syncreplication-proxied test054-syncreplication-parallel-load test055-valregex test057-memberof-refint test058-syncrepl-asymmetric Beyond that, I seem to have confused this ITS with an "add support for back-ldif and back-null" ITS, so I'll continue that way. back-ldif passes the tests I can run here. back-null now fails 6 tests. Need to look closer to figure out if any failures are bugs (or doc bugs), which is kind of the point of the exercise. -- Hallvard

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