jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tobias Bocanegra <tri...@apache.org>
Subject Re: Security Concerns wrt Index Definitions
Date Wed, 13 Nov 2013 17:41:32 GMT
I suggest to use proper nodetypes for index definitions and I second
Angela's opinion, that for "internal" structures, we should be more
rigid. I quickly browsed through the code, and I could not find any
mixin type that would allow adding a oak:index node. so how would you
define an index on an arbitrary subtree?

* create a "oak:Indexable" mixin nodetype,
* and make the oak:QueryIndexDefinition not extending from
nt:unstructured, but define it properly.

regards, toby

btw: nodetypes should be uppercase (like class and interface names.
(yes, JCR had this wrong)).

On Wed, Nov 13, 2013 at 9:29 AM, Angela Schreiber <anchela@adobe.com> wrote:
> one more question regarding the node type of the index definition
> (oak:queryIndexDefinition):
> assume that someone makes the an index definition versionable.
> is it the intended behaviour that the index content stored underneath
> the index definition is being treated with OPV VERSION as it's
> mandated by nt:unstructured?
> the 'reindex' property in contrast is marked with OPV IGNORE while
> 'async' and 'type' don't have the OPV flag set which afaik means
> that they get OPV COPY.
> kind regards
> angela
> On 11/13/13 11:21 AM, "Angela Schreiber" <anchela@adobe.com> wrote:
>>while looking at OAK-1173 and OAK-1172 i once again looked at
>>the indexing code.
>>currently the index definitions are located directly underneath
>>the root node and don't have any specific permission setup
>>associated with them.
>>what does that mean: everyone that has read/write access on the
>>root node will be able to read/write the index definitions as
>>in the default setup the permissions are inherited through the
>>node hierarchy.
>>IMO this is a very troublesome setup which may lead to serious
>>security issues.
>>therefore i would like us to discuss
>>- if the location of the index definitions is well chosen.
>>  have those that originally setup that structure thought about
>>  securit concerns? what was the result?
>>  for example: why are the index definitions not located underneath
>>  jcr:system? this was IMO more appropriate.
>>- the node type of the oak:index parent node:
>>  it's currently nt:unstructured which will allow anyone with read
>>  access to create whatever additional content there. this doesn't
>>  make sense IMO.
>>  and: is the index related code prepared to deal with any kind of
>>  garbage content in the oak:index tree?
>>- the node type definition of the oak:queryIndexDefinition:
>>  it currently extends from nt:unstructured which also allows to
>>  place any kind of child nodes. is this really intended? and is
>>  the index code prepared to deal with *any* kind of content in
>>  the subtree of the definition?
>>  and shouldn't the index definition be considered 'protected' from
>>  a JCR point of view?
>>- the access rights defined on the index definition irrespective of
>>  their location:
>>  - who needs access to the index definitions?
>>  - must they be readable to everyone?
>>  - should read access be restricted?
>>  - who should/must be able to add/change/remove the index definitions?
>>IMO we need to address this very soon before someone starts
>>to use OAK in a productive environment.
>>i will open a separate JIRA issue such that we can include this
>>into the overall planning.
>>kind regards

View raw message