Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oak-dev@jackrabbit.apache.org
Received-SPF: pass (nike.apache.org: domain of anchela@adobe.com designates
 64.18.1.191 as permitted sender)
From: Angela Schreiber <anchela@adobe.com>
To: "oak-dev@jackrabbit.apache.org" <oak-dev@jackrabbit.apache.org>
Date: Thu, 14 Nov 2013 08:39:07 +0000
Subject: Re: Security Concerns wrt Index Definitions
Thread-Topic: Security Concerns wrt Index Definitions
Thread-Index: Ac7hFPwUaCiOZxSxTA6J1rh1F1ixYw==
Message-ID: <CEAA3E3C.D3BB%anchela@adobe.com>
In-Reply-To: <4D074FBD-E011-4501-8C8D-A7FA84949877@adobe.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.3.2.130206
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

hi

On 11/13/13 9:45 PM, "Alexander Klimetschek" <aklimets@adobe.com> wrote:

>On 13.11.2013, at 09:16, Angela Schreiber <anchela@adobe.com> wrote:
>
>> while i can see some benefit of having index definitions with
>> the content being index i am not happy with having the
>> built in index definitions underneath the root node. is is for
>> sure asking for troubles as the /jcr:system is generally protected
>> in some way while the root node is very often defined to be
>> readable to everyone (imagine our regular publish setup).
>
>I agree, built-in indexes should be under /jcr:system.

ok... what about explicitly specifying the path for with a given
the definition applies?

>If the oak:index nodes can be everywhere (close to the content to be
>indexed), which IMO is useful for applications, then you are free to put
>the built-in indexes everwhere. [...]

yes... but the key point here is IMO 'applications'. i am not sure if
it really makes sense to allow everyone with write permission to
create index definitions such as proposed by jukka earlier.

to be honest that looks pretty scary to me. imagine the following
scenarios:

- authors can just create new index where ever they feel fancy
  - they may not care about an existing index already taking care of this
  - they may not be aware of or care about creating the same index
definition=20
    again with another name.

- public writable content such as we have it in social collab features:
  - any user with write access may create a new index definititions?

this may result in polluting the repository with additional and maybe
superfluous index definitions and indices, triggering that both get
versioned... someone may even try to abuse this.

note, that my point is not primarily if and how we can assure that the
implementation gracefully handles such cases in order to prevent major
problems. instead i think we should make a conscious decision on whether
setting up index definitions and consequently triggering indexing is really
something that everyone can do who has write permission at some place
in the repository.

kind regards
angela