[
https://issues.apache.org/jira/browse/ZOOKEEPER-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12650369#action_12650369
]
Benjamin Reed commented on ZOOKEEPER-237:
-----------------------------------------
If you bind a credential to a root, you end up tying yourself to a particular
authorization scheme and id.
If ACLs are used, you would not be able to circumvent the root. And by using an
identifier not tied to a credential, you can support multiple credentials for a
given root. For example, you may have /mySpace1, and you have some clients that
are in a trusted cluster that "authenticate" with ip addresses and others that
use stronger credentials. You may also have the converse problem where a given
credential may have access to /mySpace1 and /yourSpace2, so the root would be
ambiguous.
> Add a Chroot request
> --------------------
>
> Key: ZOOKEEPER-237
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-237
> Project: Zookeeper
> Issue Type: New Feature
> Reporter: Benjamin Reed
> Priority: Minor
>
> 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.
