openldap-bugs

openldap-bugs@openldap.org

1 participants
21517 discussions

(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

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

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

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

19 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

Re: ITS#5724 (Re: commit: ldap/servers/slapd backover.c)
by hyc＠symas.com 19 Feb '09

19 Feb '09

ando(a)sys-net.it wrote: > ando(a)sys-net.it wrote: > >> Sharing the pointer to the supported controls would allow to use the >> actual set. Something along the line >> >> struct BackendDB { >> char be_ctrlsbuf[SLAP_MAX_CIDS + 1]; >> char *be_ctrls; >> }; >> >> All backends would have be_ctrls = be_ctrlsbuf, but back-relay would set >> it to NULL, and temporarily set it to the relayed database's be_ctrlsbuf >> for the duration of an operation. Modules wouldn't be able to register >> new controls because the pointer is null otherwise. > > Of course, this wouldn't work since it implies modifying the BackendDB > structure, which is read-only :( backover.c 1.91 appears to partially revert rev 1.84, thus breaking ITS#5346 again. Investigating now... -- -- 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#5962) If slapcat can't join shm, it segfaults
by quanah＠OpenLDAP.org 19 Feb '09

19 Feb '09

Full_Name: Quanah Gibson-Mount Version: RE24/HEAD OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) If the shm environment is not available, and you run slapcat, it segfaults: (gdb) bt #0 0x0000002a97256996 in hdb_tool_entry_open (be=0x70ca70, mode=0) at tools.c:108 #1 0x00000000004bb31b in slapcat (argc=7, argv=0x7fbffff8a8) at slapcat.c:73 #2 0x0000000000413274 in main (argc=7, argv=0x7fbffff8a8) at main.c:391

1 0

(ITS#5961) segfault if shm isn't available
by quanah＠OpenLDAP.org 19 Feb '09

19 Feb '09

Full_Name: Quanah Gibson-Mount Version: RE24/HEAD OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) If OpenLDAP can't join the shm environment due to size issues, it segfaults: #0 0x0000002a973fe32b in hdb_checkpoint (ctx=0x41000e20, arg=0x999820) at config.c:192 192 config.c: No such file or directory. in config.c (gdb) bt #0 0x0000002a973fe32b in hdb_checkpoint (ctx=0x41000e20, arg=0x999820) at config.c:192 #1 0x0000002a95702a60 in ldap_int_thread_pool_wrapper (xpool=0x916ee0) at tpool.c:663 #2 0x0000003bfa006137 in start_thread () from /lib64/tls/libpthread.so.0 #3 0x0000003bf97c7533 in clone () from /lib64/tls/libc.so.6

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs