openldap-bugs January 2008

openldap-bugs@openldap.org

36 participants
144 discussions

Re: (ITS#5328) backends sending/setting results
by h.b.furuseth＠usit.uio.no 18 Jan '08

18 Jan '08

ando(a)sys-net.it writes: >h.b.furuseth(a)usit.uio.no wrote: >> Back-relay operations can be factored out to something like this: >> (...) >> return relay_back_op( op, rs, bd, bd->be_cancel, Fail_send ); > > ^^^ cancel should __NOT__ send response, since it's an extended > operation. (...) Good catch. >> return relay_back_op( op, rs, bd, bd->be_extended, Fail_unwilling ); >> return relay_back_op( op, rs, bd, bd->be_chk_referrals, Fail_0 ); >> return relay_back_op( op, rs, bd, bd->be_operational, Fail_1 ); > > I like the idea, but that's slightly too simple. The reason I didn't > try to synthesize calls like that was the need to also handle more > complex combinations. For this reason, I'm actually considering the use > of a mask to fine-grain drive the behavior of the helper. And your commit looks nice. Actually what I intended to say was "the _current_ back-relay code can be factored out to...". I didn't know which of it was correct. -- Regards, Hallvard

1 0

Re: (ITS#5328) backends sending/setting results
by ando＠sys-net.it 16 Jan '08

16 Jan '08

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: Linux > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > back-relay's be_extended could send a result, but be_extended should > only set/return it and leave it to the frontend to send it. > Just fixed by Pierangelo. > > Looking at the code, some overlays also send results when used as > be_extended: pcache:pcache_op_privdb(), retcode, rwm, slapi_overlay. > > > More about back-relay: > > - it fails to send anything if the Delete operation is not supported. > > - be_abandon, be_chk_referrals and be_operational can return either an > LDAP result code, or 0 or 1 (which become success and operationError > if they get used as result codes). I don't know if that matters. > > Back-relay operations can be factored out to something like this: > > int > relay_back_op( > Operation *op, > SlapReply *rs, > BackendDB *bd, > BI_op_func *func, > Fail_Type fail_mode ) > { > int rc = fail_mode; > > if ( func ) { > BackendDB *be = op->o_bd; > slap_callback cb; > > relay_back_add_cb( &cb, op ); > > op->o_bd = bd; > rc = func( op, rs ); > op->o_bd = be; > > if ( op->o_callback == &cb ) { > op->o_callback = op->o_callback->sc_next; > } > > } else if ( fail_mode > Fail_1 ) { > rc = rs->sr_err = LDAP_UNWILLING_TO_PERFORM; > rs->sr_text = "operation not supported within naming context"; > if ( fail_mode == Fail_send ) { > send_ldap_result( op, rs ); > rc = 1; > } > } > > return rc; > } > > ... > return relay_back_op( op, rs, bd, bd->be_bind, Fail_send ); > (void) relay_back_op( op, rs, bd, bd->be_unbind, Fail_0 ); return 0; > return relay_back_op( op, rs, bd, bd->be_search, Fail_send ); > return relay_back_op( op, rs, bd, bd->be_compare, Fail_send ); > return relay_back_op( op, rs, bd, bd->be_modify, Fail_send ); > return relay_back_op( op, rs, bd, bd->be_modrdn, Fail_send ); > return relay_back_op( op, rs, bd, bd->be_add, Fail_send ); > return relay_back_op( op, rs, bd, bd->be_delete, Fail_send ); > return relay_back_op( op, rs, bd, bd->be_abandon, Fail_1 ); > return relay_back_op( op, rs, bd, bd->be_cancel, Fail_send ); ^^^ cancel should __NOT__ send response, since it's an extended operation. On the contrary, it should set op->o_cancel if it couldn't relay the operation, otherwise the cancel thread would yield forever. > return relay_back_op( op, rs, bd, bd->be_extended, Fail_unwilling ); > return relay_back_op( op, rs, bd, bd->be_chk_referrals, Fail_0 ); > return relay_back_op( op, rs, bd, bd->be_operational, Fail_1 ); I like the idea, but that's slightly too simple. The reason I didn't try to synthesize calls like that was the need to also handle more complex combinations. For this reason, I'm actually considering the use of a mask to fine-grain drive the behavior of the helper. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5328) backends sending/setting results
by h.b.furuseth＠usit.uio.no 16 Jan '08

16 Jan '08

I wrote: > Back-relay operations ...as of today... > can be factored out to something like this: > (...) Oops, I forgot: typedef enum { Fail_0 = 0, Fail_1 = 1, Fail_unwilling, Fail_send } Fail_Type; -- Hallvard

1 0

(ITS#5329) back-ldif deadlock
by h.b.furuseth＠usit.uio.no 16 Jan '08

16 Jan '08

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard back-ldif deadlocks on Modify access control in test006-acls (modified to support back-ldif). It tries to lock li_rdwr for both write (for the modify) and read (reading entries for access control) at the same time. However the manpage says The LDIF backend does not honor any of the access control semantics described in slapd.access(5). Only read (=r) access to the entry pseudo-attribute and to the other attribute values of the entries returned by the search operation is honored, which is performed by the frontend. Should the manpage be updated (and maybe more acl calls be added), or should the acl call be removed? Assuming the acl call should be there, one simple fix could be to introduce a 'li_wlock' mutex, lock it early on LDAP update operations, and delay locking li_rdwr until the operation is about to update the database. That can also get rid of the entry2str_mutex abuse. I've written a patch and it works, but something broke test045. Will look again later, if we are to keep the acl call(s).

1 0

(ITS#5328) backends sending/setting results
by h.b.furuseth＠usit.uio.no 16 Jan '08

16 Jan '08

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard back-relay's be_extended could send a result, but be_extended should only set/return it and leave it to the frontend to send it. Just fixed by Pierangelo. Looking at the code, some overlays also send results when used as be_extended: pcache:pcache_op_privdb(), retcode, rwm, slapi_overlay. More about back-relay: - it fails to send anything if the Delete operation is not supported. - be_abandon, be_chk_referrals and be_operational can return either an LDAP result code, or 0 or 1 (which become success and operationError if they get used as result codes). I don't know if that matters. Back-relay operations can be factored out to something like this: int relay_back_op( Operation *op, SlapReply *rs, BackendDB *bd, BI_op_func *func, Fail_Type fail_mode ) { int rc = fail_mode; if ( func ) { BackendDB *be = op->o_bd; slap_callback cb; relay_back_add_cb( &cb, op ); op->o_bd = bd; rc = func( op, rs ); op->o_bd = be; if ( op->o_callback == &cb ) { op->o_callback = op->o_callback->sc_next; } } else if ( fail_mode > Fail_1 ) { rc = rs->sr_err = LDAP_UNWILLING_TO_PERFORM; rs->sr_text = "operation not supported within naming context"; if ( fail_mode == Fail_send ) { send_ldap_result( op, rs ); rc = 1; } } return rc; } ... return relay_back_op( op, rs, bd, bd->be_bind, Fail_send ); (void) relay_back_op( op, rs, bd, bd->be_unbind, Fail_0 ); return 0; return relay_back_op( op, rs, bd, bd->be_search, Fail_send ); return relay_back_op( op, rs, bd, bd->be_compare, Fail_send ); return relay_back_op( op, rs, bd, bd->be_modify, Fail_send ); return relay_back_op( op, rs, bd, bd->be_modrdn, Fail_send ); return relay_back_op( op, rs, bd, bd->be_add, Fail_send ); return relay_back_op( op, rs, bd, bd->be_delete, Fail_send ); return relay_back_op( op, rs, bd, bd->be_abandon, Fail_1 ); return relay_back_op( op, rs, bd, bd->be_cancel, Fail_send ); return relay_back_op( op, rs, bd, bd->be_extended, Fail_unwilling ); return relay_back_op( op, rs, bd, bd->be_chk_referrals, Fail_0 ); return relay_back_op( op, rs, bd, bd->be_operational, Fail_1 );

1 0

Re: (ITS#5308) test034-translucent crashes with back-ldif
by h.b.furuseth＠usit.uio.no 15 Jan '08

15 Jan '08

ando(a)sys-net.it writes: > It is now fixed in HEAD; please test. Please, also check and test for > any side-effect introduced by the fix, as it impacts all calls to > str2entry (many, I believe). Tested, works fine so far. Haven't looked much for those side effects though. Would need to dig in the code and then construct test cases for it, I guess. -- Hallvard

1 0

Re: (ITS#5326) Add could re-build entry's DN using parent's DN and entry's RDN
by hyc＠symas.com 15 Jan '08

15 Jan '08

1 0

Re: (ITS#5326) Add could re-build entry's DN using parent's DN and entry's RDN
by ando＠sys-net.it 15 Jan '08

15 Jan '08

h.b.furuseth(a)usit.uio.no wrote: > ando(a)sys-net.it writes: >> I understand that unfortunately in slapadd this would require either >> to keep track of inserted DNs, or to issue quite a few be_entry_get(), >> possibly resulting in a sensible penalization. Perhaps it could be an >> option, relying on the fact that slapadd is basically intended to >> operate on "well-behaved" data? > > It had better, since slapadd accepts entries out of order. (It returns > failure at the end if some child has not received a parent.) This could be treated specially by performing renames as soon as info becomes available. This pushes more and more towards making this either an option or a no-go for slapadd (i.e. rely on LDIF massaging to have things nice). Note that having data not compliant with the requirement of this ITS would by no means be a violation of LDAP nor cause any operational issue to slapd. It would just be a matter of having more well-behaved data if this does not impact too much operations (and it shouldn't for run-time adds, since we already lookup the parent when adding an entry). 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5326) Add could re-build entry's DN using parent's DN and entry's RDN
by h.b.furuseth＠usit.uio.no 15 Jan '08

15 Jan '08

ando(a)sys-net.it writes: > I understand that unfortunately in slapadd this would require either > to keep track of inserted DNs, or to issue quite a few be_entry_get(), > possibly resulting in a sensible penalization. Perhaps it could be an > option, relying on the fact that slapadd is basically intended to > operate on "well-behaved" data? It had better, since slapadd accepts entries out of order. (It returns failure at the end if some child has not received a parent.) -- Hallvard

1 0

Re: (ITS#5327) slapo-constraint seg faults on regex
by ando＠sys-net.it 15 Jan '08

15 Jan '08

michael(a)stroeder.com wrote: > Guess it's not that helpful: No problem, easy to reproduce (as much as easy to fix :) 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

← Newer
1
2
3
4
5
6
7
8
9
...
15
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs January 2008