October 2008 - openldap-bugs

(ITS#5779) backsql_load_schema_map checks wrong schema column in db

by robb＠wtg.cw.com

Full_Name: Robert Brooks Version: 2.4.12 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.28.17.64) start-up of slapd reports "backsql_load_schema_map(): required column #6 "expect_return" is empty" however the value of ldap_oc_mappings.create_proc is actually being checked, this can be confirmed by changing create_proc value in database from empty value to non-empty. problem seems to be around line 567 of schema-map.c " { delete_proc_idx + 1, "expect_return" }," 6 seems correct value, but actual result is not correct

14 years, 4 months

1
0
0 / 0

Re: (ITS#5778) slapd crashes while adding multipe attributes

by ando＠sys-net.it

yoreck(a)rambler.ru wrote: > Full_Name: Yuriy V. Ohonin > Version: slapd 2.4.3alpha (Oct 16 2008 14:08:49) Is there any special reason you're using a release that is more than 2 years old? Can you reproduce the issue with the latest release? 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 -----------------------------------

14 years, 4 months

1
0
0 / 0

(ITS#5778) slapd crashes while adding multipe attributes

by yoreck＠rambler.ru

Full_Name: Yuriy V. Ohonin Version: slapd 2.4.3alpha (Oct 16 2008 14:08:49) OS: FreeBSD 6.2-RELEASE URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.65.16.93) slapd daemon crashes complitely in such a situation: I create my own class in shema objectclass ( Tasks:Chain:Element NAME ('x-tch-e' 'x-Task-Chain-Element') MUST ( cn ) MAY ( x-tch-nxt $ x-tch-sp $ x-tch-ep ) DESC 'Container of pointers, next and previos' ) and an attribute wich should have multiple values attributetype ( Tasks:Attr:3 NAME ('x-tch-nxt' 'x-Task-Chain-Next') EQUALITY distinguishedNameMatch DESC 'Point to next chain element' SYNTAX distinguishedName ) Slapd starts sussesfully. It is possible add first x-tch-nxt attribute to an entry, but if i try to add next one (usind ldapbrowser, or ldap_mod_add php function) slapd stops (i have no such process any more) this is what syslog say: Oct 30 12:11:45 yurik kernel: pid 13227 (slapd), uid 389: exited on signal 6

14 years, 4 months

1
0
0 / 0

Re: (ITS#5777) slapd should reject BindRequest with 'name' when SASL bind is sent

by michael＠stroeder.com

Kurt Zeilenga wrote: > > On Oct 29, 2008, at 2:56 AM, michael(a)stroeder.com wrote: > >> I wonder whether it would be worth that slapd rejects a SASL bind >> request with >> BindRequest.name set (normally used for simple bind) returning a >> protocolError >> error code. > > RFC 4513: > Clients sending a BindRequest message with the sasl choice selected > SHOULD send a zero-length value in the name field. Servers receiving > a BindRequest message with the sasl choice selected SHALL ignore any > value in the name field. > > So, no. Ok. My intention was that if 'name' field and SASL authc-ID leads to different identity mapping it could confuse admins seeing 'name' in the BindRequest but a different authz-ID being in effect. Anyway no strong need, just an idea. Ciao, Michael.

14 years, 4 months

1
0
0 / 0

Re: (ITS#5745) slapcat doesn't return correct error status for bdb fatal error

by hyc＠symas.com

Guillaume.Rousse(a)inria.fr wrote: > Full_Name: Guillaume Rousse > Version: 2.4.12 > OS: > URL: > Submission from: (NULL) (193.55.250.67) > > > [root@etoile ~]# slapcat -b dc=msr-inria,dc=inria,dc=fr > ... > bdb(dc=msr-inria,dc=inria,dc=fr): pthread lock failed: Invalid argument > bdb(dc=msr-inria,dc=inria,dc=fr): PANIC: Invalid argument > bdb(dc=msr-inria,dc=inria,dc=fr): PANIC: DB_RUNRECOVERY: Fatal error, run > database recovery > bdb(dc=msr-inria,dc=inria,dc=fr): PANIC: fatal region error detected; run > recovery > bdb_db_close: database "dc=msr-inria,dc=inria,dc=fr": close failed: > DB_RUNRECOVERY: Fatal error, run database recovery (-30975) > [root@etoile ~]# echo $? > 0 > > It makes a bit difficult to know if slapcat-based backup were successful. How did you create this situation? I can't test a fix without some way to break the DB in the first place, and generally the DB doesn't fail... -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

14 years, 4 months

1
0
0 / 0

Re: (ITS#5763) libRSAglue bug in OpenLDAP configure script

by hyc＠symas.com

epj(a)newpointtech.com wrote: > Full_Name: Eric Johanson > Version: 2.4.12 > OS: Debian Linux 4.0 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (64.80.228.78) > > > The "configure" script has a bug when TLS is enabled, which causes it to fail > when using recent versions of OpenSSL. The bug is found on line 18759 of the > "configure" script in OpenLDAP 2.4.12. The line currently reads: > > LIBS="-lssl -lcrypto -lRSAglue -lrsaref $LIBS" > > But the -lRSAglue and -lrsaref are old OpenSSL libraries that are not in use any > more. I modified the above line to read: > > LIBS="-lssl -lcrypto $LIBS" > > This solves the problem. However, perhaps someone wants to add logic to detect > which version of OpenSSL is being used and then vary the LIBS variable > accordingly when the configure script tests for the linkability of the > ssl3_accept() function. > > Note that many Linux systems, even those that have a recent OpenSSL, may still > have the -lRSAglue and -lrsaref libraries (just for compatibility reasons). To > reproduce this bug, you will have to search your system and remove all files > with the names libRSAglue.a and librsaref.a. The configure script only checks for -lRSAglue after it has already failed to link without it. As such, there's something wrong on your machine for it to even be reaching that test. There is no OpenLDAP bug here. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

14 years, 4 months

1
0
0 / 0

Re: (ITS#5777) slapd should reject BindRequest with 'name' when SASL bind is sent

by Kurt＠OpenLDAP.org

On Oct 29, 2008, at 2:56 AM, michael(a)stroeder.com wrote: > I wonder whether it would be worth that slapd rejects a SASL bind > request with > BindRequest.name set (normally used for simple bind) returning a > protocolError > error code. RFC 4513: Clients sending a BindRequest message with the sasl choice selected SHOULD send a zero-length value in the name field. Servers receiving a BindRequest message with the sasl choice selected SHALL ignore any value in the name field. So, no. -- Kurt

14 years, 4 months

1
0
0 / 0

Re: (ITS#5777) slapd should reject BindRequest with 'name' when SASL bind is sent

by hyc＠symas.com

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: HEAD > OS: Linux > URL: > Submission from: (NULL) (84.163.120.227) > > > This is somewhat related to the client tool modification in ITS#5753. > > I wonder whether it would be worth that slapd rejects a SASL bind request with > BindRequest.name set (normally used for simple bind) returning a protocolError > error code. > > Example for an inconsistent use of -D and -U with SASL/DIGEST-MD5 at the > command-line: > > $ ldapwhoami -D "cn=root,dc=stroeder,dc=de" -W -U michael -Y DIGEST-MD5 > Enter LDAP Password: > SASL/DIGEST-MD5 authentication started > SASL username: michael > SASL SSF: 128 > SASL data security layer installed. > dn:cn=michael ströder,ou=private,dc=stroeder,dc=de Changing this behavior seems like a bad idea to me. Currently the RFC doesn't require servers to behave one way or the other, so there's no argument that this change would improve interoperability. If there are no clients out there depending on the behavior, then this change is meaningless. If there *are* clients out there depending on the behavior, then they will break for no apparent reason. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

14 years, 4 months

1
0
0 / 0

(ITS#5777) slapd should reject BindRequest with 'name' when SASL bind is sent

by michael＠stroeder.com

Full_Name: Michael Ströder Version: HEAD OS: Linux URL: Submission from: (NULL) (84.163.120.227) This is somewhat related to the client tool modification in ITS#5753. I wonder whether it would be worth that slapd rejects a SASL bind request with BindRequest.name set (normally used for simple bind) returning a protocolError error code. Example for an inconsistent use of -D and -U with SASL/DIGEST-MD5 at the command-line: $ ldapwhoami -D "cn=root,dc=stroeder,dc=de" -W -U michael -Y DIGEST-MD5 Enter LDAP Password: SASL/DIGEST-MD5 authentication started SASL username: michael SASL SSF: 128 SASL data security layer installed. dn:cn=michael ströder,ou=private,dc=stroeder,dc=de

14 years, 4 months

1
0
0 / 0

Re: (ITS#5753) Command-line tools: Handling of -x and -D vs. -Y and -U

by michael＠stroeder.com

Seems to work as expected.

14 years, 4 months

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs October 2008