openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

Re: (ITS#5963) Explictly deleting all object classes and re-add some fails in modify request
by michael＠stroeder.com 20 Feb '09

20 Feb '09

Pierangelo Masarati wrote: > michael(a)stroeder.com wrote: > >> If I explicitly remove all object classes of an entry by value and >> re-add some >> of them the modify requests fail with >> "Type or value exists: modify/add: objectClass: value #1 already exists" >> >> Unfortunately I cannot provide a simple example for showing this. >> Specific configuration and data upon request since it's private >> data which MUST NOT be disclosed. > > I could not reproduce it. I also can't reproduce it with standard object classes on my local system. > Probably, the best way to proceed is: I could provide a canned config to a developer which should be kept confidential. Do you take that? Ciao, Michael.

1 0

Re: (ITS#5963) Explictly deleting all object classes and re-add some fails in modify request
by ando＠sys-net.it 20 Feb '09

20 Feb '09

michael(a)stroeder.com wrote: > If I explicitly remove all object classes of an entry by value and re-add some > of them the modify requests fail with > "Type or value exists: modify/add: objectClass: value #1 already exists" > > Unfortunately I cannot provide a simple example for showing this. Specific > configuration and data upon request since it's private data which MUST NOT be > disclosed. I could not reproduce it. Probably, the best way to proceed is: 1) write down the objectClass values before and after the attempted modifications 2) classify them as ABSTRACT, STRUCTURAL, AUXILIARY 3) indicate any inheritance relationship 4) send the outcome of (2) and (3) after mangling the objectClass names as required. This should allow you (and others) to try to reproduce the issue without the need to disclose your info. 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#5964) Explictly deleting all object classes and re-add some fails in modify request
by michael＠stroeder.com 20 Feb '09

20 Feb '09

openldap-its(a)OpenLDAP.org wrote: > You may follow the progress of this report by loading the following > URL in a web browser: > http://www.OpenLDAP.org/its/index.cgi?findid=5964 Sorry, this duplicate was produced by hitting reload. Please remove it. Ciao, Michael.

1 0

(ITS#5964) Explictly deleting all object classes and re-add some fails in modify request
by michael＠stroeder.com 20 Feb '09

20 Feb '09

Full_Name: Michael Ströder Version: RE24 (synced right now) OS: openSUSE 11.1 URL: Submission from: (NULL) (84.163.85.36) If I explicitly remove all object classes of an entry by value and re-add some of them the modify requests fail with "Type or value exists: modify/add: objectClass: value #1 already exists" Unfortunately I cannot provide a simple example for showing this. Specific configuration and data upon request since it's private data which MUST NOT be disclosed.

1 0

(ITS#5963) Explictly deleting all object classes and re-add some fails in modify request
by michael＠stroeder.com 20 Feb '09

20 Feb '09

1 0

Re: (ITS#5959) back-meta doesn't detect illegal values
by ando＠sys-net.it 19 Feb '09

19 Feb '09

hyc(a)symas.com wrote: > This seems like an odd situation, since we just went thru the validator above, > before attempting to normalize. In this case the attribute was > telephoneNumber, with a value of " " (a single space). The validator is > printableStringValidate, which accepts the value. But telephoneNumberNormalize > rejects it. Shouldn't the validator and normalizer always accept the same set > of input? I suggest you file an ITS :) I agree having normalize fail where validate would succeed should never happen. > Anyway, HEAD is fixed to just drop the illegal values, as Ando suggested. Thanks, I was about to look at it myself. 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#5959) back-meta doesn't detect illegal values
by hyc＠symas.com 19 Feb '09

19 Feb '09

hyc(a)OpenLDAP.org wrote: > Full_Name: Howard Chu > Version: 2.4.14/HEAD > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (76.91.220.157) > Submitted by: hyc > > > back-meta doesn't check the return code from the normalizer when it's > normalizing the values of an attribute. As such, it can leave NULL slots in > a->a_nvals even though a->a_vals slots are all non-NULL. This seems like an odd situation, since we just went thru the validator above, before attempting to normalize. In this case the attribute was telephoneNumber, with a value of " " (a single space). The validator is printableStringValidate, which accepts the value. But telephoneNumberNormalize rejects it. Shouldn't the validator and normalizer always accept the same set of input? Anyway, HEAD is fixed to just drop the illegal values, as Ando suggested. -- -- 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#5959) back-meta doesn't detect illegal values
by hyc＠symas.com 19 Feb '09

19 Feb '09

Pierangelo Masarati wrote: > hyc(a)OpenLDAP.org wrote: > >> back-meta doesn't check the return code from the normalizer when it's >> normalizing the values of an attribute. As such, it can leave NULL slots in >> a->a_nvals even though a->a_vals slots are all non-NULL. >> >> I was going to try just dup'ing the a->a_vals value into the slot, but I see >> that in back-ldap for the same situation, the entire attribute is just dropped. >> I suppose that's the safer path. > > In the spirit of doing what's best to return as much as possible, > wouldn't it be preferable to just drop illegal values? And, of course, > the whole attr if no legal values are left. Looking over the code, there are some other problems. Other areas will drop values for various reasons (e.g., mapping out objectclass values). attr->a_numvals is set before these checks occur, and is not updated with the correct count later. I'll try to get some more fixes in for .15. -- -- 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#5916) Allow alias dereferencing in search C API
by ando＠sys-net.it 19 Feb '09

19 Feb '09

ando(a)sys-net.it wrote: > A patch is coming. An essential part of the fix was missing. This is now fixed in HEAD, please 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#5959) back-meta doesn't detect illegal values
by hyc＠symas.com 19 Feb '09

19 Feb '09

Pierangelo Masarati wrote: > hyc(a)OpenLDAP.org wrote: > >> back-meta doesn't check the return code from the normalizer when it's >> normalizing the values of an attribute. As such, it can leave NULL slots in >> a->a_nvals even though a->a_vals slots are all non-NULL. >> >> I was going to try just dup'ing the a->a_vals value into the slot, but I see >> that in back-ldap for the same situation, the entire attribute is just dropped. >> I suppose that's the safer path. > > In the spirit of doing what's best to return as much as possible, > wouldn't it be preferable to just drop illegal values? And, of course, > the whole attr if no legal values are left. Sounds fine, will do that for a future rev. -- -- 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