jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lars Michele <lars.mich...@tu-dortmund.de>
Subject Re: Groups Deny, DefaultAccessManager
Date Sat, 25 Apr 2009 14:40:51 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message