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 [email protected] > On 21 Sep 2017, at 17:13, Bertrand Delacretaz <[email protected]> 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
