Re: chroot-like content segregation?

[Bertrand Delacretaz]

On Fri, Sep 22, 2017 at 9:14 AM, Tomek Rekawek
 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?

[Tomek Rekawek]

Hello Robert & Michael,

> On 22 Sep 2017, at 08:31, Robert Munteanu  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  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
reka...@adobe.com

Re: chroot-like content segregation?

[Michael Dürig]

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?

[Robert Munteanu]

Hi Tomek,

On Fri, 2017-09-22 at 05: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.

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

[Tomek Rekawek]

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
reka...@adobe.com

> On 21 Sep 2017, at 17:13, Bertrand Delacretaz  wrote:
> 
> Hi,
> 
> I'm presenting next week at 
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fadapt.to=02%7C01%7C%7C15ad55ff154e41cade1e08d50103451f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636416035909672993=eY96ZM01i319NbyG%2FyViIZELv26e%2FGJjFOC332QYFUM%3D=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=02%7C01%7C%7C15ad55ff154e41cade1e08d50103451f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636416035909829248=INxX6aSA%2FdB6hnHCgzYW2gGw1Sj1eq3b%2BGc88Cw7WWM%3D=0

Re: chroot-like content segregation?

[Torgeir Veimo]

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

chroot-like content segregation?

[Bertrand Delacretaz]

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