You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-dev@jackrabbit.apache.org by Angela Schreiber <an...@adobe.com> on 2013/11/13 11:21:26 UTC
Security Concerns wrt Index Definitions
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
Re: Security Concerns wrt Index Definitions
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Nov 13, 2013 at 11:21 AM, Angela Schreiber <an...@adobe.com> wrote:
> ...- if the location of the index definitions is well chosen....
> for example: why are the index definitions not located underneath
> jcr:system? this was IMO more appropriate...
FWIW, from my user's point of view, index definitions under
/jcr:system makes more sense than "polluting" the root node with that
kind of stuff.
-Bertrand
Re: Security Concerns wrt Index Definitions
Posted by Angela Schreiber <an...@adobe.com>.
hi jukka
oak only has 2 built-in users: admin and anonymous.
we don't have an administrators group and we can't predefine
the access control content as this depends on the repository
setup... we don't and should not mandate a particular access
control model.
we could however treat the built-in index definitions as repository
internal content such as we do for the permission store. but
if we do, we should make this configurable and extensible.
kind regards
angela
On 11/13/13 6:27 PM, "Jukka Zitting" <ju...@gmail.com> wrote:
>Hi,
>
>On Wed, Nov 13, 2013 at 12:16 PM, Angela Schreiber <an...@adobe.com>
>wrote:
>> regarding restricting permissions:
>> we should have that in the default setup instead of relying on
>> some specific user of OAK to remember to setup it. experience
>> shows that this simply doesn't work; we have to make the repository
>> secure by default.
>
>How about we restrict the default indexes in /oak:index to administrators?
>
>BR,
>
>Jukka Zitting
Re: Security Concerns wrt Index Definitions
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Wed, Nov 13, 2013 at 12:16 PM, Angela Schreiber <an...@adobe.com> wrote:
> regarding restricting permissions:
> we should have that in the default setup instead of relying on
> some specific user of OAK to remember to setup it. experience
> shows that this simply doesn't work; we have to make the repository
> secure by default.
How about we restrict the default indexes in /oak:index to administrators?
BR,
Jukka Zitting
Re: Security Concerns wrt Index Definitions
Posted by Angela Schreiber <an...@adobe.com>.
hi alex
please allow me to be confused... maybe the docu is not as clear
for someone that is not familiar with the code as it might look
for the author ;-)
you say:
"indices go under 'oak:index'"
"index definition is of type 'oak:queryIndex'"
i thought the index content is stored underneath ":index".
so, what does 'oak:index' refer to? is it marker or isn't it
a marker?
and why do you need 'oak:index' if the index definition is identified
by the node type 'oak:queryIndexDefinition'?
and what happens if someone just adds a node "oak:index" for the
sake of it and put's some content in there?
kind regards
angela
On 11/13/13 8:40 PM, "Alex Parvulescu" <al...@gmail.com> wrote:
>Hi,
>
>I'd like to chime in on the docs observation.
>
>Indices go under 'oak:index'. An index definition node is of type
>'oak:queryIndexDefinition', there's no constraint on the name.
>You also have a bunch of examples showing just that on various index
>implementations [0].
>
>I don't see where the confusion may come from.
>
>
>[0] http://jackrabbit.apache.org/oak/docs/query.html
>
>
>
>
>On Wed, Nov 13, 2013 at 7:16 PM, Angela Schreiber <an...@adobe.com>
>wrote:
>
>> hi jukka
>>
>> >The idea behind the oak:index child node for index definitions was
>> >that you could place them close to the content being indexed.
>>
>> just re-read the query.md and it states at the very beginning:
>>
>> "Query Indices are defined under the `oak:index` node."
>>
>> given the fact that we ship oak with some default indexes that
>> are all located at /oak:index i fear that everyone will just add
>> there indexes there.
>>
>> only later the documentation states:
>>
>> "To define a property index on a subtree you have to add an index
>> definition node that:
>> * must be of type `oak:queryIndexDefinition` [...]"
>>
>> but doesn't state that the node must be named 'oak:index'.
>> that's a bit confusing and you can't enforce that name unless
>> you specify a mixin such as proposed by tobi.
>>
>> kind regards
>> angela
>>
>>
Re: Security Concerns wrt Index Definitions
Posted by Alex Parvulescu <al...@gmail.com>.
Hi,
I'd like to chime in on the docs observation.
Indices go under 'oak:index'. An index definition node is of type
'oak:queryIndexDefinition', there's no constraint on the name.
You also have a bunch of examples showing just that on various index
implementations [0].
I don't see where the confusion may come from.
[0] http://jackrabbit.apache.org/oak/docs/query.html
On Wed, Nov 13, 2013 at 7:16 PM, Angela Schreiber <an...@adobe.com> wrote:
> hi jukka
>
> >The idea behind the oak:index child node for index definitions was
> >that you could place them close to the content being indexed.
>
> just re-read the query.md and it states at the very beginning:
>
> "Query Indices are defined under the `oak:index` node."
>
> given the fact that we ship oak with some default indexes that
> are all located at /oak:index i fear that everyone will just add
> there indexes there.
>
> only later the documentation states:
>
> "To define a property index on a subtree you have to add an index
> definition node that:
> * must be of type `oak:queryIndexDefinition` [...]"
>
> but doesn't state that the node must be named 'oak:index'.
> that's a bit confusing and you can't enforce that name unless
> you specify a mixin such as proposed by tobi.
>
> kind regards
> angela
>
>
Re: Security Concerns wrt Index Definitions
Posted by Angela Schreiber <an...@adobe.com>.
hi
On 11/13/13 9:45 PM, "Alexander Klimetschek" <ak...@adobe.com> wrote:
>On 13.11.2013, at 09:16, Angela Schreiber <an...@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
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
Re: Security Concerns wrt Index Definitions
Posted by Alexander Klimetschek <ak...@adobe.com>.
On 13.11.2013, at 09:16, Angela Schreiber <an...@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.
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. And for that /jcr:system makes a lot of sense, more than the root node.
Cheers,
Alex
Re: Security Concerns wrt Index Definitions
Posted by Angela Schreiber <an...@adobe.com>.
hi jukka
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).
regarding restricting permissions:
we should have that in the default setup instead of relying on
some specific user of OAK to remember to setup it. experience
shows that this simply doesn't work; we have to make the repository
secure by default.
regarding david's model #1:
the longer i work on the repository and on security, the more i come
to believe that rule #1 does not apply for
1. special content that stores information internal to the repository
2. content that is particularly sensitive
3. content that has been generated by untrusted users
david's model has been created at a time when we just had a
simple content mgt system without caring too much about security,
with a simple read-only publish mode and any social collaboration
features that turn the publish into a writable for everyone repository.
IMO we should rewrite them to match the requirements and changes in
our products... not only but also wrt security.
kind regards
angela
On 11/13/13 5:58 PM, "Jukka Zitting" <ju...@gmail.com> wrote:
>Hi,
>
>On Wed, Nov 13, 2013 at 5:21 AM, Angela Schreiber <an...@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
Re: Security Concerns wrt Index Definitions
Posted by Angela Schreiber <an...@adobe.com>.
hi jukka
>The idea behind the oak:index child node for index definitions was
>that you could place them close to the content being indexed.
just re-read the query.md and it states at the very beginning:
"Query Indices are defined under the `oak:index` node."
given the fact that we ship oak with some default indexes that
are all located at /oak:index i fear that everyone will just add
there indexes there.
only later the documentation states:
"To define a property index on a subtree you have to add an index
definition node that:
* must be of type `oak:queryIndexDefinition` [...]"
but doesn't state that the node must be named 'oak:index'.
that's a bit confusing and you can't enforce that name unless
you specify a mixin such as proposed by tobi.
kind regards
angela
Re: Security Concerns wrt Index Definitions
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Wed, Nov 13, 2013 at 5:21 AM, Angela Schreiber <an...@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
Re: Security Concerns wrt Index Definitions
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Wed, Nov 13, 2013 at 2:34 PM, Tobias Bocanegra <tr...@apache.org> wrote:
> this also rises the question: how does the index plugin find its
> definitions?
See the o.a.j.o.plugins.index.IndexUpdate class.
BR,
Jukka Zitting
Re: Security Concerns wrt Index Definitions
Posted by Tobias Bocanegra <tr...@apache.org>.
Hi,
On Wed, Nov 13, 2013 at 11:08 AM, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> On Wed, Nov 13, 2013 at 12:41 PM, Tobias Bocanegra <tr...@apache.org> wrote:
>> 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?
>
> By adding such a mixin?
>
> The index code itself only cares about the presence of an oak:index
> child node, not the type(s) of the parent node, so it doesn't really
> matter if the node is added as a residual nt:unstructured node, or
> through a mixin type that explicitly defines it.
>
>> suggest:
>> * create a "oak:Indexable" mixin nodetype,
>
> +0
>
>> * and make the oak:QueryIndexDefinition not extending from
>> nt:unstructured, but define it properly.
>
> Personally I'd even do away with the oak:queryIndexDefinition type
> entirely, and leave the typing (or lack of it) of index definitions to
> the individual index plugins that interpret them.
but then, we should at least define the mixin as a hint for the
plugins of where to look for it:
[oak:Indexable] mix
* oak:index (nt:base)
this also rises the question: how does the index plugin find its
definitions? certainly not via query :-)
maybe by a lookup table in /jcr:system/oak:indexes ?
> The reason why the type currently extends nt:unstructured is to allow
> custom index plugins to support extra configuration that isn't
> explicitly listed in the type definition.
then, the index plugin should be able to provide the nodetypes it needs.
--
toby
Re: Security Concerns wrt Index Definitions
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Wed, Nov 13, 2013 at 12:41 PM, Tobias Bocanegra <tr...@apache.org> wrote:
> 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?
By adding such a mixin?
The index code itself only cares about the presence of an oak:index
child node, not the type(s) of the parent node, so it doesn't really
matter if the node is added as a residual nt:unstructured node, or
through a mixin type that explicitly defines it.
> suggest:
> * create a "oak:Indexable" mixin nodetype,
+0
> * and make the oak:QueryIndexDefinition not extending from
> nt:unstructured, but define it properly.
Personally I'd even do away with the oak:queryIndexDefinition type
entirely, and leave the typing (or lack of it) of index definitions to
the individual index plugins that interpret them.
The reason why the type currently extends nt:unstructured is to allow
custom index plugins to support extra configuration that isn't
explicitly listed in the type definition.
BR,
Jukka Zitting
Re: Security Concerns wrt Index Definitions
Posted by Tobias Bocanegra <tr...@apache.org>.
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?
suggest:
* 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 <an...@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" <an...@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
>>
>
Re: Security Concerns wrt Index Definitions
Posted by Angela Schreiber <an...@adobe.com>.
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" <an...@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
>