Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oak-dev@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of anchela@adobe.com designates
 64.18.1.78 as permitted sender)
Message-ID: <51507F37.6010104@adobe.com>
Date: Mon, 25 Mar 2013 17:45:43 +0100
From: Angela Schreiber <anchela@adobe.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US;
 rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: <oak-dev@jackrabbit.apache.org>
Subject: Re: "Secure realm" of internal APIs to prevent costly access control
 lookups
References: 
 <CAB4ELO6+zQ4dAB_GhnCW4wWRWHYuVorQPgySe=hY+SQpK7Q+uw@mail.gmail.com>
In-Reply-To: 
 <CAB4ELO6+zQ4dAB_GhnCW4wWRWHYuVorQPgySe=hY+SQpK7Q+uw@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

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