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
