openldap-bugs

openldap-bugs@openldap.org

1 participants
20965 discussions

Re: ITS#5724 (Re: commit: ldap/servers/slapd backover.c)
by ando＠sys-net.it 05 Oct '08

05 Oct '08

Howard Chu wrote: > ando(a)sys-net.it wrote: >> ando(a)OpenLDAP.org wrote: >> >>> Log Message: >>> open database using the real structure (partial fix to ITS#5724) >> >> We need a virtual database to inherit controls from the real database. >> Sharing the array of known controls could be a solution, but it wouldn't >> allow the virtual database to have specific controls, e.g. registered by >> an overlay. A solution would be to let the real database know it's >> related to virtual ones, so that modifications to the real database via >> back-config can be propagated to the virtual ones. This, of course, >> poses the problem that if a virtual database is deleted, any reference >> to it must be removed from the list of related databases. I wonder if >> all of this is worth the effort of exposing real controls by the virtual >> database. > > Since a single relay database may be configured to multiplex to many > other databases, and they may not all support the same set of controls, > this seems to be an exercise in futility. I guess it may be OK to just > advertise a union of all the real database controls, and perform an > extra restriction check before handing off processing. 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. 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#5724 (Re: commit: ldap/servers/slapd backover.c)
by hyc＠symas.com 05 Oct '08

05 Oct '08

ando(a)sys-net.it wrote: > ando(a)OpenLDAP.org wrote: > >> Log Message: >> open database using the real structure (partial fix to ITS#5724) > > We need a virtual database to inherit controls from the real database. > Sharing the array of known controls could be a solution, but it wouldn't > allow the virtual database to have specific controls, e.g. registered by > an overlay. A solution would be to let the real database know it's > related to virtual ones, so that modifications to the real database via > back-config can be propagated to the virtual ones. This, of course, > poses the problem that if a virtual database is deleted, any reference > to it must be removed from the list of related databases. I wonder if > all of this is worth the effort of exposing real controls by the virtual > database. Since a single relay database may be configured to multiplex to many other databases, and they may not all support the same set of controls, this seems to be an exercise in futility. I guess it may be OK to just advertise a union of all the real database controls, and perform an extra restriction check before handing off processing. -- -- 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#5726) syncrepl must look at runqueue also after successful connection
by rein＠OpenLDAP.org 05 Oct '08

05 Oct '08

Full_Name: Rein Tollevik Version: CVS head OS: linux, solaris URL: Submission from: (NULL) (84.215.36.97) Submitted by: rein The first fix to ITS#5454 in revision 1.392 appear to be wrong under curtain situations, runqueue manipulation must be done after a paused syncrepl connection is rescheduled. Ref: http://www.openldap.org/lists/openldap-devel/200810/msg00014.html It looks as if switching from trylock to lock at the start of do_syncrepl() should be the only fix for ITS#5454, and that the optimization this revision introduces should be reverted. I'll commit that shortly. Rein Tollevik Basefarm AS

1 0

Re: (ITS#5723) test046-dds failed
by ando＠sys-net.it 05 Oct '08

05 Oct '08

dieter(a)dkluenter.de wrote: > test046 fails due to insufficient access. Fixed in HEAD. 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

ITS#5724 (Re: commit: ldap/servers/slapd backover.c)
by ando＠sys-net.it 05 Oct '08

05 Oct '08

ando(a)OpenLDAP.org wrote: > Log Message: > open database using the real structure (partial fix to ITS#5724) We need a virtual database to inherit controls from the real database. Sharing the array of known controls could be a solution, but it wouldn't allow the virtual database to have specific controls, e.g. registered by an overlay. A solution would be to let the real database know it's related to virtual ones, so that modifications to the real database via back-config can be propagated to the virtual ones. This, of course, poses the problem that if a virtual database is deleted, any reference to it must be removed from the list of related databases. I wonder if all of this is worth the effort of exposing real controls by the virtual database. 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#5724) back-relay doesn't expose underlying database controls correctly
by ando＠sys-net.it 05 Oct '08

05 Oct '08

I have a fix for this issue when the relay database is configured *after* the relayed one. I'll commit it in a moment. However, this fix does not cure your case, where the virtual database needs to appear *before* the real one, and also does not cure similar issues related, for example, to run-time configuring modules that register controls on a real database (e.g. an overlay), which would not be echoed by the virtual database. 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#5723) test046-dds failed
by ando＠sys-net.it 05 Oct '08

05 Oct '08

dieter(a)dkluenter.de wrote: > Full_Name: Dieter > Version: HEAD > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.142.238.55) > > > Hello, > test046 fails due to insufficient access. > > slapd.1.log: > > ==> bdb_add: cn=Meeting,ou=Groups,dc=example,dc=com > oc_check_required entry (cn=Meeting,ou=Groups,dc=example,dc=com), objectClass > "g > roupOfNames" > oc_check_required entry (cn=Meeting,ou=Groups,dc=example,dc=com), objectClass > "d > ynamicObject" > oc_check_allowed type "objectClass" > oc_check_allowed type "cn" > oc_check_allowed type "member" > oc_check_allowed type "entryTtl" > oc_check_allowed type "entryExpireTimestamp" > oc_check_allowed type "structuralObjectClass" > bdb_dn2entry("cn=meeting,ou=groups,dc=example,dc=com") > => bdb_dn2id("cn=meeting,ou=groups,dc=example,dc=com") > <= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30989) > dnMatch 0 > "cn=bjorn jensen,ou=information technology > division,ou=people,dc=example > ,dc=com" > "cn=bjorn jensen,ou=information technology > division,ou=people,dc=example > ,dc=com" > bdb_add: no write access to attribute > send_ldap_result: conn=21 op=1 p=3 > send_ldap_result: err=50 matched="" text="no write access to attribute" > send_ldap_response: msgid=2 tag=105 err=50 > ber_flush2: 42 bytes to sd 13 > conn=21 op=1 RESULT tag=105 err=50 text=no write access to attribute > connection_get(13) Looks like another side effect of checking write permission on attributes during add. At this point, I suspect we'd better add a configure switch that allows restore the old behavior. The switch could be removed as soon as obsolete, much like what occurred to schemacheck. 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

(ITS#5725) Connection enabled for events twice
by rein＠OpenLDAP.org 05 Oct '08

05 Oct '08

Full_Name: Rein Tollevik Version: CVS head OS: Linux 2.6 URL: Submission from: (NULL) (84.215.36.97) Submitted by: rein connection_client_setup() enables the connection for events twice, causing race conditions that can create deadlock situations. Ref: http://www.openldap.org/lists/openldap-devel/200810/msg00014.html A fix that removes the unnecessary call to slapd_set_read() will be committed soon. Rein Tollevik Basefarm AS

1 0

(ITS#5724) back-relay doesn't expose underlying database controls correctly
by Guillaume.Rousse＠inria.fr 05 Oct '08

05 Oct '08

Full_Name: Guillaume Rousse Version: 2.4.11 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.224.237.5) Here is a simple relay configuration: database relay suffix ou=telephony,dc=msr-inria,dc=inria,dc=fr overlay rwm rwm-suffixmassage ou=users,dc=msr-inria,dc=inria,dc=fr rwm-map attribute telephoneNumber homePhone rwm-map attribute telephoneNumber database bdb suffix "dc=msr-inria,dc=inria,dc=fr" rootdn "cn=root,dc=msr-inria,dc=inria,dc=fr" However, queries with critical pagedResult control fails: Oct 2 14:07:29 etoile slapd[30006]: conn=118 op=1 SRCH base="ou=telephony,dc=msr-inria,dc=inria,dc=fr" scope=2 deref=3 filter="(objectClass=inetOrgPerson)" Oct 2 14:07:29 etoile slapd[30006]: conn=118 op=1 SRCH attr=uid givenname initials sn manager departmentnumber telephonenumber mail title homephone mobile pager Oct 2 14:07:29 etoile slapd[30006]: conn=118 op=1 SEARCH RESULT tag=101 err=12 nentries=0 text=critical control unavailable in context Oct 2 14:16:15 etoile slapd[6002]: => get_ctrls Oct 2 14:16:15 etoile slapd[6002]: => get_ctrls: oid="1.2.840.113556.1.4.319" (critical) Oct 2 14:16:15 etoile slapd[6002]: <= get_ctrls: n=1 rc=0 err=""

1 0

(ITS#5723) test046-dds failed
by dieter＠dkluenter.de 05 Oct '08

05 Oct '08

Full_Name: Dieter Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.142.238.55) Hello, test046 fails due to insufficient access. slapd.1.log: ==> bdb_add: cn=Meeting,ou=Groups,dc=example,dc=com oc_check_required entry (cn=Meeting,ou=Groups,dc=example,dc=com), objectClass "g roupOfNames" oc_check_required entry (cn=Meeting,ou=Groups,dc=example,dc=com), objectClass "d ynamicObject" oc_check_allowed type "objectClass" oc_check_allowed type "cn" oc_check_allowed type "member" oc_check_allowed type "entryTtl" oc_check_allowed type "entryExpireTimestamp" oc_check_allowed type "structuralObjectClass" bdb_dn2entry("cn=meeting,ou=groups,dc=example,dc=com") => bdb_dn2id("cn=meeting,ou=groups,dc=example,dc=com") <= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30989) dnMatch 0 "cn=bjorn jensen,ou=information technology division,ou=people,dc=example ,dc=com" "cn=bjorn jensen,ou=information technology division,ou=people,dc=example ,dc=com" bdb_add: no write access to attribute send_ldap_result: conn=21 op=1 p=3 send_ldap_result: err=50 matched="" text="no write access to attribute" send_ldap_response: msgid=2 tag=105 err=50 ber_flush2: 42 bytes to sd 13 conn=21 op=1 RESULT tag=105 err=50 text=no write access to attribute connection_get(13) -Dieter

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