You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "angela (JIRA)" <ji...@apache.org> on 2013/05/07 19:07:16 UTC

[jira] [Commented] (OAK-774) Calculate readstatus

    [ https://issues.apache.org/jira/browse/OAK-774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13651064#comment-13651064 ] 

angela commented on OAK-774:
----------------------------

cool, thanks a lot for the patch... very much appreciated as this
is really a tricky piece! in general separating out the read status calculation 
from the regular permission eval makes a lot more sense IMO.

some additional comments:

- that initial part doesn't cover readability of ac content, right?
  could that be the reason for failing tests (there is one specific
  for the globbing restriction)... 
  
- after the calculation i would first test if there is a entry in the
  map for the specified path before iterating over the keys.

- regarding #getReadStatus: no sure, if i properly get that... from a
  first glance i would suspect that there is an issue with the DENY_NODES
  at line 241. furthermore, i somewhat get the feeling that the different
  methods to calculate the final status have a lot of similar code...
  that sounds like a candidate for being merged...
  maybe we need a way to add/subtract readstatus (see privilegebits for
  a similar concept) in order to simplify it? what do you think?

- ReadStatusEntryPredicate: the apply call returns false if the other entry
  is created for the same path... how do you then "add" addition permission
  if entry1 on path /a grants read_nodes and entry2 on path /a grants read_properties?
  i guess i am missing a piece here...

- As far as the restrictions are concerned:
  If they match that path of the permission entry this isn't a guarantee that
  they also match to all child items... that looks a bit suspicious in the
  current implementation (or maybe i misread it). imo we can either
  > have always ALLOW/DENY_THIS if there is a restriction present
  > extend the RestrictionPattern interface to allow for more fine grained
    information (basically delegating the responsibility to the impl)
  > add specific code for known restrictions (for example the globpattern "" or "/*").




                
> Calculate readstatus
> --------------------
>
>                 Key: OAK-774
>                 URL: https://issues.apache.org/jira/browse/OAK-774
>             Project: Jackrabbit Oak
>          Issue Type: Sub-task
>          Components: core, jcr
>            Reporter: angela
>            Assignee: angela
>         Attachments: OAK-774-patch.txt, OAK-774-test-patch.txt, OAK-774-test-patch.txt
>
>
> this includes 2 major steps:
> - clarify meaning of ReadStatus.*_ALL in terms of reading access control
>   content (and possibly extend the set of existing status)
> - implement calculation of read status in compiled permission impl
>  
> the 2 things together will allow us to improve performance within the
> SecureNodeState for those trees where a given user has full access or
> at least full access to non-ac items.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira