openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

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

10 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 08 Aug '10

08 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 06 Aug '10

06 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

(ITS#6616) back-sql crashing
by rex.johnston＠gmail.com 06 Aug '10

06 Aug '10

Full_Name: Rex Johnston Version: cvs OS: debian URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (123.255.40.107) 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.

1 0

Re: (ITS#6615) objectClass definition and error 65
by quanah＠zimbra.com 04 Aug '10

04 Aug '10

--On Tuesday, August 03, 2010 10:43 PM +0000 philippe.eychart(a)mail.pf wrote: > Full_Name: Philippe EYCHART > Version: 2.4.21 > OS: Ubuntu 9.10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (123.50.86.106) This is a question better suited to openldap-technical(a)openldap.org, but inheritance works by having included the previous parent. I.e., person <- organizationalPerson <- inetOrgPerson, as in, inetOrgPerson inherits from organizationalPerson, which inherits from person. person <- organizationalPerson and person <- referencePerson are different inheritance trees. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6614) Checking Pre-Requisities
by quanah＠zimbra.com 04 Aug '10

04 Aug '10

--On Tuesday, August 03, 2010 9:06 PM +0000 tcssuneelkumar(a)gmail.com wrote: > Full_Name: Suneel > Version: 2.4.23 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (198.95.226.224) The ITS system is for reporting bugs. For help with building the software, etc, use the openldap-technical(a)openldap.org mailing list. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6615) objectClass definition and error 65
by philippe.eychart＠mail.pf 03 Aug '10

03 Aug '10

Full_Name: Philippe EYCHART Version: 2.4.21 OS: Ubuntu 9.10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (123.50.86.106) Hi, Two structural (top) classes are not allowed in the same entry. (a person is not a posixGroup ...) Multiple inheritance is not allowed. (although "oc_sup_oids" is a "char **" in the structure "LDAPObjectClass" ... 8-| ) But, why "organisationalPerson" and "residentialPerson" are they not allowed (error returned: 65) in the same entry of type "person"? Yet, they both inherit from the same objectClass "person"?!... (And these two concepts are not incompatible...) Is this fact a misinterpretation of the "simple inheritance" or this return is correct?... (On the other hand, it's true that "person" and "posixGroup" inherit both from the same -abstract- objectClass : "top" ...) None of my research does the answer (Is this a bugg in the server or must I implement it like that?), so I turn to you ... Regards. PE <http://home.gna.org/ldapcppei/Frontends/Howto-7.fr.html#ss7.2>

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