jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@adobe.com>
Subject Re: AccessControlManagerget - Privileges(path) method problem
Date Tue, 27 Sep 2011 14:53:25 GMT
the current implementation applies the following rules:

1 ace for user principal is always weighted higher than ace for group
2 inherited aces are weighted lower than those defined on the target
3 within an acl the aces for groups are evaluated in the order they
   are defined

thus: if you define a ace for a non-group principal it will always
overrule the effect of those ace defined for a group even if inherited
or ordered before the group-ace.

the reason for this is that from the experience we gained with
our products, user-aces are hard to maintain and are only used
to allow/deny permissions for a user irrespective of any groups
that user may be member of.

regards
angela

On 9/27/11 2:41 PM, bobofer wrote:
> I played little more with ACLs and discover this.
> If Tom is member of DEV and USR group and if ACEs are arranged like this,
> DEV – jcr:write
> USR – jcr:read
> the Tom has jcr:read privilege( witch is wrong).
>
> But if I ACEs arrange like this,
> DEV – jcr:read
> USR – jcr:write
> the Tom has jcr:write privilege(right one).
>
> My conclusion is that Tom gets privileges from LAST principal in ACL, in
> this case USR group.
>
> Any ideas how to fix this?
>
> --
> View this message in context: http://jackrabbit.510166.n4.nabble.com/AccessControlManagerget-Privileges-path-method-problem-tp3790533p3847131.html
> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.

Mime
View raw message