jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Boston <...@tfd.co.uk>
Subject ACLProvider/Entries Question.
Date Sat, 04 Jul 2009 15:46:59 GMT
Hi,
First I assume I am looking at the correct ACLProvider ie  
acl.ACLProvider and not principalbased.ACLProvider or  
combined.ACLProvider.

I am looking at the acl.ACLProvider and the way in which it compiles a  
permissions set, so I can get a better understanding of the process  
prior to some minor local modifications.

 From what I understand, after reading the code and drawing [1]  
permissions are accumulated by processing an ordered list of entries.  
(ACLProvider#Entries)

Since this accumulation depends on the current state of the permission  
and privilege bitmaps as they a built up (those registers being  
"allows", "denies", "allowPrivilege", "denyPrivilege" ), (in  
ACLProvider.buildResult(path)).

  I think I am correct in saying that the order in which the Entries  
is processed is significant.
Is that correct ?

However looking at the implementation of Entries the underlying store  
is a ListOrderedMap which IIRC maintains the order in which elements  
were placed into the map, and AFAICT, the entries of the map are  
populated from a list of Principals in the Entries constructor (.  
AFAICT, the order of the Map or the list is not sorted before being  
used to build the permission bitmaps in ACLProvider.buildResult()

This implies that the order of the Principal names presented to  
Entries() determines the order in which the permissions are compiled  
in buildResult().

Is that correct ?

What I dont get, is

If a grant of a permission on a ancestor on one principal name (lets  
say the first principal name in the list) and deny the same permission  
on a child node (lets say the last principal name in the list), how  
that is reflected in the final "allows" bitmap ?

I think, the grant will be processed first, setting the bit in the  
allows, and allowsPrivilage bitmaps.
Then some time later the deny would be processed, but since the bit is  
already set in the allows/allowPrivilege Permissions.diff(...) will  
filter that bit out of the deny, and so the permission will still be  
allowed.

Obviously, if the principal names were the same the younger (eg child  
node) would have been processed first.

Was all of this intentional or should the principalNamesToEntries  
actually collet ACE in the order they are found working from child to  
ancestor ?
See [2] for an example.

If any of the above analysis isn't clear (v high probability :) ),  
please say and I will try and explain myself better.
Ian


[1] http://groups.google.com/group/sakai-kernel/web/jackrabbitPermissionsResolution.graffle.pdf
[2] http://groups.google.com/group/sakai-kernel/web/jackrabbitPermissionsEntriesOrder.graffle.pdf

Mime
View raw message