Return-Path: X-Original-To: apmail-jackrabbit-oak-dev-archive@minotaur.apache.org Delivered-To: apmail-jackrabbit-oak-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 2685CF0AE for ; Mon, 25 Mar 2013 15:22:15 +0000 (UTC) Received: (qmail 88975 invoked by uid 500); 25 Mar 2013 15:22:15 -0000 Delivered-To: apmail-jackrabbit-oak-dev-archive@jackrabbit.apache.org Received: (qmail 88919 invoked by uid 500); 25 Mar 2013 15:22:15 -0000 Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: oak-dev@jackrabbit.apache.org Delivered-To: mailing list oak-dev@jackrabbit.apache.org Received: (qmail 88910 invoked by uid 99); 25 Mar 2013 15:22:15 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 25 Mar 2013 15:22:15 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of jukka.zitting@gmail.com designates 209.85.214.179 as permitted sender) Received: from [209.85.214.179] (HELO mail-ob0-f179.google.com) (209.85.214.179) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 25 Mar 2013 15:22:11 +0000 Received: by mail-ob0-f179.google.com with SMTP id un3so6064783obb.38 for ; Mon, 25 Mar 2013 08:21:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=iMN4YOUjWfhan2+B8L8V2xLMlbegcPzAiOKAM2/B0dY=; b=tb+SbtrIPiHRn4000CmtrYRLgaXEL0x8vfvylL0K3GWVYl3U/p8jRbE2J0hg+SHCg1 wfLl5moOAZbmlFCaTT779qFxlhMawfrXqJs6R3u/NjXGoqAkKoqqojQX4GPS5urkQQ9p 7uyMjC7+LzXJ4HpgxuJX5ndXbywH4XH1/HVqvaxrfkFcjdyrpZiJli10J0CYr60VS+wE ll5TDbKkuBdITdigDPt1+pXyuiJJmFJF+v0hRRA6o5bb/OVCpU9H2TzPf852V0kKM+Lc zlAlUFM3D5xTBM+RiXVdmfTOcenaZT2MHWCRVWZE6O4S4YjUokYHUw5L9w/avdrG9At+ HmEA== X-Received: by 10.60.172.108 with SMTP id bb12mr11978872oec.110.1364224910419; Mon, 25 Mar 2013 08:21:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.132.20 with HTTP; Mon, 25 Mar 2013 08:21:30 -0700 (PDT) In-Reply-To: References: From: Jukka Zitting Date: Mon, 25 Mar 2013 17:21:30 +0200 Message-ID: Subject: Re: "Secure realm" of internal APIs to prevent costly access control lookups To: Oak devs Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org Hi Lukas, On Mon, Mar 25, 2013 at 5:09 PM, Lukas Eder wrote: > Are there any such plans in OAK? Yes, but not exactly as you outline. Instead of having a special "secure realm" or other special modes that allows things like JCR API calls without access restrictions, we've built Oak using a set of layers with with different responsibilities and limitations. The lowest ones of these levels, the NodeState model [1] and the underlying MicroKernel, offer an unrestricted view on the content stored in the repository. Access controls are currently built into the next level that consists of the TreeImpl class and other components that make up the Oak API [2]. Just recently we've been discussion about whether access control checks should be pushed even further down the stack into the NodeState level. See [3] for the relevant (and ongoing) thread. It would be great if you could take a look at those layers and the recent discussion to see whether they address the issues you've encountered with Jackrabbit's access control model. [1] https://github.com/apache/jackrabbit-oak/blob/trunk/doc/nodestate.md [2] https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/README.md [3] http://markmail.org/message/a4vviwtddoajx4ua BR, Jukka Zitting