jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From SCHEDENIG Marian <Marian.Schede...@qualysoft.com>
Subject How does Jackrabbit resolve ACL permissions?
Date Wed, 13 Feb 2013 10:34:37 GMT

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?


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

Tel +43 1 4095987-26
Fax +43 1 4095987-11


P Please consider the environment before printing this email

  • Unnamed multipart/related (inline, None, 0 bytes)
View raw message