openldap-bugs

openldap-bugs@openldap.org

1 participants
20965 discussions

Re: (ITS#5761) More flexible dynlist configuration desirable
by ando＠sys-net.it 21 Oct '08

21 Oct '08

Applied to HEAD; please test. Instructions are (should be) in slapo-dynlist(5). p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5761) More flexible dynlist configuration desirable
by Guillaume.Rousse＠inria.fr 21 Oct '08

21 Oct '08

Full_Name: Guillaume Rousse Version: 2.4.11 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.55.250.67) Dynlist overlay only accept a single configuration directive for the whole base, preventing to map differently the request URL depending on the context. For including users into groups with such URL as ldap:///ou=users,dc=domain,dc=tld??sub?(gidNumber=X), you need dynlist-attrset groupOfURLs memberURL member For including groups into other groups, with such URL as ldap:///ou=group,dc=domain,dc=tld?member?sub?(cn=Y), you need dynlist-attrset groupOfURLs memberURL It would be practical to add a switch for this directive, allowing to restrict its application to a specific context. Pierangelo suggested something as: dynlist-attrset <group-oc> <URL-ad> [ ldap:///base??scope?filter ] [[<mapped-ad>:]<member-ad> ...] Which would turn previous examples into: dynlist-attrset groupOfURLs memberURL ldap:///ou=users,dc=domain,dc=tld??sub?(gidNumber=X) member dynlist-attrset groupOfURLs memberURL ldap:///ou=group,dc=domain,dc=tld??sub?(cn=Y)

1 0

Re: (ITS#5760) attribute hiding in rwm overlay
by ando＠sys-net.it 20 Oct '08

20 Oct '08

brett.maxfield(a)gmail.com wrote: > Full_Name: Brett Maxfield > Version: 2.4.12 release > OS: Solaris 5.10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (203.18.108.167) > > > There is a bug that stops rwm-map being used to hide attributes, eg : > > database ldap > suffix "c=AU" > uri "ldap://<parent ip>:<parent port>/c=AU" > overlay rwm > lastmod off > > # attribute maps (ok except for final "rwm-map attribute *" map) > rwm-map attribute cn * > rwm-map attribute sn * > rwm-map attribute mail * > rwm-map attribute c * > rwm-map attribute o * > rwm-map attribute ou * > > # does not like this, it stops any entries being returned > #rwm-map attribute * > > # objectclass maps (ok) > rwm-map objectclass top * > rwm-map objectclass country * > rwm-map objectclass organization * > rwm-map objectclass organizationalRole * > rwm-map objectclass organizationalPerson * > rwm-map objectclass organizationalUnit * > rwm-map objectclass * Not clear what the problem is, now. The above configuration seems to work as intended as far as attribute mapping is concerned. The fact that "rwm-map objectclass *" no longer kills the objectClass attribuet was fixed some time ago (the fix is in 2.4.12). What kills the allowed objectClass values is a bug in evaluating what values are preserved. If you don't put any "rwm-map objectclass" rule, it works as expected. I'm fixing this other bug. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5760) attribute hiding in rwm overlay
by brett.maxfield＠gmail.com 20 Oct '08

20 Oct '08

Full_Name: Brett Maxfield Version: 2.4.12 release OS: Solaris 5.10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (203.18.108.167) There is a bug that stops rwm-map being used to hide attributes, eg : database ldap suffix "c=AU" uri "ldap://<parent ip>:<parent port>/c=AU" overlay rwm lastmod off # attribute maps (ok except for final "rwm-map attribute *" map) rwm-map attribute cn * rwm-map attribute sn * rwm-map attribute mail * rwm-map attribute c * rwm-map attribute o * rwm-map attribute ou * # does not like this, it stops any entries being returned #rwm-map attribute * # objectclass maps (ok) rwm-map objectclass top * rwm-map objectclass country * rwm-map objectclass organization * rwm-map objectclass organizationalRole * rwm-map objectclass organizationalPerson * rwm-map objectclass organizationalUnit * rwm-map objectclass * Comment from the openlda-software list.. > I am trying to setup a ldap backend which is a filtered view of > another larger parent directory, with respect to exposing fewer object > classes and attributes. > > The intent is to present a simpler view of the larger directory, and > the config below works, except for when i uncomment the line > containing "rwm-map attribute *", to hide the attributes i do not want > visible, but after that it stops returning any entries at all for any > query. So may be there is some important openldap attribute i am > nuking ? Yes, I fear that's hiding the objectClass attribute, which is required for internal operations. On the other hand, you can't simply tell back-ldap to preserve that attribute, because mapping objectClass is not allowed. I suggest you file an ITS so that this problem can be fixed. p. Ing. Pierangelo Masarati OpenLDAP Core Team

1 0

Re: (ITS#5755) Schema file not always converted to LDIF and slapdwon't restart
by hyc＠symas.com 20 Oct '08

20 Oct '08

h.b.furuseth(a)usit.uio.no wrote: > I wrote: >> Possibly that should wait for OpenLDAP 2.5 though, and just log a >> warning for now. > > ...though -f file -F dir should fail, of course. Splitting these two behaviors isn't possible. The same config_build_entry() function is called in both cases; once the error is detected and config_build_entry() fails, the startup will fail. Remember that the full cn=config tree is always assembled in memory, even if you don't use a persistent copy in the filesystem. -- -- 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#5759) whitespace vs white space
by quanah＠OpenLDAP.org 20 Oct '08

20 Oct '08

Full_Name: Quanah Gibson-Mount Version: HEAD OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) I noticed that the term "whitespace" and "white space" are used inconsistently throughout the documentation. Can we please pick one? ;) --Quanah

