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 Bertrand Delacretaz <bd...@apache.org> on 2017/09/21 15:13:04 UTC
chroot-like content segregation?
Hi,
I'm presenting next week at https://adapt.to on creating multi-tenant
HTTP request processing / rendering farms with Sling, showing a mix of
Sling-based experiments and theoretical considerations on what would
help creating such farms.
Having chroot-style [1] user segregation at the repository level would
help: after opening a session as a member of the jail group "foo",
/jails/foo becomes my new root, blocking me from accessing anything
above that and transparently mapping my repository root to /jails/foo.
Access control can of course help implementing this, but having the
path mapping to transparently jail the user or group in their own
subtree makes things much easier at the application level.
Has anyone already played with something like this?
Any prototypes or experiments worth mentioning?
-Bertrand
[1] https://linux.die.net/man/2/chroot
Re: chroot-like content segregation?
Posted by Robert Munteanu <ro...@apache.org>.
Hi Tomek,
On Fri, 2017-09-22 at 05:03 +0000, Tomek Rekawek wrote:
> Hello Bertrand,
>
> this seems like an opposite of the composite node store - rather than
> combining multiple repositories together, we’re trying to split one
> repository into many jails. Maybe I’m too optimistic, but I think the
> implementation should be quite easy if done on the node store level.
(snip)
But that would require support in the various Oak subsystems, like
indexing, node types, etc right? Either that, or we create full self-
contained 'jails' with node type definitions, indexes, principals, etc.
Robert
Re: chroot-like content segregation?
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Fri, Sep 22, 2017 at 9:14 AM, Tomek Rekawek
<re...@adobe.com.invalid> wrote:
> ...Bertrand - could you clarify if the jails should share some data with the “main” repository (which would
> make it more difficult, as Robert and Michael wrote) or the self-contained approach is ok?...
They don't need to share anything, jails being completely isolated
from each other is fine.
Which makes me think that this could also be handled at the Sling
level by switching repositories with one SlingRepository service per
jail. There are some caches that would need to be made aware of that,
at least in Sling, so that probably also leaves a few "details" to
address.
-Bertrand
Re: chroot-like content segregation?
Posted by Tomek Rekawek <re...@adobe.com.INVALID>.
Hello Robert & Michael,
> On 22 Sep 2017, at 08:31, Robert Munteanu <ro...@apache.org> wrote:
>>
>> this seems like an opposite of the composite node store - rather than
>> combining multiple repositories together, we’re trying to split one
>> repository into many jails. Maybe I’m too optimistic, but I think the
>> implementation should be quite easy if done on the node store level.
>
> But that would require support in the various Oak subsystems, like
> indexing, node types, etc right? Either that, or we create full self-
> contained 'jails' with node type definitions, indexes, principals, etc.
Yep, the idea I’ve described assumes that each jail is self-contained, with their own indexing data, users, etc.
> On 22 Sep 2017, at 08:58, Michael Dürig <md...@apache.org> wrote:
> I agree that on the NodeStore level this is probably easy enough. However mind you that the JCR semantics demand for *a lot* of shared global state, all of which is implement on top of the NodeStore. It is this global state that complicated the composite store implementation and in fact required drastic limitations in some places.
>
> If the segregation is security relevant we probably need to come up with similar limitations in order to properly sandbox the individual parts. E.g. don't leak through observation events, indexes, node type constraints leading to exceptions that could leak sensitive information. Avoid information exposure through the version store. Etc, etc…
I think it’s an easier case than the composite node store, with the assumption as above (fully self-contained jails). With the composite node store we have to wrap the node state/builder objects, so their can be “switched” to appropriate mount on the right moment. For this jailed node store, we don’t need to wrap anything - we just return a node state /jail/foo as a root. Then it’s not possible to access any other part of the repository and jail has its own indexes, node types, version store, etc. With regards to the observation events, the jailed node store have to announce only the relevant part of the new state (so basically call newState.getChildNode(“jail/foo”)).
Maybe my assumption that every jail is self-contained is too strong (and makes the multi-tenancy too expensive), but that was my idea coming from the initial Bertrand’s e-mail. Bertrand - could you clarify if the jails should share some data with the “main” repository (which would make it more difficult, as Robert and Michael wrote) or the self-contained approach is ok?
Regards,
Tomek
--
Tomek Rękawek | Adobe Research | www.adobe.com
rekawek@adobe.com
Re: chroot-like content segregation?
Posted by Michael Dürig <md...@apache.org>.
Hi,
I agree that on the NodeStore level this is probably easy enough.
However mind you that the JCR semantics demand for *a lot* of shared
global state, all of which is implement on top of the NodeStore. It is
this global state that complicated the composite store implementation
and in fact required drastic limitations in some places.
If the segregation is security relevant we probably need to come up with
similar limitations in order to properly sandbox the individual parts.
E.g. don't leak through observation events, indexes, node type
constraints leading to exceptions that could leak sensitive information.
Avoid information exposure through the version store. Etc, etc...
Michael
On 22.09.17 07:03, Tomek Rekawek wrote:
> Hello Bertrand,
>
> this seems like an opposite of the composite node store - rather than combining multiple repositories together, we’re trying to split one repository into many jails. Maybe I’m too optimistic, but I think the implementation should be quite easy if done on the node store level.
>
> The node states / builders - the basic objects representing the data on the lowest abstraction level - don’t know anything about their parents and their paths. The API client just calls NodeStore#getRoot() and gets a node state representing the root. If we have the JailedNodeStore, it can go to the underlying segment- or document node store and return basically any node (eg. /jails/foo). The node store implementation have to take care of transforming it back to the right place when the client calls NodeStore#merge().
>
> For instance, the structure for the SegmentMK repository is as follows:
>
> /
> /root
> /root/content
> /root/home
> /root/...
> /checkpoints/foo/root
> /checkpoints/bar/root
>
> Where the /root represents the actual repository root and the /checkpoints subtree represents the checkpoints and is not accessible directly. This shows how easy it is to return some part of the tree as the root and block the API client from accessing other parts laying higher.
>
> Regards,
> Tomek
>
Re: chroot-like content segregation?
Posted by Tomek Rekawek <re...@adobe.com.INVALID>.
Hello Bertrand,
this seems like an opposite of the composite node store - rather than combining multiple repositories together, we’re trying to split one repository into many jails. Maybe I’m too optimistic, but I think the implementation should be quite easy if done on the node store level.
The node states / builders - the basic objects representing the data on the lowest abstraction level - don’t know anything about their parents and their paths. The API client just calls NodeStore#getRoot() and gets a node state representing the root. If we have the JailedNodeStore, it can go to the underlying segment- or document node store and return basically any node (eg. /jails/foo). The node store implementation have to take care of transforming it back to the right place when the client calls NodeStore#merge().
For instance, the structure for the SegmentMK repository is as follows:
/
/root
/root/content
/root/home
/root/...
/checkpoints/foo/root
/checkpoints/bar/root
Where the /root represents the actual repository root and the /checkpoints subtree represents the checkpoints and is not accessible directly. This shows how easy it is to return some part of the tree as the root and block the API client from accessing other parts laying higher.
Regards,
Tomek
--
Tomek Rękawek | Adobe Research | www.adobe.com
rekawek@adobe.com
> On 21 Sep 2017, at 17:13, Bertrand Delacretaz <bd...@apache.org> wrote:
>
> Hi,
>
> I'm presenting next week at https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fadapt.to&data=02%7C01%7C%7C15ad55ff154e41cade1e08d50103451f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636416035909672993&sdata=eY96ZM01i319NbyG%2FyViIZELv26e%2FGJjFOC332QYFUM%3D&reserved=0 on creating multi-tenant
> HTTP request processing / rendering farms with Sling, showing a mix of
> Sling-based experiments and theoretical considerations on what would
> help creating such farms.
>
> Having chroot-style [1] user segregation at the repository level would
> help: after opening a session as a member of the jail group "foo",
> /jails/foo becomes my new root, blocking me from accessing anything
> above that and transparently mapping my repository root to /jails/foo.
>
> Access control can of course help implementing this, but having the
> path mapping to transparently jail the user or group in their own
> subtree makes things much easier at the application level.
>
> Has anyone already played with something like this?
> Any prototypes or experiments worth mentioning?
>
> -Bertrand
>
> [1] https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flinux.die.net%2Fman%2F2%2Fchroot&data=02%7C01%7C%7C15ad55ff154e41cade1e08d50103451f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636416035909829248&sdata=INxX6aSA%2FdB6hnHCgzYW2gGw1Sj1eq3b%2BGc88Cw7WWM%3D&reserved=0
Re: chroot-like content segregation?
Posted by Torgeir Veimo <to...@gmail.com>.
Could you implement a JcrDocumentStore which relays to an underlying JCR
repository with subpath jailing for this purpose? Catching it at any other
level seems to lead to complications and special cases.
On 22 September 2017 at 01:13, Bertrand Delacretaz <bd...@apache.org>
wrote:
> Hi,
>
> I'm presenting next week at https://adapt.to on creating multi-tenant
> HTTP request processing / rendering farms with Sling, showing a mix of
> Sling-based experiments and theoretical considerations on what would
> help creating such farms.
>
> Having chroot-style [1] user segregation at the repository level would
> help: after opening a session as a member of the jail group "foo",
> /jails/foo becomes my new root, blocking me from accessing anything
> above that and transparently mapping my repository root to /jails/foo.
>
> Access control can of course help implementing this, but having the
> path mapping to transparently jail the user or group in their own
> subtree makes things much easier at the application level.
>
> Has anyone already played with something like this?
> Any prototypes or experiments worth mentioning?
>
> -Bertrand
>
> [1] https://linux.die.net/man/2/chroot
>
--
-Tor