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: Security Concerns wrt Index Definitions
Date Wed, 13 Nov 2013 17:29:34 GMT
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:

>hi
>
>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
>angela
>


Mime
View raw message