openldap-bugs February 2009

openldap-bugs@openldap.org

47 participants
298 discussions

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 20 Feb '09

20 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 20 Feb '09

20 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 20 Feb '09

20 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 20 Feb '09

20 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 20 Feb '09

20 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

Re: (ITS#5960) [rwm] segfault with slapcat on cn=config
by hyc＠symas.com 20 Feb '09

20 Feb '09

tchemineau(a)linagora.com wrote: > Full_Name: Thomas Chemineau > Version: RE24 and HEAD > OS: CentOS > URL: ftp://ftp.openldap.org/incoming/thomas-chemineau-090219.patch > Submission from: (NULL) (213.41.243.192) > > > Hi, > > Here is the following configuration : > > 8<---- > include /opt/openldap-2.4.14/etc/openldap/schema/core.schema > pidfile /opt/openldap-2.4.14/var/run/slapd.pid > argsfile /opt/openlidap-2.4.14/var/run/slapd.args > > database ldap > suffix "o=proxy" > uri ldap://server.lan > idassert-bind mode=none flags=prescriptive bindmethod=simple timeout=0 > network-timeout=0 binddn="cn=administrateur,cn=users,dc=otherdemo,dc=lan" > credentials="secret" > overlay rwm > rwm-suffixmassage "o=proxy" "dc=otherdemo,dc=lan" > > database bdb > suffix "dc=my-domain,dc=com" > rootdn "cn=Manager,dc=my-domain,dc=com" > rootpw secret > directory /opt/openldap-2.4.14/var/openldap-data > index objectClass eq > 8<---- > > Initializing cn=config via slapd -f ... -F works fine. Now, if I want to do a > slapcat on cn=config with the following command, I had a segmentation fault. > > 8<---- > ldif_read_file: read entry file: > "/usr/local/openldap-2.4/etc/openldap/slapd.d/cn=config/olcDatabase={1}ldap/olcOverlay={0}rwm.ldif" > => str2entry: "dn: olcOverlay={0}rwm > objectClass: olcOverlayConfig > objectClass: olcRwmConfig > olcOverlay: {0}rwm > olcRwmRewrite: {0}rwm-suffixmassage "o=proxy" "dc=otherdemo,dc=lan" > olcRwmTFSupport: false > olcRwmNormalizeMapped: FALSE > structuralObjectClass: olcRwmConfig > entryUUID: 8d7c51c4-239f-48f5-9ad5-751a50942eec > creatorsName: cn=config > createTimestamp: 20090219101010Z > entryCSN: 20090219101010.781439Z#000000#000#000000 > modifiersName: cn=config > modifyTimestamp: 20090219101010Z > " >>>> dnPrettyNormal:<olcOverlay={0}rwm> > <<< dnPrettyNormal:<olcOverlay={0}rwm>,<olcOverlay={0}rwm> >>>> dnPretty:<cn=config> > <<< dnPretty:<cn=config> >>>> dnNormalize:<cn=config> > <<< dnNormalize:<cn=config> >>>> dnPretty:<cn=config> > <<< dnPretty:<cn=config> >>>> dnNormalize:<cn=config> > <<< dnNormalize:<cn=config> > <= str2entry(olcOverlay={0}rwm) -> 0x124cbe48 > => test_filter > PRESENT > => access_allowed: search access to > "olcOverlay={0}rwm,olcDatabase={1}ldap,cn=config" "objectClass" requested > <= root access granted > => access_allowed: search access granted by manage(=mwrscxd) > <= test_filter 6 > Erreur de segmentation > 8<---- > > I run GDB, and I had this: > > 8<---=> access_allowed: search access to > "olcOverlay={0}rwm,olcDatabase={1}ldap,cn=config" "objectClass" requested > <= root access granted > => access_allowed: search access granted by manage(=mwrscxd) > <= test_filter 6 > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 46972859751984 (LWP 9462)] > 0x00000000004e08cf in rwm_cf_gen (c=0x7ffff26060b0) at rwm.c:2165 > 2165 for ( last = 0; !BER_BVISNULL( > &rwmap->rwm_bva_rewrite[ last ] ); last++ )- > 8<---- > > It seems that rwmap->rm_bva_rewrite is null. By the way, even if I correct this, > I have a similar issue in the rwm_db_destroy function, because rwmap->rwm_rw is > null too. So, freeing memory on a null pointer causes a segfault too. The above > patch corrects this problem. My apologies if I have missed something here. > > By the way, I make a mistake during the upload file on ftp.openldap.org, you > will find 2 files (both the same): servers.slapd.overlays.rwm.c.patch and the > other one specified above. > Thanks for the report. The last chunk of the patch was solving the wrong problem, so a different fix is in HEAD. -- -- 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

← Newer
1
...
5
6
7
8
9
10
11
...
30
Older →

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 February 2009