openldap-bugs

openldap-bugs@openldap.org

1 participants
21065 discussions

Re: (ITS#6618) Add support for unbind requests in perl backend
by Kurt＠OpenLDAP.org 11 Aug '10

11 Aug '10

On Aug 11, 2010, at 8:29 AM, masarati(a)aero.polimi.it wrote: >> Full_Name: Gareth Palmer >> Version: CVS HEAD >> OS: Ubuntu 9.04 >> URL: >> = http://www.acsdata.co.nz/patches/openldap-back_perl-unbind-100811.patch >> Submission from: (NULL) (202.21.137.14) >>=20 >>=20 >> Hello, >>=20 >> This patch adds support for passing through unbind requests to the >> underlying >> module when using the perl backend. >=20 > In this patch, the unbind operation is bypassed if requested by the > rootdn. You seem to consider "unbind" as the opposite of "bind", = while it > is a request to shutdown a connection between client and server. As = such, > it should be honored also when the connection is bound as the rootdn. More to the point, backends should not be dependent on close (nor open) = connection events. Hence this patch ought to be rejected. -- Kurt=

1 0

Re: (ITS#6618) Add support for unbind requests in perl backend
by masarati＠aero.polimi.it 11 Aug '10

11 Aug '10

> Full_Name: Gareth Palmer > Version: CVS HEAD > OS: Ubuntu 9.04 > URL: > http://www.acsdata.co.nz/patches/openldap-back_perl-unbind-100811.patch > Submission from: (NULL) (202.21.137.14) > > > Hello, > > This patch adds support for passing through unbind requests to the > underlying > module when using the perl backend. In this patch, the unbind operation is bypassed if requested by the rootdn. You seem to consider "unbind" as the opposite of "bind", while it is a request to shutdown a connection between client and server. As such, it should be honored also when the connection is bound as the rootdn. p.

1 0

(ITS#6620) ppolicy: pwdChangedTime/userPassword delete issue.
by m.d.t.evans＠qmul.ac.uk 11 Aug '10

11 Aug '10

Full_Name: Martin Evans Version: 2.4.20 OS: CentOS 5.X URL: Submission from: (NULL) (138.37.8.59) I've attached a proposed patch to fix an error that sometimes occurs when attempting to delete a userPassword attribute from an entry whilst the ppolicy overlay is active. The OL 2.4.20 code seems to assume that this operational attribute always exists (but it clearly cannot always exist otherwise the error would not occur). I think it can be reproduced by adding a fresh entry that contains a userPassword. Then simply deleting the userPassword fails resulting in: ldap_modify: No such attribute (16) additional info: modify/delete: pwdChangedTime: no such attribute Further experiments show that if the userPassword is modified before then deleted the error does not occur (presumably because something else sets pwdChangedTime on a mod operation but not when the attribute is added in an entire new entry). I've modified our OL 2.4.20 test systems with the patch below and the problem goes away: Cheerio! Martin. -bash-3.2# diff -u servers/slapd/overlays/ppolicy.c.0 servers/slapd/overlays/ppolicy.c --- servers/slapd/overlays/ppolicy.c.0 2009-08-26 00:07:41.000000000 +0100 +++ servers/slapd/overlays/ppolicy.c 2010-08-11 14:28:53.000000000 +0100 @@ -1880,22 +1880,31 @@ slap_timestamp( &now, &timestamp ); mods = (Modifications *) ch_calloc( sizeof( Modifications ), 1 ); - mods->sml_desc = ad_pwdChangedTime; + + /* MDTE PATCH 20100811: modify to not do delete non existing pwdChangedTime */ if (pwmop != LDAP_MOD_DELETE) { + mods->sml_desc = ad_pwdChangedTime; mods->sml_op = LDAP_MOD_REPLACE; mods->sml_numvals = 1; mods->sml_values = (BerVarray) ch_malloc( 2 * sizeof( struct berval ) ); ber_dupbv( &mods->sml_values[0], &timestamp ); BER_BVZERO( &mods->sml_values[1] ); assert( !BER_BVISNULL( &mods->sml_values[0] ) ); - + mods->sml_flags = SLAP_MOD_INTERNAL; + mods->sml_next = NULL; + modtail->sml_next = mods; + modtail = mods; } else { - mods->sml_op = LDAP_MOD_DELETE; + if (attr_find(e->e_attrs, ad_pwdChangedTime )) { + mods->sml_desc = ad_pwdChangedTime; + mods->sml_op = LDAP_MOD_DELETE; + mods->sml_flags = SLAP_MOD_INTERNAL; + mods->sml_next = NULL; + modtail->sml_next = mods; + modtail = mods; + } } - mods->sml_flags = SLAP_MOD_INTERNAL; - mods->sml_next = NULL; - modtail->sml_next = mods; - modtail = mods; + /* END OF MDTE PATCH */ if (attr_find(e->e_attrs, ad_pwdGraceUseTime )) { mods = (Modifications *) ch_calloc( sizeof( Modifications ), 1 );

1 0

(ITS#6619) CSN too old
by heinz.hoelzl＠gvcc.net 11 Aug '10

11 Aug '10

Full_Name: Heinz Hölzl Version: 2.4.23 OS: Linux Ubuntu Hardy LTS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.18.132.37) If i sync a part of my DIT with syncrepl, the first sync works fine. Then if i modify some objects on the provider, on the consumer appears: "do_syncrep2: rid=105 CSN too old, ignoring 20100811125159.871757Z#000000#001#000000" If i sync the hole DIT all works fine. If i use openldap 2.4.19 for syncing only a part of the DIT all works fine too. The version of the provider is 2.4.23 too. slapd.conf on the provider: ...snip.... database ldap lastmod on suffix "dc=krb" rootdn "cn=admin,dc=krb" uri "ldaps://lbackend.s2.dc.gvcc.net:10636" readonly on ...snip... slapd.conf on the consumer: # Schema and objectClass definitions include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/samba3.schema include /etc/openldap/schema/openldap.schema include /etc/openldap/schema/misc.schema include /etc/openldap/schema/sgv.schema include /etc/openldap/schema/mozillaOrgPerson.schema include /etc/openldap/schema/kerberos.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args allow bind_v2 # Schema check allows for forcing entries to # match schemas for their objectClasses's #schemacheck on loglevel none ####################################################################### # ldbm database definitions ####################################################################### modulepath /usr/lib/ldap moduleload back_hdb moduleload rwm sizelimit unlimited tool-threads 1 access to * by * write include /etc/openldap/tls.conf backend hdb # KERBEROS database hdb dbconfig set_cachesize 0 2097152 0 dbconfig set_lk_max_objects 1500 dbconfig set_lk_max_locks 1500 dbconfig set_lk_max_lockers 1500 lastmod on suffix "dc=krb" checkpoint 512 30 directory "/var/lib/ldap/krb" rootdn "cn=admin,dc=krb" rootpw blabla include /etc/openldap/slapd.replica.consumer-krb index objectClass eq index krbPrincipalName eq,pres,sub index krbPwdPolicyReference eq,pres index entryUUID,aliasedObjectName eq index default sub ############################################################################### /etc/openldap/slapd.replica.consumer-krb: # syncrepl syncrepl rid=101 searchbase="dc=krb" scope=base provider=ldaps://syncrepl.zid.gvcc.net type=refreshAndPersist retry="5 5 300 +" schemachecking=off bindmethod=sasl saslmech=EXTERNAL tls_cert=/etc/openldap/.ssl/usercert.pem tls_key=/etc/openldap/.ssl/user.key tls_cacert=/etc/ssl/cacert.pem tls_reqcert=try syncrepl rid=102 searchbase="cn=princs,dc=krb" scope=base provider=ldaps://syncrepl.zid.gvcc.net type=refreshAndPersist retry="5 5 300 +" schemachecking=off bindmethod=sasl saslmech=EXTERNAL tls_cert=/etc/openldap/.ssl/usercert.pem tls_key=/etc/openldap/.ssl/user.key tls_cacert=/etc/ssl/cacert.pem tls_reqcert=try syncrepl rid=103 searchbase="cn=krbcontainer,dc=krb" scope=sub provider=ldaps://syncrepl.zid.gvcc.net type=refreshAndPersist retry="5 5 300 +" schemachecking=off bindmethod=sasl saslmech=EXTERNAL tls_cert=/etc/openldap/.ssl/usercert.pem tls_key=/etc/openldap/.ssl/user.key tls_cacert=/etc/ssl/cacert.pem tls_reqcert=try syncdata=default syncrepl rid=104 searchbase="o=zid,cn=princs,dc=krb" scope=sub provider=ldaps://syncrepl.zid.gvcc.net type=refreshAndPersist retry="5 5 300 +" schemachecking=off bindmethod=sasl saslmech=EXTERNAL tls_cert=/etc/openldap/.ssl/usercert.pem tls_key=/etc/openldap/.ssl/user.key tls_cacert=/etc/ssl/cacert.pem tls_reqcert=try syncdata=default syncrepl rid=105 searchbase="o=klingons,cn=princs,dc=krb" scope=sub provider=ldaps://syncrepl.zid.gvcc.net type=refreshAndPersist retry="5 5 300 +" schemachecking=off bindmethod=sasl saslmech=EXTERNAL tls_cert=/etc/openldap/.ssl/usercert.pem tls_key=/etc/openldap/.ssl/user.key tls_cacert=/etc/ssl/cacert.pem tls_reqcert=try syncdata=default ################################################################## buid-options for both versions (2.4.19 and 2.4.23) used on the consumer an on the provider: ./configure --prefix=${prefix} --bindir=${prefix}/bin --sbindir=${prefix}/sbin --libexecdir=${prefix}/lib --libdir=${prefix}/lib --sysconfdir=/etc --localstatedir=/var --mandir=${prefix}/share/man --enable-debug --enable-dynamic --enable-syslog --enable-proctitle --enable-ipv6 --enable-local --enable-slapd --enable-aci --enable-cleartext --enable-crypt --disable-lmpasswd --enable-spasswd --enable-modules --enable-rewrite --enable-rlookups --enable-slapi --enable-slp --enable-wrappers --enable-backends=mod --disable-ndb --enable-overlays=mod --with-subdir=ldap --with-cyrus-sasl --with-threads --with-tls=openssl --with-odbc=unixodbc --build x86_64-linux-gnu

1 0

(ITS#6618) Add support for unbind requests in perl backend
by gareth＠acsdata.co.nz 11 Aug '10

11 Aug '10

Full_Name: Gareth Palmer Version: CVS HEAD OS: Ubuntu 9.04 URL: http://www.acsdata.co.nz/patches/openldap-back_perl-unbind-100811.patch Submission from: (NULL) (202.21.137.14) Hello, This patch adds support for passing through unbind requests to the underlying module when using the perl backend. Regards Gareth

1 0

Re: (ITS#6616) back-sql crashing
by masarati＠aero.polimi.it 09 Aug '10

09 Aug '10

> masarati(a)aero.polimi.it wrote: >>> Attempting to create an inetOrgPerson interface to a proprietary >>> database >>> schema. >>> Obviously something wrong at this stage, causes slapd to SEGV. >>> >>> gdb tells me that in >>> servers/slapd/back-sql/entry-id.c:backsql_id2entry() >>> bsi->bsi_oc is null going into this call. >>> >>> rc = attr_merge_normalize_one( bsi->bsi_e, >>> slap_schema.si_ad_objectClass, >>> &bsi->bsi_oc->bom_oc->soc_cname, >>> bsi->bsi_op->o_tmpmemctx ); >>> >>> Without any time to absorb any implications, adding this just before >>> the >>> above >>> call >>> >>> // added without any clue... Rex >>> if ( eid->eid_oc == NULL ) >>> return LDAP_NO_SUCH_OBJECT; >>> >>> fixes the SEGV, but not my interface. >>> >> >> This should not happen, since that objectClass mapping is explicitly >> obtained few lines above if missing, and if the entry's OC was known by >> ID >> it must be available in the ID to OC mapping. I suspect something like >> ITS#6617, where the obejctClass' ID overflows the unsigned long. Can >> you >> investigate? >> >> A backtrace and a description of the expected and actual values would >> help >> (e.g. what ID has the "offending" objectClass, and what ID is >> backsql_id2entry() actually trying to fetch). >> >> It should be OK, at this point, to give up, but a clear indication that >> mapping did not succeed needs to be returned. >> >> p. >> >> > > I've finished my interface and i'm reluctant to share the mess it was in > when it caused the server to crash. > > What i found was that the call to avl_find() in backsql_id2oc() returned > NULL, which got passed back up the > stack, used as a pointer and boom. > > Without spending a long time trying to decipher the code, i could only > guess what any of this means, i'm not > an LDAP expert (or even really all that familiar with it). Please keep replies in CC to the ITS. In principle, avl_find() must return a valid objectClass; logically, we should assert() that a non-NULL pointer is returned. Determining why this occurs could help fixing the issue. Right now, you're just wiping it under the carpet, by returning a generic error instead of the expected data. p.

1 0

Re: (ITS#6600) pcache overlay should ignore invalid attributes in search requests
by masarati＠aero.polimi.it 07 Aug '10

07 Aug '10

> Tentatively, the "right" patch would be like this > > <ftp://ftp.openldap.org/incoming/pierangelo-masarati-its6600.1.patch> This patch, although apparently fixing this specific case, breaks test020; investigating... p.

1 0

Re: (ITS#6616) back-sql crashing
by masarati＠aero.polimi.it 07 Aug '10

07 Aug '10

> Attempting to create an inetOrgPerson interface to a proprietary database > schema. > Obviously something wrong at this stage, causes slapd to SEGV. > > gdb tells me that in servers/slapd/back-sql/entry-id.c:backsql_id2entry() > bsi->bsi_oc is null going into this call. > > rc = attr_merge_normalize_one( bsi->bsi_e, > slap_schema.si_ad_objectClass, > &bsi->bsi_oc->bom_oc->soc_cname, > bsi->bsi_op->o_tmpmemctx ); > > Without any time to absorb any implications, adding this just before the > above > call > > // added without any clue... Rex > if ( eid->eid_oc == NULL ) > return LDAP_NO_SUCH_OBJECT; > > fixes the SEGV, but not my interface. This should not happen, since that objectClass mapping is explicitly obtained few lines above if missing, and if the entry's OC was known by ID it must be available in the ID to OC mapping. I suspect something like ITS#6617, where the obejctClass' ID overflows the unsigned long. Can you investigate? A backtrace and a description of the expected and actual values would help (e.g. what ID has the "offending" objectClass, and what ID is backsql_id2entry() actually trying to fetch). It should be OK, at this point, to give up, but a clear indication that mapping did not succeed needs to be returned. p.

1 0

Re: (ITS#6617) back-sql: 64-bit parent IDs get munged
by masarati＠aero.polimi.it 07 Aug '10

07 Aug '10

> 64-bit values for (at least) parent IDs do not get resolved correctly - > only the > lower 32 bits are preserved. This leads up to a crash as it tries to > resolve a > non-existant ID: > > To reproduce: > ldap_entries has a row with an ID of 1,000,000,000 with a parent of > 9,999,999,999 (and > a row 9,999,999,999 for the parent). When back-sql goes to resolve this, the > following shows in the ODBC trace: > > SELECT COUNT(*) FROM > ldap_entry_objclasses,ldap_entries,ldap_static_entries > WHERE ldap_static_entries.id=1410065407 AND > ldap_entries.id=ldap_entry_objclasses.entry_id AND > ldap_entries.keyval=ldap_static_entries.id and ldap_entries.oc_map_id=4 > > (1,410,065,407 = 32-bit rollover of 9,999,999,999). Currently, IDs are hardcoded as 32-bit unsigned (unsigned long) for internal use. In back-sql, we used the same type. I wonder whether it makes sense to allow to customize them (I think using 64-bit regardless of the arch is not a choice). p.

1 0

(ITS#6617) back-sql: 64-bit parent IDs get munged
by 7003＠blargh.com 07 Aug '10

07 Aug '10

Full_Name: Andrew Gray Version: 2.4.23 OS: Debian 5 64-bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.216.14.1) 64-bit values for (at least) parent IDs do not get resolved correctly - only the lower 32 bits are preserved. This leads up to a crash as it tries to resolve a non-existant ID: To reproduce: ldap_entries has a row with an ID of 1000000000 with a parent of 9999999999 (and a row 9999999999 for the parent). When back-sql goes to resolve this, the following shows in the ODBC trace: SELECT COUNT(*) FROM ldap_entry_objclasses,ldap_entries,ldap_static_entries WHERE ldap_static_entries.id=1410065407 AND ldap_entries.id=ldap_entry_objclasses.entry_id AND ldap_entries.keyval=ldap_static_entries.id and ldap_entries.oc_map_id=4 (1410065407 = 32-bit rollover of 9999999999).

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