From users-return-19450-apmail-jackrabbit-users-archive=jackrabbit.apache.org@jackrabbit.apache.org Wed Feb 13 10:34:29 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 2F12DDA84 for ; Wed, 13 Feb 2013 10:34:29 +0000 (UTC) Received: (qmail 26013 invoked by uid 500); 13 Feb 2013 10:34:28 -0000 Delivered-To: apmail-jackrabbit-users-archive@jackrabbit.apache.org Received: (qmail 25728 invoked by uid 500); 13 Feb 2013 10:34:28 -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 25699 invoked by uid 99); 13 Feb 2013 10:34:26 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 13 Feb 2013 10:34:26 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of prvs=4756A29561=Marian.Schedenig@qualysoft.com designates 213.253.200.123 as permitted sender) Received: from [213.253.200.123] (HELO ns.qualysoft.hu) (213.253.200.123) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 13 Feb 2013 10:34:19 +0000 Received: from BPVMEMBP01.qualysoft.hu ([fe80::f5ae:4ae7:505e:4a0d]) by BPVMECHP02.qualysoft.hu ([fe80::8810:bc7:649a:b134%17]) with mapi id 14.02.0328.009; Wed, 13 Feb 2013 11:34:38 +0100 From: SCHEDENIG Marian To: "users@jackrabbit.apache.org" Subject: How does Jackrabbit resolve ACL permissions? Thread-Topic: How does Jackrabbit resolve ACL permissions? Thread-Index: Ac4J1bS82YscC199RuGGfW1xAsBQTw== Date: Wed, 13 Feb 2013 10:34:37 +0000 Message-ID: <14F1ECB22F0236499AD4A9F17DD292E243D85B@BPVMEMBP01.qualysoft.hu> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.1.2.130] Content-Type: multipart/related; boundary="_004_14F1ECB22F0236499AD4A9F17DD292E243D85BBPVMEMBP01qualyso_"; type="multipart/alternative" MIME-Version: 1.0 X-Virus-Checked: Checked by ClamAV on apache.org --_004_14F1ECB22F0236499AD4A9F17DD292E243D85BBPVMEMBP01qualyso_ Content-Type: multipart/alternative; boundary="_000_14F1ECB22F0236499AD4A9F17DD292E243D85BBPVMEMBP01qualyso_" --_000_14F1ECB22F0236499AD4A9F17DD292E243D85BBPVMEMBP01qualyso_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, we're using the standard ACLProvider for permission handling. We're now run= ning 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 EveryonePrincip= al) 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 fu= ll permissions to A on /a_folder and to B on /b_folder. This fails, apparen= tly 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 dif= ferent way to do it. 2. Deny full permissions to "everyone" on /a_folder and grant full permissi= ons to A on the same folder (and the same with "everyone" and B on /b_folde= r). This also fails, although apparently it works for user X if we deny "ev= eryone" 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 requi= rement? Thanks, Marian. -- DI Marian Schedenig Senior Developer [Description: Description: Description: Description: Description: Descripti= on: cid:image001.png@01CCBE64.F3314040] INFINICA - Member of Qualysoft Group Leonard-Bernstein-Stra=DFe 10 A-1220 Wien =D6sterreich 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 --_000_14F1ECB22F0236499AD4A9F17DD292E243D85BBPVMEMBP01qualyso_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

we’re using the standard ACLProvider for permi= ssion 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” (wh= ich 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.<= /p>

 

We’ve tried two approaches:

 

1. Deny full permissions to “everyone” o= n 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 dif= ferent way to do it.

 

2. Deny full permissions to “everyone” o= n /a_folder and grant full permissions to A on the same folder (and the sam= e with “everyone” and B on /b_folder). This also fails, althoug= h 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 rule= s for overlapping grants and denies on the same resource? And what is the c= orrect way to solve our requirement?

 

Thanks,

Marian.

DI Marian Schedenig

= Senior Developer

 

INFINICA - Member of Qualysoft Group

Leonard-Bernstein-Stra=DFe 10

A-1220 Wien

=D6sterreich

 

Tel +43 1 4095987-26

Fax +43 1 4095987-11

 

www.infin= ica.at

www.qual= ysoft.at

marian.schedenig@infinica.at

 

P<= span lang=3D"EN-US" style=3D"font-size:9.0pt;color:green;mso-fareast-langua= ge:DE-AT"> Please consider the environment before printing this email

 

--_000_14F1ECB22F0236499AD4A9F17DD292E243D85BBPVMEMBP01qualyso_-- --_004_14F1ECB22F0236499AD4A9F17DD292E243D85BBPVMEMBP01qualyso_--