jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@adobe.com>
Subject Re: How does Jackrabbit resolve ACL permissions?
Date Fri, 01 Mar 2013 16:46:33 GMT
hi marian

sorry... you lost me :(
would it be possible for you to pack that information into test-cases,
run them on a standard jackrabbit setup and the provide the feedback
back to list (including the tests).

i hope this isn't too much of a burden for you. but it would
definitely help me understanding what you are struggling with.
your custom login module shouldn't have an impact here. if it does
then there might be something wrong with mapping between principals
in the subject and the principals stored in the AC content (see JCR-3439 
for an example that could lead to such a behavior)

the easiest and fasted way to write such test would probably be
to extend org.apache.jackrabbit.core.security.authorization.acl.WriteTest
- create your users and groups
- user adminSession to create the ac setup
- test for the expected outcome and document your expectations and
   where they are not met.

that class already contains some tests related to the inheritance,
so that give an idea on how to get started.

let me know if that would work for you.
kind regards
angela




On 2/28/13 3:16 PM, SCHEDENIG Marian wrote:
> Hi Angela,
>
> thanks again for your input. I finally got around to working on this again.
>
> On a single level, I made our permission concept work by making sure that deny enries
are always sorted before grant entries in our ACLs. I've also configured our repositories
to use SimpleWorkspaceAccessManager, which simply grants workspace access to all validated
users (we have a custom login module anyway which only allows access for specific users).
>
> I'm still struggling with inherited dependencies though. Perhaps I'm misunderstanding
something, but the way I see it, permissions are evaluated either 1) working downwards from
the root directory to the file in question or 2) upwards from the relevant file to the root
directory. In case 1), a privilege denied to a user on one level would be denied to the same
user for all sub levels as well. In case 2), sub levels could override the permissions by
granting the user the privilege again, i.e. users could be denied write access on the root
folder and then granted write access on their own home folder.
>
> I've written a couple of test cases, and neither option really seems to apply. I'll briefly
describe my test cases below; all of them consist of a simple structure with a main folder
"main", a sub folder "sub" and a file "file" in the sub folder. I'm setting permissions only
on folders (we generally don't use ACLs on files, as we've had issues with versioning). I'm
setting up the test cases as an admin user and then verifying the permission as User A. User
A belongs to the groups A_AND_B and ONLY_A. All users belong to the group everyone (which
maps to the EveryonePrinciple).
>
> Test A:
>
> Deny "all" to everyone on main, grant "all" to A_AND_B on sub. User cannot read main,
but can read sub and file, and can write new content to file. This is consistent with option
2 described above.
>
> Test B:
>
> Grant "write" to everyone on main, deny "write" to  A_AND_B on sub. User can read all
files andfolders, but cannot write new content to file. Also consistent with option 2.
>
>   Test C:
>
> Deny "read" and "write" to ONLY_A on main, grant "read" and "write" to everyone on sub.
User cannot read main, which is still consistent with option 2, but he can also not read sub
and file, or write content to the file. And this doesn't seem to fit any of the options I
described.
>
> Curiously when I change the deny to A_AND_B and the grant to ONLY_A, everything works
as expected again. Which could indicate that the order in which a user's groups are listed
(which is undefined in our case) has an influence on the effective permissions.
>
> Is there something else I'm missing here?
>
> Thx,
> Marian.
>
> -----Original Message-----
> From: Angela Schreiber [mailto:anchela@adobe.com]
> Sent: Mittwoch, 13. Februar 2013 16:19
> To: users@jackrabbit.apache.org
> Subject: Re: How does Jackrabbit resolve ACL permissions?
>
> hi marian
>
> the 401 is most probably rather a result on how access to workspaces is evaluated that
a permission evaluation problem on the content itself.
>
> in other words:
> i was testing with our default setup that keeps users in each workspace (workspace access
is granted if the user exists), while i would assume you are having the default jackrabbit
setup with the DefaultSecurityManager.
> unless you change the workspaceaccessmgr configuration you will get a default that makes
workspace access depending on accessibility of the root node (see DefaultSecurityManager line
659).
>
> if that's the case you can adjust the default configuration by something that better
fits your needs regarding accessibility of workspaces...
>
> something like:
> <SecurityManager
> 	class="org.apache.jackrabbit.core.DefaultSecurityManager"
> 	workspaceName="security">
>      <WorkspaceAccessManager class="..."/>  </SecurityManager>
>
> the most trivial implementation of the workspace-access-mgr just allows access to all
workspace (there is such an implementation somewhere in jackrabbit core).
> alternatively you may want to create one that specifically fits your needs.
>
> in general i find the UserPerWorkspaceSecurityManager more intuitive than what is the
default in jackrabbit core... despite the terrible name :-)
>
> kind regards
> angela
>
> On 2/13/13 3:51 PM, SCHEDENIG Marian wrote:
>> Hi Angela,
>>
>> thanks for the quick reply. I had a bug in my test code and could indeed get it working
now with multiple grant/denies on the same node, as long as I make sure to put the grants
before the denies.
>>
>> I still can't reproduce your suggested example though (Miroslav's fix taken into
account). By default I do indeed provide ALL permissions to "everyone" on root, as otherwise
(i.e. if I remove that ACE at the beginning of my test case), non-admins cannot access the
repository content at all. In fact (I'm doing all my access through WebDAV), I get a 401 (authentication
required) from the repository if I don't explicitly grant permissions on the root folder.
And that goes for a subfolder with granted ALL as well: No root permissions, no permissions
anywhere.
>>
>> Not sure if perhaps I'm doing something wrong there. But solution 2 (deny rights
to everyone and grant them to a certain group per relevant folder) should be good enough for
us.
>>
>> Cheers,
>> Marian.
>>
>> -----Original Message-----
>> From: Angela Schreiber [mailto:anchela@adobe.com]
>> Sent: Mittwoch, 13. Februar 2013 13:30
>> To: users@jackrabbit.apache.org
>> Subject: Re: How does Jackrabbit resolve ACL permissions?
>>
>> 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.schedenig@infinica.at<mailto:marian.schedenig@infinica.at>
>>>
>>> *P**Please consider the environment before printing this email*
>>>

Mime
View raw message