jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lars Michele <lars.mich...@tu-dortmund.de>
Subject Re: Groups Deny, DefaultAccessManager
Date Sat, 25 Apr 2009 14:36:41 GMT
> I notice the Access Control Elements with a deny statement don't get
> added to a ACE relating to a Group Principal.
> Does any one know the reason for this ? Is it part of the Spec ?
I do not know if it is part of the spec, but when you comment it out, it
works and I have not found a drawback yet.
> We have use cases where we want to grant part of a tree to a group and
> then deny a subtree to the main group and grant to a smaller group. At
> the moment, it looks like DACM wont do this for us, we could write our
> own (in fact we did for JR 14), but I dont really want to drift too
> far from anything in the spec.
If the check is removed, following rules work.

The principal "everybody" has read rights on the node, which is
important, so that every (authenticated) user can access the repository.
If you want to make a subdirectory protected, you just set a "deny all"
rule for "everybody" on this directory and add the appropriate rights
for the desired groups with access rights. So it does, what it should do.

What rules count:
Because the rules get computed by "OR", an "allow" counts more than a
"deny". That means if you set a "deny all" on group1 and "allow all" on
group2 and a user is in both groups (I know, you never should do
something like this), the "allow all" wins.
A user rule always wins against a group rule.
The order of the rules in the ACLs is *NOT* important!

I hope, that helps.


View raw message