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

Logged in as guest

Viewing Incoming/5628
Full headers

From: kouk@noc.uoa.gr
Subject: dereferencing user with translucent overlay
Compose comment
Download message
State:
0 replies:
5 followups: 1 2 3 4 5

Major security issue: yes  no

Notes:

Notification:


Date: Wed, 23 Jul 2008 15:30:28 GMT
From: kouk@noc.uoa.gr
To: openldap-its@OpenLDAP.org
Subject: dereferencing user with translucent overlay
Full_Name: Kostantinos Koukopoulos
Version: 2.4.11
OS: Solaris 9
URL: ftp://ftp.openldap.org/incoming/kostantinos-koukopoulos-080723-2.patch
Submission from: (NULL) (195.134.100.30)


When using the translucent overlay, if one tries to use set syntax in an ACL or
ACI rule, in order to dereference the bound user, like in the example below,
then the user's entry is fetched from the local database only. 

Example <who> clause:
by set="user/eduPersonOrgUnitDN & [ou=someunit,dc=someorg,dc=somecountry]"

If the 'eduPersonOrgUnitDN' attribute has not been modified it will not be found
in the local database. I believe it would be better if the remote database was
also checked, like when a search operation is performed against the overlay.

I found the problem was due to that acl_set_gather2 tries to fetch the attribute
directly from the backend, but the translucent overlay does not support this, so
the backend is used instead. I've attached a patch which makes acl_set_gather
always use an internal search operation to fetch the attribute, instead of
calling acl_set_gather2.

I've also tried to hack the translucent overlay so that it would support the
bi_entry_get_rw callback but I haven't been able to provide something that would
even satisfy me. I suppose I would have to use some sort of callback mechanism
like translucent_search_cb but I haven't figured it out yet.


Followup 1

