[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Wishes for set ACLs
I believe problem stems (or stemed) from bdb_entry_get not
realizing that it needs to pass up the DB_DEADLOCK error
instead of retrying. That is, there were cases where the
higher level transaction (boi->boi_txn) was masked or
otherwise hidden from bdb_entry_get.
If we fixed all of that, great.
Kurt
At 11:26 AM 3/17/2005, Pierangelo Masarati wrote:
>Kurt D. Zeilenga wrote:
>
>>At 07:36 AM 3/17/2005, Hallvard B Furuseth wrote:
>>
>>
>>>I've got a few wishes for set acls.
>>
>>I have one...
>>
>>1) avoid deadlock conditions
>>
>>
>It is unclear to me how deadlock could arise when using sets;
>value collection occurs via backend_attribute(), so, unless this function suffers from the problem, I don't see room for deadlocks. For instance, I assume that to cause a potential deadlock I should dereference an entry whose access control is being checked. For the purpose, I wrote the following (trivial, useless) set-based rule, using test003 data:
>
>access to dn.exact="cn=Bjorn Jensen,ou=Information Technology Division,ou=People,dc=example,dc=com"
> by set="[cn=all staff,ou=groups,dc=example,dc=com]/member/uid & this/uid" read
> by * auth
>
>This should cause the entry "cn=Bjorn Jensen,ou=Information Technology Division,ou=People,dc=example,dc=com" to be dereferenced (to lookup the "uid" attribute) while being checked for access. Well, this works fine even under heavy load (multiple clients simultaneously and repeatedly accessing that entry).
>
>Even the URI form:
>
>access to dn.exact="cn=Bjorn Jensen,ou=Information Technology Division,ou=People,dc=example,dc=com"
> by set="[ldap:///dc=example,dc=com??sub?(uid=bjorn)]/uid & this/uid" read
> by * auth
>
>which directly issues an internal search, in principle might incur in a deadlock, but it doesn't.
>
>Could you elaborate more on the issue?
>
>p.
>
>
> SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497