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.
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 -----------------------------------
changed notes changed state Open to Suspended
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/
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 -----------------------------------
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/
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
need review
changed state Suspended to Open moved from Incoming to Software Bugs
requires adding entry_get to translucent overlay