Permission handling (Was: [jira] [Commented] (OAK-660) ReadOnlyTree: implement Object#equals and Object#hashCode)

[Jukka Zitting <ju...@gmail.com>]

Hi,

[branching general discussion to the list]

I'm not implying that the suggested solution in OAK-660 is wrong
(apologies if that was how I sounded), just trying to understand why
it was chosen since we've explicitly tried to make this pattern
(pre-load content in memory, refresh/reload when changes are detected)
unnecessary with Oak. If it's needed, then there might be some problem
lurking around that we haven't yet considered. Thus I'd like to better
understand the underlying issues before we rush into a solution.

More specifically, what's the cost of permission compilation and, if
too high to be done on-demand, what's the trade-off between storing
the compilation results in memory vs. in content? Also, what's the
benefit of a separate permission store vs. reading permissions
directly along the path being accessed?

PS. Angela, I know this must be annoying, with people asking questions
and bringing up alternatives, just to end up with "ah, right, I didn't
know that!" But these discussions help spread knowledge and
understanding about the security code and thus hopefully make it
easier for others to participate in the effort if or when needed.

BR,

Jukka Zitting

Re: Permission handling (Was: [jira] [Commented] (OAK-660) ReadOnlyTree: implement Object#equals and Object#hashCode)

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Fri, Mar 1, 2013 at 3:46 PM, Angela Schreiber <an...@adobe.com> wrote:
> it's not yet chosen... its work in progress and am still in the
> very first iteration (compared to us having up to 5 different
> mk implementations and still don't have a final decision
> on how to build it). i am currently trying to complete that, fill
> in the TODOs and FIXMEs in order to be able to verify if it works
> in the first place and second how it performs.

My main worry here is that we end up with a similar situation as with
the original MongoMK. After months of effort we essentially needed to
start from scratch since the implementation didn't take into account
the broader design of Oak.

You're obviously in a much better position to understand how the
different pieces of Oak fit together, so I'm not too concerned, but I
assume you'd agree that others could have valuable input on how to
best fit permission handling with the rest of the stack.

> see above... how can i generate figures if i don't get an initial
> version running because i keep discussing?

Even a general description of why you believe one approach to be
better than the other would be fine.

See for example my original MongoMK^2 design proposal where I outlined
the SegmentMK design together with rough estimates of some key
performance characteristics. I don't yet have exact numbers to back up
all those estimates, but they are still quite valuable in discussing
the overall design and in figuring out whether implementation or
design changes are needed to address specific issues.

> it wouldn't be annoying at all if people would invest some time
> looking at the code and understanding the existing
> setup and the requirements before guessing how it could be or not
> and starting discussions on how it should be or not based on
> assumptions. that's my precondition for a serious discussion.

The code can only tell you *how* it currently works, not *why* it
works like that or how it'll work once the implementation is
completed. The reason I bring up these discussions are the latter
questions, i.e. when I can't find answers to my questions just by
looking at the code.

For example, I see the canRead() methods on PermissionProvider and I
wonder whether those calls really need to be made on each and every
Tree access. Since a Tree is based on an immutable snapshot of the
repository, we should be able to tell whether the current user has
full read access to content in that subtree. If that's the case (which
it commonly is), it would be possible for us to avoid *all* remaining
canRead() calls in that subtree, which would be a great performance
gain regardless of how far the canRead() method itself can be
optimized.

BR,

Jukka Zitting

Re: Permission handling (Was: [jira] [Commented] (OAK-660) ReadOnlyTree: implement Object#equals and Object#hashCode)

[Angela Schreiber <an...@adobe.com>]

hi jukka

> I'm not implying that the suggested solution in OAK-660 is wrong
> (apologies if that was how I sounded)

ack

>, just trying to understand why it was chosen

it's not yet chosen... its work in progress and am still in the
very first iteration (compared to us having up to 5 different
mk implementations and still don't have a final decision
on how to build it). i am currently trying to complete that, fill
in the TODOs and FIXMEs in order to be able to verify if it works
in the first place and second how it performs.

> (pre-load content in memory, refresh/reload when changes are detected)
> unnecessary with Oak. If it's needed, then there might be some problem
> lurking around that we haven't yet considered.

i don't want to pre-load content but i am convinced that just reading
the permission content (which is already a compiled form of the
original AC content) for every single call of 'hasPermission'
will not perform irrespective on how precise the compilation in
the content will be... if it turns out that i am mistaken i will
adjust it in the subsequent iteration.

> More specifically, what's the cost of permission compilation and, if
> too high to be done on-demand, what's the trade-off between storing
> the compilation results in memory vs. in content? Also, what's the
> benefit of a separate permission store vs. reading permissions
> directly along the path being accessed?

see above... how can i generate figures if i don't get an initial
version running because i keep discussing?
it's a first version that includes what IMHO would be a likely start
for being a scalable, high performing ac-evaluation taking both oak
specifics and my experiences from cq2 up to jr2.x into account.
it will evolve and be adjusted based on concrete numbers and input.
that doesn't differ from any other area in the oak project.

> PS. Angela, I know this must be annoying, with people asking questions
> and bringing up alternatives, just to end up with "ah, right, I didn't
> know that!"

it wouldn't be annoying at all if people would invest some time
looking at the code and understanding the existing
setup and the requirements before guessing how it could be or not
and starting discussions on how it should be or not based on
assumptions. that's my precondition for a serious discussion.
discussions just for the sake of mail traffic and visibility is futile.

> But these discussions help spread knowledge and
> understanding about the security code and thus hopefully make it
> easier for others to participate in the effort if or when needed.

see above: that's perfectly fine if the discussions are qualified.
if they are not they will simply make no difference but instead
just prevent me from completing a task that is months behind the schedule.

regards
angela