OpenLDAP
Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest

Viewing Development/5724
Full headers

From: Guillaume.Rousse@inria.fr
Subject: back-relay doesn't expose underlying database controls correctly
Compose comment
Download message
State:
0 replies:
6 followups: 1 2 3 4 5 6

Major security issue: yes  no

Notes:

Notification:


Date: Sun, 5 Oct 2008 15:42:21 GMT
From: Guillaume.Rousse@inria.fr
To: openldap-its@OpenLDAP.org
Subject: back-relay doesn't expose underlying database controls correctly
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=""


Followup 1

Download message
Date: Sun, 05 Oct 2008 20:38:28 +0200
From: Pierangelo Masarati <ando@sys-net.it>
To: Guillaume.Rousse@inria.fr
CC: openldap-its@openldap.org
Subject: Re: (ITS#5724) back-relay doesn't expose underlying database controls
 correctly
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@sys-net.it
-----------------------------------



Followup 2

Download message
Date: Sun, 05 Oct 2008 21:19:04 +0200
From: Pierangelo Masarati <ando@sys-net.it>
To: openldap-its@openldap.org
Subject: ITS#5724 (Re: commit: ldap/servers/slapd backover.c)
ando@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@sys-net.it
-----------------------------------



Followup 3

Download message
Date: Sun, 05 Oct 2008 15:55:06 -0700
From: Howard Chu <hyc@symas.com>
To: ando@sys-net.it
CC: openldap-its@openldap.org
Subject: Re: ITS#5724 (Re: commit: ldap/servers/slapd backover.c)
ando@sys-net.it wrote:
> ando@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/



Followup 4

Download message
Date: Mon, 06 Oct 2008 07:41:34 +0200
From: Pierangelo Masarati <ando@sys-net.it>
To: Howard Chu <hyc@symas.com>
CC: openldap-its@openldap.org
Subject: Re: ITS#5724 (Re: commit: ldap/servers/slapd backover.c)
Howard Chu wrote:
> ando@sys-net.it wrote:
>> ando@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@sys-net.it
-----------------------------------



Followup 5

Download message
Date: Mon, 06 Oct 2008 19:30:37 +0200
From: Pierangelo Masarati <ando@sys-net.it>
To: openldap-its@openldap.org
Subject: Re: ITS#5724 (Re: commit: ldap/servers/slapd backover.c)
ando@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 :(

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@sys-net.it
-----------------------------------



Followup 6

Download message
Date: Thu, 19 Feb 2009 15:16:50 -0800
From: Howard Chu <hyc@symas.com>
To: ando@sys-net.it
CC: openldap-its@openldap.org
Subject: Re: ITS#5724 (Re: commit: ldap/servers/slapd backover.c)
ando@sys-net.it wrote:
> ando@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/


Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest


The OpenLDAP Issue Tracking System uses a hacked version of JitterBug

______________
© Copyright 2013, OpenLDAP Foundation, info@OpenLDAP.org