jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Re: Security Concerns wrt Index Definitions
Date Wed, 13 Nov 2013 16:58:58 GMT
Hi,

On Wed, Nov 13, 2013 at 5:21 AM, Angela Schreiber <anchela@adobe.com> wrote:
> currently the index definitions are located directly underneath
> the root node and don't have any specific permission setup
> associated with them.

I guess we should restrict at least write permission to administrators.

> IMO this is a very troublesome setup which may lead to serious
> security issues.

I'm not too worried about this, since the index definitions themselves
seldom contain any confidential information, and if they do, it's
always possible to read-protect them. The actual indexed content is
always hidden.

> - 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 idea behind the oak:index child node for index definitions was
that you could place them close to the content being indexed.

For example, if you only want to index content within /foo/bar, you
could add the relevant index definitions in /foo/bar/oak:index. A nice
side-effect of this approach is that someone with write permission
within /foo/bar would then also be able to define new indexes for that
subtree.

Putting the index definitions inside /jcr:system or some other such
location would make the

> - 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?

We could add a more specific node type for this, but I don't see much
benefit in doing so. See rule #1 in David's model.

The index code in any case only looks at properly formatted index
definitions, so having extra content there does no harm. It might even
be useful, for example it would be possible to put a README.txt node
there to document the index setup.

> - 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?

See my point above. The indexing code only looks at the relevant data
in the index definition, and ignores whatever else the user might want
to place there.

>   and shouldn't the index definition be considered 'protected' from
>   a JCR point of view?

No, as otherwise we'd need to introduce a custom API for managing
indexes. With the current approach you can use any JCR content editor
or JCR client code to manage index definitions in Oak.

> - 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?

These are all questions that can be addressed with normal ACLs on the
index definition nodes.

It might make sense to adjust the permissions on the default indexes
created by the initial repository content (for example make them
writable by administrators only as mentioned above), but in general
I'd leave it up to the administrator of a particular deployment to
decide if and how index definitions need to be protected.

BR,

Jukka Zitting

Mime
View raw message