openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

(ITS#5651) pthread error in configure
by edpena＠cisco.com 09 Aug '08

09 Aug '08

Full_Name: Ed Pena Version: openldap-2.3.39 OS: hpux 11.11 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (64.102.254.33) checking pthread.h usability... no checking pthread.h presence... yes configure: WARNING: pthread.h: present but cannot be compiled configure: WARNING: pthread.h: check for missing prerequisite headers? configure: WARNING: pthread.h: see the Autoconf documentation configure: WARNING: pthread.h: section "Present But Cannot Be Compiled" configure: WARNING: pthread.h: proceeding with the preprocessor's result configure: WARNING: pthread.h: in the future, the compiler will take precedence configure: WARNING: ## --------------------------------------------- ## configure: WARNING: ## Report this to <http://www.openldap.org/its/> ## configure: WARNING: ## --------------------------------------------- ## checking for pthread.h... yes

1 0

Re: (ITS#5628) dereferencing user with translucent overlay
by hyc＠symas.com 09 Aug '08

09 Aug '08

Pierangelo Masarati wrote: > hyc(a)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/

1 0

Re: (ITS#5628) dereferencing user with translucent overlay
by ando＠sys-net.it 09 Aug '08

09 Aug '08

hyc(a)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(a)sys-net.it -----------------------------------

1 0

(ITS#5650) The bdb_entry_get() call ignores the attribute arg
by ando＠sys-net.it 09 Aug '08

09 Aug '08

Full_Name: Pierangelo Masarati Version: HEAD/re24/re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Submitted by: ando The call bdb_entry_get() ignores the attribute description passed as arg, returning the entry if it exists and if it belongs to the objectClass optionally passed as arg. The fix is trivial: check if the attribute is present in the entry. The only question is: should we also check for subtypes? Right now, I'm fixing it for strict attribute type. p.

1 0

Re: problem with ldap backend / rwm overlay (ITS#5647)
by brett.maxfield＠gmail.com 09 Aug '08

09 Aug '08

------=_Part_137280_15866481.1218285287040 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Works exactly as it should, extra attributes are now hidden :) Thanks very much. Brett On Sat, Aug 9, 2008 at 7:02 PM, Pierangelo Masarati < openldap-its(a)openldap.org> wrote: > Should be fixed now in HEAD, for both slapo-rwm and slapd-meta. Please > test. > > p. > ------=_Part_137280_15866481.1218285287040 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline <div dir="ltr">Works exactly as it should, extra attributes are now hidden :)<br><br>Thanks very much.<br><br>Brett<br><br><div class="gmail_quote">On Sat, Aug 9, 2008 at 7:02 PM, Pierangelo Masarati <span dir="ltr"><<a href="mailto:openldap-its@openldap.org">openldap-its(a)openldap.org</a>></span> wrote:<br> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Should be fixed now in HEAD, for both slapo-rwm and slapd-meta.  Please test.<br> <font color="#888888"><br> p.<br> </font></blockquote></div><br></div> ------=_Part_137280_15866481.1218285287040--

1 0

Re: (ITS#5628) dereferencing user with translucent overlay
by hyc＠symas.com 09 Aug '08

09 Aug '08

ando(a)sys-net.it wrote: > kouk(a)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/

1 0

Re: (ITS#5618) better error messages for syncrepl failure
by hyc＠symas.com 09 Aug '08

09 Aug '08

henson(a)acm.org wrote: > Full_Name: Paul B. Henson > Version: 2.3.40 > OS: Gentoo > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (134.71.248.24) > > > I recently installed some updates and configuration changes on one of my > LDAP slaves. Replication broke mysteriously after that. The only thing logged > was "slapd[30723]: do_syncrepl: rid 001 retrying (9 retries left)" > > I finally figured out that the search was failing with a protocol error because > derefAliases was set to always, a setting I had just added. It would be useful > if replication failure provided better error messages, something in the logs > indicating that a protocol error had occurred because of an invalid > dereferencing setting would have saved me a lot of time. An additional log message for this situation has been added. > In addition, if it is a protocol error to dereference aliases in the context of > syncrepl, shouldn't the server just ignore that global configuration setting and > just do the right thing? A patch has been applied to always set Deref to Never. These changes are in CVS HEAD, please test. -- -- 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

Re: (ITS#5628) dereferencing user with translucent overlay
by ando＠sys-net.it 09 Aug '08

09 Aug '08

kouk(a)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(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5627) set syntax in ACI's
by ando＠sys-net.it 09 Aug '08

09 Aug '08

Can't find the patch; however, the problem should now be fixed, thanks. Please test. 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#5637) dynacl broken when an access mask has been already applied by previous ACL rule
by ando＠sys-net.it 09 Aug '08

09 Aug '08

Fixed in HEAD, thanks. Please test. 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

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