1 0

Re: (ITS#5757) back-null returns an error when any critical extension is specified
by ando＠sys-net.it 20 Oct '08

20 Oct '08

ando(a)sys-net.it wrote: > A different fix is in HEAD. Please test. p. A more thorough fix is now in HEAD. Please re-test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5758) NO-OP control criticality
by ando＠sys-net.it 20 Oct '08

20 Oct '08

h.b.furuseth(a)usit.uio.no wrote: > ando(a)sys-net.it writes: >> The latest draft I can find (14 February 2007) states that >> >> Clients MUST provide a >> criticality value of TRUE to prevent unintended modification of the >> directory. >> >> As a consequence, I think the server could reject instances of this control >> with a criticality of FALSE, to prevent its unintended use. > > RFC 2251 allowed that (or could be read as alllowing it), but > RFC 4511 deliberately does not, after long discussions on ldapbis. OK, backing out my latest commit. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5758) NO-OP control criticality
by h.b.furuseth＠usit.uio.no 20 Oct '08

20 Oct '08

ando(a)sys-net.it writes: > The latest draft I can find (14 February 2007) states that > > Clients MUST provide a > criticality value of TRUE to prevent unintended modification of the > directory. > > As a consequence, I think the server could reject instances of this control > with a criticality of FALSE, to prevent its unintended use. RFC 2251 allowed that (or could be read as alllowing it), but RFC 4511 deliberately does not, after long discussions on ldapbis. -- Hallvard

1 0

(ITS#5758) NO-OP control criticality
by ando＠sys-net.it 20 Oct '08

20 Oct '08

Full_Name: Pierangelo Masarati Version: HEAD/re24/re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando The latest draft I can find (14 February 2007) states that Clients MUST provide a criticality value of TRUE to prevent unintended modification of the directory. As a consequence, I think the server could reject instances of this control with a criticality of FALSE, to prevent its unintended use. However, OpenLDAP's slapd currently tolerates a criticality of FALSE, and OpenLDAP clients allow users to use this control with a criticality of FALSE. I think the clients need to be fixed, and the server should prevent this improper use. Also, the server should check whether the control is used with operations not indicated in the draft (i.e. non-write ops). p.

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