Hi Angela,
I suppose you wanted to make example as
+ b
+ rep:policy
+ allow
- jcr:primaryType = rep:GrantACE
- rep:principalName = groupB
- rep:privileges = [jcr:read]
--
Best regards,
Miroslav
On Wed, Feb 13, 2013 at 1:29 PM, Angela Schreiber <anch...@adobe.com> wrote:
> hi marian
>
> imo there shouldn't be any major obstacles in setting up the
> ACL to reflect the permissions as you describe below.
> in quickly tried it out on the crx-explorer using the following
> setup:
>
> groups
> ------------------------------**------------------------------**---
> - groupA
> - groupB
>
> users
> ------------------------------**------------------------------**---
> - userA: member of groupA (and everyone)
> - userB: member of groupB (and everyone)
> - userC: member of groupA and groupB (and everyone)
>
> acl setup
> ------------------------------**------------------------------**---
> + root
> + a
> + rep:policy
> + allow
> - jcr:primaryType = rep:GrantACE
> - rep:principalName = groupA
> - rep:privileges = [jcr:read]
> + b
> + rep:policy
> + allow
> - jcr:primaryType = rep:DenyACE
> - rep:principalName = groupB
> - rep:privileges = [jcr:read]
>
> result
> ------------------------------**------------------------------**---
>
> - userA can read /a but not /b
> - userB can read /b but not /a
> - userC can read /a and /b
>
> additional adding an DENY ace for everyone on the root is
> redundant and doesn't not have an effect on the result.
>
>
> general notes
> ------------------------------**------------------------------**---
>
> - ACEs are inherited through the node hierarchy. ACEs defined on
> a particular node take precedence over inherited onces.
> defining addition restrictions may be used to limit the effect to
> certain parts of the subtree defined by the access controlled node
>
> - as long as ACEs are defined from group principals the evaluation
> is strictly hierarchical. on a single ACL the order of ACEs matters.
>
> - if you define ACEs for non-group principal they will take predecence
> in any case: over the group principals and over the inheritance rule
> defined above.
>
> regarding your comments below:
> ------------------------------**------------------------------**---
>
> 1) that works for me... see above. in don't think you analysis
> matches the way the permissions are evaluated.
> 2) that would work as well but the ACE for everyone is redundant.
> it would not work if you would allow group A first and deny everyone
> group after that... as the ACE for A would become redundant.
>
> hope that helps
> angela
>
>
>
> On 2/13/13 11:34 AM, SCHEDENIG Marian wrote:
>
>> Hi,
>>
>> we’re using the standard ACLProvider for permission handling. We’re now
>> running into problems when trying to set up slightly more complex ACLs
>> than we’ve used so far:
>>
>> Say we have three groups, “everyone” (which is Jackrabbit’s
>> EveryonePrincipal) and “A” and “B”. We want to allow only users in the A
>> group to be able to access the folder /a_folder and only members of B to
>> access /b_folder. A user may be a member of A, B, A and B or of neither
>> group. If user X is a member of A and not a member of B, X should still
>> have access to /a_folder.
>>
>> We’ve tried two approaches:
>>
>> 1. Deny full permissions to “everyone” on the root folder and then grant
>> full permissions to A on /a_folder and to B on /b_folder. This fails,
>> apparently because permissions are resolved in a “top down” manner, and
>> as soon as it has been established that a user doesn’t have access to a
>> parent folder, its subfolders are no longer evaluated. That’s fine, if
>> we can find a different way to do it.
>>
>> 2. Deny full permissions to “everyone” on /a_folder and grant full
>> permissions to A on the same folder (and the same with “everyone” and B
>> on /b_folder). This also fails, although apparently it works for user X
>> if we deny “everyone” and grant X (specifically the user) on the folder.
>>
>> I’m now wondering: How exactly does Jackrabbit resolve permissions? Case
>> 1 seems to be clear, but what are the exact rules for overlapping grants
>> and denies on the same resource? And what is the correct way to solve
>> our requirement?
>>
>> Thanks,
>>
>> Marian.
>>
>> --
>>
>> *DI Marian Schedenig*
>>
>> Senior Developer
>>
>>
>> Description: Description: Description: Description: Description:
>> Description: cid:image001.png@01CCBE64.**F3314040
>>
>> INFINICA - Member of Qualysoft Group**
>>
>>
>> Leonard-Bernstein-Straße 10
>>
>> A-1220 Wien
>>
>> Österreich
>>
>> Tel +43 1 4095987-26
>>
>> Fax +43 1 4095987-11
>>
>> www.infinica.at <http://www.infinica.at/>
>>
>> www.qualysoft.at <http://www.qualysoft.at/>
>>
>> marian.schede...@infinica.at
>> <mailto:marian.schedenig@**infinica.at<marian.schede...@infinica.at>
>> >
>>
>> *P**Please consider the environment before printing this email*
>>
>>
