jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Keller <chkel...@adobe.com>
Subject Re: Security Concerns wrt Index Definitions
Date Thu, 14 Nov 2013 14:04:44 GMT

Only following the Oak development with half attention, this popped in my attention. As an
Oak use I have to care for index-configuration. And am not happy with the current situation.
So I take the opportunity of this mail to hook in.

Angela Schreiber:
IMO this is a very troublesome setup which may lead to serious
security issues.

Jukka Zitting:
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.

You are right in the security aspect of disclosure of information, the set-up may not be problematic.
The issue relevant here, is the organizational one.

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

Though writing data for storage and a configuration is all writing, one means saving data
and one is changing the system-configuration.
It's a valid requirement that you want to separate the permissions to the one from the other.
Which in the current suggested approach is difficult to achieve.

Using the Hierarchy for separating the concerns is simple and efficient. That is why I would
opt for the /system path approach.

I have the impression that this thread is partly covering a second topic: the implications
of the distributed configuration

I'd leave it up to the administrator of a particular deployment to
decide if and how index definitions need to be protected.

It overlaps a bit with the Root-Node. In the thread it is about the set-up for the AccessControl
for this Node.
But it shares the more general topic, that having the configuration with the content:
It imposes every Users of the hierarchy to have the case-handling.
Take the simplest application for a repository, a packaging: It must be decided should the
configuration be included in the package or not?

I am definitely biased by my most dominant use of a Repository as a Storage for a CMS. But
for this case I have some doubts in the benefits of a distributed search configuration.
The independent features pos requirements to the search configuration mostly about the properties
and to a very small extend to paths.

This shapes my evaluation that the gain in security by moving the configuration to its own
branch is higher than the possible gain of keeping it on root and treat it specially there.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message