jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Boston <...@tfd.co.uk>
Subject Re: Groups Deny, DefaultAccessManager
Date Sun, 26 Apr 2009 07:30:29 GMT
Lars,
Thank you, the explanation makes sense. Its the order independence of  
the ACL and the fact that everything is or'd together that makes a  
deny in group pointless, rather than an explicit design decision. The  
approach you suggest to achieving the private subfolder is perfectly  
workable.

Presumably this policy is expressed inside the implementation of the  
AccessControlProvider where the ACL is compiled.
Since this class is defined in the repository.xml would it be the  
right place extend or change the behavior *if* I wanted to ? ( I have  
some other use cases that may need to address if the standard impl  
doesnt cover them)

Thanks
Ian
On 25 Apr 2009, at 15:40, Lars Michele wrote:

> Just a correction...
> Lars Michele schrieb:
>> Hi,
>>
>>> I notice the Access Control Elements with a deny statement don't get
>>> added to a ACE relating to a Group Principal.
>>>
>>> Does any one know the reason for this ? Is it part of the Spec ?
>>>
>> I do not know if it is part of the spec, but when you comment it  
>> out, it
>> works and I have not found a drawback yet.
>>
>>> We have use cases where we want to grant part of a tree to a group  
>>> and
>>> then deny a subtree to the main group and grant to a smaller  
>>> group. At
>>> the moment, it looks like DACM wont do this for us, we could write  
>>> our
>>> own (in fact we did for JR 14), but I dont really want to drift too
>>> far from anything in the spec.
>>>
>> If the check is removed, following rules work.
>>
>> The principal "everybody" has read rights on the node, which is
>> important, so that every (authenticated) user can access the  
>> repository.
>> If you want to make a subdirectory protected, you just set a "deny  
>> all"
>> rule for "everybody" on this directory and add the appropriate rights
>> for the desired groups with access rights. So it does, what it  
>> should do.
>>
>> What rules count:
>> Because the rules get computed by "OR", an "allow" counts more than a
>> "deny". That means if you set a "deny all" on group1 and "allow  
>> all" on
>> group2 and a user is in both groups (I know, you never should do
>> something like this)
>
> In fact, you do something like this. I am a little bit gaga. My  
> example
> with the group "everybody" shows, that you have to do something like
> this ;-)
>
>> , the "allow all" wins.
>> A user rule always wins against a group rule.
>> The order of the rules in the ACLs is *NOT* important!
>>
>> I hope, that helps.
>>
>> Lars
>>
>


Mime
View raw message