Re: Wishes for set ACLs

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 12:35 PM 3/17/2005, Howard Chu wrote:
>Kurt D. Zeilenga wrote:
>
>>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.
>> 
>Pretty sure all of that has worked for quite a while. Otherwise static groups would be triggering deadlocks all the time.

Static groups long ago suffered from this problem, but then we
added code to use to directly use the target if the target
was the group.   And, if we have to go get the group, we use
the same operation structure.  So, same locker id.  No problem.

The problem is where we spin off a new operation and hence
use a different locker id.

Kurt




>I don't think Ando's test would trigger any problems. More likely you would need at least two ACLs that create circular references, and attempt to modify both target entries.
>
>e.g.
>  access to uid=foo by group=bar write
>  access to group=bar by uid=foo write
>
>But I haven't tried it, so no guesses whether it's safe or broken.
>
>>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
>>>   
>>
>>
>>
>> 
>
>
>-- 
> -- Howard Chu
> Chief Architect, Symas Corp.       Director, Highland Sun
> http://www.symas.com               http://highlandsun.com/hyc
> Symas: Premier OpenSource Development and Support