jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@adobe.com>
Subject Security Concerns wrt Index Definitions
Date Wed, 13 Nov 2013 10:21:26 GMT
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