Download message
Date: Sat, 09 Aug 2008 13:01:37 +0200
From: Pierangelo Masarati <ando@sys-net.it>
To: kouk@noc.uoa.gr
CC: openldap-its@openldap.org
Subject: Re: (ITS#5628) dereferencing user with translucent overlay
kouk@noc.uoa.gr wrote:
> Full_Name: Kostantinos Koukopoulos
> Version: 2.4.11
> OS: Solaris 9
> URL: ftp://ftp.openldap.org/incoming/kostantinos-koukopoulos-080723-2.patch
> Submission from: (NULL) (195.134.100.30)
> 
> 
> When using the translucent overlay, if one tries to use set syntax in an
ACL or
> ACI rule, in order to dereference the bound user, like in the example
below,
> then the user's entry is fetched from the local database only. 
> 
> Example <who> clause:
> by set="user/eduPersonOrgUnitDN &
[ou=someunit,dc=someorg,dc=somecountry]"
> 
> If the 'eduPersonOrgUnitDN' attribute has not been modified it will not be
found
> in the local database. I believe it would be better if the remote database
was
> also checked, like when a search operation is performed against the
overlay.
> 
> I found the problem was due to that acl_set_gather2 tries to fetch the
attribute
> directly from the backend, but the translucent overlay does not support
this, so
> the backend is used instead. I've attached a patch which makes
acl_set_gather
> always use an internal search operation to fetch the attribute, instead of
> calling acl_set_gather2.

Although I understand the spirit of the patch you propose, I'm not sure 
it is the right solution.  In fact, running an internal search like that 
implies that the whole overlay chain be run through.  Probably, that's 
correct in the case of the translucent overlay, though.  I need to think 
about it.  Any comments by others?

> I've also tried to hack the translucent overlay so that it would support
the
> bi_entry_get_rw callback but I haven't been able to provide something that
would
> even satisfy me. I suppose I would have to use some sort of callback
mechanism
> like translucent_search_cb but I haven't figured it out yet.

That's another problem I ran through when trying to add rewrite 
capabilities to the slapo-rwm(5) overlay, so that authorization could be 
rewrapped when performed through virtual data views.  However, I believe 
the API of bi_entry_get_rw be modified for overlays, since the current 
API does not allow calls to modify their arguments.  I'd leave that 
alone by now.

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: Sat, 09 Aug 2008 04:29:14 -0700
From: Howard Chu <hyc@symas.com>
To: ando@sys-net.it
CC: openldap-its@openldap.org
Subject: Re: (ITS#5628) dereferencing user with translucent overlay
ando@sys-net.it wrote:
> kouk@noc.uoa.gr wrote:
>> Full_Name: Kostantinos Koukopoulos
>> Version: 2.4.11
>> OS: Solaris 9
>> URL: ftp://ftp.openldap.org/incoming/kostantinos-koukopoulos-080723-2.patch
>> Submission from: (NULL) (195.134.100.30)
>>
>>
>> When using the translucent overlay, if one tries to use set syntax in
an ACL or
>> ACI rule, in order to dereference the bound user, like in the example
below,
>> then the user's entry is fetched from the local database only.
>>
>> Example<who>  clause:
>> by set="user/eduPersonOrgUnitDN& 
[ou=someunit,dc=someorg,dc=somecountry]"
>>
>> If the 'eduPersonOrgUnitDN' attribute has not been modified it will not
be found
>> in the local database. I believe it would be better if the remote
database was
>> also checked, like when a search operation is performed against the
overlay.
>>
>> I found the problem was due to that acl_set_gather2 tries to fetch the
attribute
>> directly from the backend, but the translucent overlay does not support
this, so
>> the backend is used instead. I've attached a patch which makes
acl_set_gather
>> always use an internal search operation to fetch the attribute, instead
of
>> calling acl_set_gather2.
>
> Although I understand the spirit of the patch you propose, I'm not sure
> it is the right solution.  In fact, running an internal search like that
> implies that the whole overlay chain be run through.  Probably, that's
> correct in the case of the translucent overlay, though.  I need to think
> about it.  Any comments by others?

Seems that we should add a backend_attribute handler to the translucent overlay.

>> I've also tried to hack the translucent overlay so that it would
support the
>> bi_entry_get_rw callback but I haven't been able to provide something
that would
>> even satisfy me. I suppose I would have to use some sort of callback
mechanism
>> like translucent_search_cb but I haven't figured it out yet.
>
> That's another problem I ran through when trying to add rewrite
> capabilities to the slapo-rwm(5) overlay, so that authorization could be
> rewrapped when performed through virtual data views.  However, I believe
> the API of bi_entry_get_rw be modified for overlays, since the current
> API does not allow calls to modify their arguments.  I'd leave that
> alone by now.

Haven't looked closely at this yet...
-- 
   -- 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 3

Download message
Date: Sat, 09 Aug 2008 16:03:55 +0200
From: Pierangelo Masarati <ando@sys-net.it>
To: hyc@symas.com
CC: openldap-its@openldap.org
Subject: Re: (ITS#5628) dereferencing user with translucent overlay
hyc@symas.com wrote:

> Seems that we should add a backend_attribute handler to the translucent
overlay.

That's not going to work anyway, since the overlay's bi_acl_attribute 
method is not going to be called anyway.  In fact, any call to 
backend_attribute will be cast into a call to bi_entry_get_rw, so only 
by implementing translucent_entry_get_rw we could have a chance to look 
the remote entry up.  But then we'd probably have issues in the 
subsequent call to translucent_entry_release, to distinguish whether the 
looked-up entry was from the local or the remote database...  And see 
ITS#5650: right now, even if the attribute is not local, the local entry 
will always be returned.

>>> I've also tried to hack the translucent overlay so that it would
support the
>>> bi_entry_get_rw callback but I haven't been able to provide
something that would
>>> even satisfy me. I suppose I would have to use some sort of
callback mechanism
>>> like translucent_search_cb but I haven't figured it out yet.
>> That's another problem I ran through when trying to add rewrite
>> capabilities to the slapo-rwm(5) overlay, so that authorization could
be
>> rewrapped when performed through virtual data views.  However, I
believe
>> the API of bi_entry_get_rw be modified for overlays, since the current
>> API does not allow calls to modify their arguments.  I'd leave that
>> alone by now.
> 
> Haven't looked closely at this yet...

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 4

Download message
Date: Sat, 09 Aug 2008 12:18:57 -0700
From: Howard Chu <hyc@symas.com>
To: Pierangelo Masarati <ando@sys-net.it>
CC: openldap-its@openldap.org
Subject: Re: (ITS#5628) dereferencing user with translucent overlay
Pierangelo Masarati wrote:
> hyc@symas.com wrote:
>
>> Seems that we should add a backend_attribute handler to the translucent
overlay.
>
> That's not going to work anyway, since the overlay's bi_acl_attribute
> method is not going to be called anyway.  In fact, any call to
> backend_attribute will be cast into a call to bi_entry_get_rw, so only
> by implementing translucent_entry_get_rw we could have a chance to look
> the remote entry up.  But then we'd probably have issues in the
> subsequent call to translucent_entry_release, to distinguish whether the
> looked-up entry was from the local or the remote database...  And see
> ITS#5650: right now, even if the attribute is not local, the local entry
> will always be returned.

I think in most cases the entry that translucent returns will have to be 
constructed from both local and remote anyway. In which case, 
translucent_release should just be a call to entry_free; the original local 
entry should be duplicated and released immediately.

>>>> I've also tried to hack the translucent overlay so that it
would support the
>>>> bi_entry_get_rw callback but I haven't been able to provide
something that would
>>>> even satisfy me. I suppose I would have to use some sort of
callback mechanism
>>>> like translucent_search_cb but I haven't figured it out yet.
>>> That's another problem I ran through when trying to add rewrite
>>> capabilities to the slapo-rwm(5) overlay, so that authorization
could be
>>> rewrapped when performed through virtual data views.  However, I
believe
>>> the API of bi_entry_get_rw be modified for overlays, since the
current
>>> API does not allow calls to modify their arguments.  I'd leave that
>>> alone by now.
>> Haven't looked closely at this yet...

-- 
   -- 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 5

Download message
From: "Aaron K. Reffett" <akreffett@cert.org>
To: "openldap-its@OpenLDAP.org" <openldap-its@OpenLDAP.org>
CC: "kouk@noc.uoa.gr" <kouk@noc.uoa.gr>
Date: Wed, 23 Mar 2011 16:00:34 -0400
Subject: Re: (ITS#5628) dereferencing user with translucent overlay
I ran in to this issue when attempting to enforce group ACLs on a translucent
proxy where all group information is stored on the proxied directory.

I implemented a hack in 2.3.43 (RHEL-5, we're a bit behind the times) to
implement bi_entry_get_rw on slapo-translucent and rewire calls within the
overlay from be_entry_get_rw to overlay_entry_get_ov.  To prevent internal calls
to be_entry_get_rw from invoking the new function (and potentially resulting in
infinite recursion) I reworked the calls to overlay_entry_get_ov to use
on->on_next instead of the top of the overlay stack.  I believe that this was
the original intent of these uses anyway to obtain the local-backend information
so the call should start at the next overlay, or directly to the underlying
database if there are no other overlays on the stack.  I also applied a small
patch to backover.c to support passing NULL to the on parameter of
overlay_entry_get_ov and its release function to signify that the bottom of the
overlay stack has been reached and to just call the backend database.  When
merging remote and local records the local records were duped and released
immediately and the dupes appended to the returned entry and the caller left
responsible to call entry_free.

I have not thoroughly tested this code and I will need to rewrite it for 2.4
anyway (when we move to it, hopefully later this year) but wanted to check if
there has been any progress on this issue that would obviate my need to port
this to 2.4.  If not, aside from what I described above am I missing any glaring
issues that I would need to address to get a complete solution to this issue?

Thanks,
Aaron Reffett


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