jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lukas Eder <lukas.e...@gmail.com>
Subject Re: "Secure realm" of internal APIs to prevent costly access control lookups
Date Mon, 25 Mar 2013 17:23:17 GMT
Hi Angela,

> in contrast to jr-core access control mgt and permission evaluation
> will not be built on top of the JCR stack but be located below the
> new "SPI" boundary inside oak-core.

So, in essence, there are means of accessing the OAK-internal
repository representation through this SPI explicitly. It will be
low-level, but it will allow for bypassing access control. That's what
you're saying?

> consequently we no longer have the need for (shared) system session.
> btw: in jackrabbit-core system sessions already bypasses all kind
> of access control evaluation.

That's what I would've expected. However, this bypass is implemented
explicitly in AccessControlProvider implementations. I had missed this
fact at first, when I was implementing my own.

Regards,
Lukas

>
> kind regards
> angela
>
>
> On 3/25/13 4:09 PM, Lukas Eder wrote:
>>
>> Hello,
>>
>> I'm currently looking into extending Jackrabbit's (not OAK's) access
>> control management, and I found it easy to see how this area is a
>> significant performance bottleneck for today's Jackrabbit Content
>> Repository.
>>
>> The biggest design and architecture problem, in my opinion, is the
>> need for a session with associated, hard-coded access control
>> behaviour. From what I understand so far, there are (possibly
>> non-exhaustive):
>>
>> - System sessions
>> - Admin sessions
>> - User sessions
>>
>> In my opinion, in OAK, there should be something like a "secure
>> realm". Once this realm is entered, executing code should get complete
>> access to all of the repository through standard internal and external
>> API. For example, such behaviour could be achieved through setting a
>> ThreadLocal "monitor" in a local execution context as such:
>>
>>      // Outside of the "secure realm". JCR access goes through access
>> control
>>      T result = secure(new Securable<T>() {
>>          public T run() {
>>              // Inside of the "secure realm". JCR access
>>              // would now bypass access control
>>          }
>>      });
>>
>> And this could be the implementation of secure():
>>
>>      private static final ThreadLocal<Boolean>  t = new
>> ThreadLocal<Boolean>();
>>
>>      // OAK internals could use this to check if access control is needed
>>      public static boolean isSecured() {
>>          return t.get() != null;
>>      }
>>
>>      public static<T>  T secure(Securable<T>  s) {
>>          // Already secured
>>          if (isSecured()) {
>>              return s.run();
>>          }
>>          else {
>>              try {
>>                  t.set(true);
>>                  return s.run();
>>              }
>>              finally {
>>                  t.remove();
>>              }
>>          }
>>      }
>>
>> Such use of ThreadLocal is smelly and potentially slow, of course.
>> This is just to illustrate the idea. More realistic use-cases would
>> probably expose a shareable system session within the "secure realm".
>> The important thing is that this system session would also bypass
>> access control.
>>
>> Are there any such plans in OAK?
>>
>> Cheers
>> Lukas

Mime
View raw message