jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@adobe.com>
Subject Re: "Secure realm" of internal APIs to prevent costly access control lookups
Date Mon, 25 Mar 2013 16:45:43 GMT
hi lukas

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.

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.

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