Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of anchela@adobe.com designates
 64.18.1.31 as permitted sender)
Message-ID: <4E81E365.5010109@adobe.com>
Date: Tue, 27 Sep 2011 16:53:25 +0200
From: Angela Schreiber <anchela@adobe.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US;
 rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: "users@jackrabbit.apache.org" <users@jackrabbit.apache.org>
Subject: Re: AccessControlManagerget - Privileges(path) method problem
References: <1315204811293-3790533.post@n4.nabble.com>
 <1315430373148-3797303.post@n4.nabble.com>
 <1317120652284-3846776.post@n4.nabble.com>
 <1317127279511-3847131.post@n4.nabble.com>
In-Reply-To: <1317127279511-3847131.post@n4.nabble.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit

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.