[
https://issues.apache.org/jira/browse/ZOOKEEPER-2014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15656309#comment-15656309
]
ASF GitHub Bot commented on ZOOKEEPER-2014:
-------------------------------------------
Github user hanm commented on a diff in the pull request:
https://github.com/apache/zookeeper/pull/96#discussion_r87543684
--- Diff: src/java/test/org/apache/zookeeper/server/DataTreeTest.java ---
@@ -200,29 +198,34 @@ public void
testSerializeDoesntLockDataNodeWhileWriting() throws Exception {
BinaryOutputArchive oa = new BinaryOutputArchive(out) {
@Override
public void writeRecord(Record r, String tag) throws
IOException {
- DataNode node = (DataNode) r;
- if (node.data.length == 1 && node.data[0] == 42) {
- final Semaphore semaphore = new Semaphore(0);
- new Thread(new Runnable() {
- @Override
- public void run() {
- synchronized (markerNode) {
- //When we lock markerNode, allow
writeRecord to continue
- semaphore.release();
+ // Need check if the record is a DataNode instance because
of changes in ZOOKEEPER-2014
+ // which adds default ACL to config node.
+ if (r instanceof DataNode) {
--- End diff --
@fpj - we were not setting ACLs on intrinsic znodes (i.e.
/zookeeper/config) ZooKeeper implicitly created while initializing a DataTree
before. And for this test case, it only creates znodes, not ACLs. As a result,
it's reasonable for the previous test case to assume every record that's
serializing is a DataNode record. Now with this patch, there is an ACL
implicitly created when /zookeeper/config node is created, so the previous
assumption (that all records to be serialized are DataNode record) does not
hold. Thus, a change is required.
For reference, you could put a break point on
https://github.com/apache/zookeeper/blob/master/src/java/main/org/apache/zookeeper/server/ReferenceCountedACLCache.java#L133
while running this test case, and you will see there is one ACL that's
serialized. Now you can remove the ACL associated with /zookeeper/config at
https://github.com/apache/zookeeper/pull/96/files#diff-a676d93082759105dd8c79c0a76a8007R259,
and you will see the break point on ReferenceCountedACLCache.java previous set
not get hit. That is the difference.
Another way to experiment this is to create an ACL in this test (without
applying this pull request first), something like:
`final DataNode markerNode = tree.getNode("/marker");
tree.setACL("/marker", ZooDefs.Ids.READ_ACL_UNSAFE, -1);` will do. Then
we will see the same type casting failure - this simulates what this PR will do
in terms of changing the type of records. Basically I think the root cause is
the test itself could be made more robust, by eliminate the assumptions (that
every record is a DataNode) that might not always hold.
> Only admin should be allowed to reconfig a cluster
> --------------------------------------------------
>
> Key: ZOOKEEPER-2014
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2014
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
> Affects Versions: 3.5.0
> Reporter: Raul Gutierrez Segales
> Assignee: Michael Han
> Priority: Blocker
> Fix For: 3.5.3
>
> Attachments: ZOOKEEPER-2014.patch, ZOOKEEPER-2014.patch,
> ZOOKEEPER-2014.patch, ZOOKEEPER-2014.patch, ZOOKEEPER-2014.patch,
> ZOOKEEPER-2014.patch, ZOOKEEPER-2014.patch, ZOOKEEPER-2014.patch,
> ZOOKEEPER-2014.patch, ZOOKEEPER-2014.patch, ZOOKEEPER-2014.patch,
> ZOOKEEPER-2014.patch, ZOOKEEPER-2014.patch, ZOOKEEPER-2014.patch,
> ZOOKEEPER-2014.patch
>
>
> ZOOKEEPER-107 introduces reconfiguration support via the reconfig() call. We
> should, at the very least, ensure that only the Admin can reconfigure a
> cluster. Perhaps restricting access to /zookeeper/config as well, though this
> is debatable. Surely one could ensure Admin only access via an ACL, but that
> would leave everyone who doesn't use ACLs unprotected. We could also force a
> default ACL to make it a bit more consistent (maybe).
> Finally, making reconfig() only available to Admins means they have to run
> with zookeeper.DigestAuthenticationProvider.superDigest (which I am not sure
> if everyone does, or how would it work with other authentication providers).
> Review board https://reviews.apache.org/r/51546/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
