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.
