From users-return-19451-apmail-jackrabbit-users-archive=jackrabbit.apache.org@jackrabbit.apache.org Wed Feb 13 12:30:33 2013
Return-Path:
X-Original-To: apmail-jackrabbit-users-archive@minotaur.apache.org
Delivered-To: apmail-jackrabbit-users-archive@minotaur.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
by minotaur.apache.org (Postfix) with SMTP id 84FABE9B6
for ; Wed, 13 Feb 2013 12:30:33 +0000 (UTC)
Received: (qmail 27913 invoked by uid 500); 13 Feb 2013 12:30:33 -0000
Delivered-To: apmail-jackrabbit-users-archive@jackrabbit.apache.org
Received: (qmail 27616 invoked by uid 500); 13 Feb 2013 12:30:26 -0000
Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
List-Help:
List-Unsubscribe:
List-Post:
List-Id:
Reply-To: users@jackrabbit.apache.org
Delivered-To: mailing list users@jackrabbit.apache.org
Received: (qmail 27574 invoked by uid 99); 13 Feb 2013 12:30:25 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 13 Feb 2013 12:30:25 +0000
X-ASF-Spam-Status: No, hits=-0.7 required=5.0
tests=RCVD_IN_DNSWL_LOW,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of anchela@adobe.com designates 64.18.1.234 as permitted sender)
Received: from [64.18.1.234] (HELO exprod6og119.obsmtp.com) (64.18.1.234)
by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 13 Feb 2013 12:30:18 +0000
Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob119.postini.com ([64.18.5.12]) with SMTP
ID DSNKURuHRRYaY8BcNaXLHYRvr+OHjlHWhaYj@postini.com; Wed, 13 Feb 2013 04:29:58 PST
Received: from inner-relay-4.eur.adobe.com (inner-relay-4.adobe.com [193.104.215.14])
by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r1DCQr1v022330
for ; Wed, 13 Feb 2013 04:26:53 -0800 (PST)
Received: from nahub02.corp.adobe.com (nahub02.corp.adobe.com [10.8.189.98])
by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id r1DCTsXM021790
for ; Wed, 13 Feb 2013 04:29:55 -0800 (PST)
Received: from eurhub01.eur.adobe.com (10.128.4.30) by nahub02.corp.adobe.com
(10.8.189.98) with Microsoft SMTP Server (TLS) id 8.3.297.1; Wed, 13 Feb 2013
04:29:54 -0800
Received: from angela.corp.adobe.com (10.132.1.18) by eurhub01.eur.adobe.com
(10.128.4.111) with Microsoft SMTP Server id 8.3.297.1; Wed, 13 Feb 2013
12:29:53 +0000
Message-ID: <511B8741.8090307@adobe.com>
Date: Wed, 13 Feb 2013 13:29:53 +0100
From: Angela Schreiber
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:
Subject: Re: How does Jackrabbit resolve ACL permissions?
References: <14F1ECB22F0236499AD4A9F17DD292E243D85B@BPVMEMBP01.qualysoft.hu>
In-Reply-To: <14F1ECB22F0236499AD4A9F17DD292E243D85B@BPVMEMBP01.qualysoft.hu>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Checked: Checked by ClamAV on apache.org
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
>
> www.qualysoft.at
>
> marian.schedenig@infinica.at
>
> *P**Please consider the environment before printing this email*
>