You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Ian Boston <ie...@tfd.co.uk> on 2010/03/17 13:27:36 UTC
AccessControlUtil.replaceAccessControlEntry
I just noticed that AccessControlUtil.replaceAccessControlEntry searches for a match on ACE within an ACL using the principal only. (and not the grant or deny as well)
So if there was a grant acl and the replacement is a deny, then the grant is removed, even if the deny did not deny what was granted (I think I better give and example :) )
before
grant:ieb:jcr:write
update with
deny:ieb:jcr:nodeTypeManagement
after update
deny:ieb:jcr:nodeTypeManagement
----
I think, the ACLTemplate in JCR2 will support
grant:ieb:jcr:write
deny:ieb:jcr:nodeTypeManagement
in a single ACL, perhaps the replace should look at both the principal and the allow/deny
WDYT?
Ian
Re: AccessControlUtil.replaceAccessControlEntry
Posted by Ian Boston <ie...@tfd.co.uk>.
On 18 Mar 2010, at 03:16, Eric Norman wrote:
> Hi Ian,
>
> I am having trouble reproducing what you have described. I added a new unit
> test in r924618 to test the scenario you described and it appears to work
> correctly for me. Can you check the new unit test to see if there are some
> extra steps in your use case that I am missing?
Hi Eric,
I just read the patch for the test, and its correct.
You create grants and denies in 2 separate posts, and then test the results to see that both grants and denies are there in the json representing the ACL on the node, which indicates that AccessControlUtil.replaceAccessControlEntry does not merge grants and denies for the same principal into a single ACE.
My analysis was based on reading the code, rather than running it through a debugger or creating a test, so I need to go back and re-read the code/run in a debugger to see just where my thinking was wrong. It may be that I misread the setPolicy which might be merging rather than replacing.
Thank you for the test, one more thing covered, sorry for the false alarm.
Ian
>
> Regards,
> -Eric
>
>
> On Wed, Mar 17, 2010 at 9:02 AM, Ray Davis <ra...@media.berkeley.edu> wrote:
>
>> On 3/17/10 5:27 AM, Ian Boston wrote:
>>
>>> I just noticed that AccessControlUtil.replaceAccessControlEntry searches
>>> for a match on ACE within an ACL using the principal only. (and not the
>>> grant or deny as well)
>>>
>>> So if there was a grant acl and the replacement is a deny, then the grant
>>> is removed, even if the deny did not deny what was granted (I think I better
>>> give and example :) )
>>>
>>>
>>> before
>>>
>>> grant:ieb:jcr:write
>>>
>>> update with
>>>
>>> deny:ieb:jcr:nodeTypeManagement
>>>
>>> after update
>>>
>>> deny:ieb:jcr:nodeTypeManagement
>>>
>>
>> That would be a bug -- the method's documented intent is not to interfere
>> with any grants or denies on unmentioned privileges (after disaggregation).
>> Looks like the integration test may be missing a case.
>>
>> Best,
>> Ray
>>
>>
>>
>>>
>>> ----
>>>
>>> I think, the ACLTemplate in JCR2 will support
>>>
>>> grant:ieb:jcr:write
>>> deny:ieb:jcr:nodeTypeManagement
>>>
>>
>>
>>
>>
>>> in a single ACL, perhaps the replace should look at both the principal and
>>> the allow/deny
>>> WDYT?
>>>
>>> Ian
>>>
>>
>>
Re: AccessControlUtil.replaceAccessControlEntry
Posted by Eric Norman <er...@gmail.com>.
Hi Ian,
I am having trouble reproducing what you have described. I added a new unit
test in r924618 to test the scenario you described and it appears to work
correctly for me. Can you check the new unit test to see if there are some
extra steps in your use case that I am missing?
Regards,
-Eric
On Wed, Mar 17, 2010 at 9:02 AM, Ray Davis <ra...@media.berkeley.edu> wrote:
> On 3/17/10 5:27 AM, Ian Boston wrote:
>
>> I just noticed that AccessControlUtil.replaceAccessControlEntry searches
>> for a match on ACE within an ACL using the principal only. (and not the
>> grant or deny as well)
>>
>> So if there was a grant acl and the replacement is a deny, then the grant
>> is removed, even if the deny did not deny what was granted (I think I better
>> give and example :) )
>>
>>
>> before
>>
>> grant:ieb:jcr:write
>>
>> update with
>>
>> deny:ieb:jcr:nodeTypeManagement
>>
>> after update
>>
>> deny:ieb:jcr:nodeTypeManagement
>>
>
> That would be a bug -- the method's documented intent is not to interfere
> with any grants or denies on unmentioned privileges (after disaggregation).
> Looks like the integration test may be missing a case.
>
> Best,
> Ray
>
>
>
>>
>> ----
>>
>> I think, the ACLTemplate in JCR2 will support
>>
>> grant:ieb:jcr:write
>> deny:ieb:jcr:nodeTypeManagement
>>
>
>
>
>
>> in a single ACL, perhaps the replace should look at both the principal and
>> the allow/deny
>> WDYT?
>>
>> Ian
>>
>
>
Re: AccessControlUtil.replaceAccessControlEntry
Posted by Ray Davis <ra...@media.berkeley.edu>.
On 3/17/10 5:27 AM, Ian Boston wrote:
> I just noticed that AccessControlUtil.replaceAccessControlEntry searches for a match on ACE within an ACL using the principal only. (and not the grant or deny as well)
>
> So if there was a grant acl and the replacement is a deny, then the grant is removed, even if the deny did not deny what was granted (I think I better give and example :) )
>
>
> before
>
> grant:ieb:jcr:write
>
> update with
>
> deny:ieb:jcr:nodeTypeManagement
>
> after update
>
> deny:ieb:jcr:nodeTypeManagement
That would be a bug -- the method's documented intent is not to
interfere with any grants or denies on unmentioned privileges (after
disaggregation). Looks like the integration test may be missing a case.
Best,
Ray
>
>
> ----
>
> I think, the ACLTemplate in JCR2 will support
>
> grant:ieb:jcr:write
> deny:ieb:jcr:nodeTypeManagement
>
> in a single ACL, perhaps the replace should look at both the principal and the allow/deny
> WDYT?
>
> Ian