Patrick Hunt commented on ZOOKEEPER-237:

The current patch implements the java client side of chroot. After reviewing 
the code more closely it became clear
that implementing this on the server is much harder/errorprone/inefficient than 
implementing the core functionality
on the client. This means we don't get enforcement with this JIRA, however 
ZOOKEEPER-424 was created to
address that feature enhancement.

As it currently stands the client can set a chroot during client (ZooKeeper) 
object creation which will provide
similar functionality to unix chroot command. See the updated API and forrest 
docs for details.

I added 3 tests, two of which re-use existing test functionality. I'm 
validating both the synchronous as well
as async operations.

Note: I made delete("/") have the same semantics w/ or w/o chroot being used. I 
thought this best, although
not strictly necessary.

Note: /zookeeper is only available if chroot is not used (we don't map it into 
the chroot for example). I don't think
we would want to do that anyway. but wanted to not it here for review.

When updating the client code I introduced the concept of clientpath and 
serverpath to make the distinction more

Note that we validate both the chroot path as well as the clientPath, we don't 
validate the serverpath, assuming
that it's valid. Also this ensures that clientpaths start, for example, with / 

Note: watchregistration objects resulted in a very nice way of mapping 
client/server paths in watches that don't require
us to do any prefix elimination.

In general I was pretty happy with the (small) number of changes required to 
implement this and also the decent
test coverage we currently have.

Mahadev should take this next and implement the c client changes, hopefully 
they will be similar.

> Add a Chroot request
> --------------------
>                 Key: ZOOKEEPER-237
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-237
>             Project: Zookeeper
>          Issue Type: New Feature
>          Components: c client, java client
>            Reporter: Benjamin Reed
>            Assignee: Patrick Hunt
>            Priority: Minor
>             Fix For: 3.2.0
>         Attachments: ZOOKEEPER-237.patch
> It would be nice to be able to root ZooKeeper handles at specific points in 
> the namespace, so that applications that use ZooKeeper can work in their own 
> rooted subtree.
> For example, if ops decides that application X can use the subtree /apps/X 
> and application Y can use the subtree /apps/Y, X can to a chroot to /apps/X 
> and then all its path references can be rooted at /apps/X. Thus when X 
> creates the path "/myid", it will actually be creating the path 
> "/apps/X/myid".
> There are two ways we can expose this mechanism: 1) We can simply add a 
> chroot(String path) API, or 2) we can integrate into a service identifier 
> scheme for example zk://server1:2181,server2:2181/my/root. I like the second 
> form personally.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

Reply via email to