Mailing-List: contact notifications-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jira@apache.org
Date: Thu, 5 Feb 2015 00:18:35 +0000 (UTC)
From: "Josh Elser (JIRA)" <jira@apache.org>
To: notifications@accumulo.apache.org
Message-ID: <JIRA.12772057.1422978754000.260269.1423095515943@Atlassian.JIRA>
In-Reply-To: <JIRA.12772057.1422978754000@Atlassian.JIRA>
References: <JIRA.12772057.1422978754000@Atlassian.JIRA>
 <JIRA.12772057.1422978754109@arcas>
Subject: [jira] [Commented] (ACCUMULO-3557) No write ACL set on
 /accumulo/instances/...
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/ACCUMULO-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14306285#comment-14306285 ] 

Josh Elser commented on ACCUMULO-3557:
--------------------------------------

bq. Restricting write access would be difficult, since the whole point of this name-to-id mapping paradigm was so somebody could easily re-initialize an instance with the same name, without clobbering an existing instance.

In practice, how often is this actually used? I don't think I've ever done this in the years I've used Accumulo. I only see re-init'ing done when I'm destroying the instance.

bq. And, the new instance could have a different instance secret, so what ACL do we use?

Obviously, we would want to use the current instance.secret (since that's what the rest of the instance nodes would be acl'ed with). The problem would be knowing what the old instance.secret was to remove the old znode. The first thought I have is to have a password-prompt when we get an AuthFailed removing the old ZNode. The administrator running the reinitialization can enter whatever the old secret was.

bq. The risks here are how it affects clients.

Yes, that was my original concern. Users being redirected to a different Accumulo instances -- maliciously or otherwise. Anyone has the ability to change these nodes which means that anyone with access to the system can prevent users from normally accessing it by just nuking this node.

> No write ACL set on /accumulo/instances/...
> -------------------------------------------
>
>                 Key: ACCUMULO-3557
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-3557
>             Project: Accumulo
>          Issue Type: Improvement
>          Components: zookeeper
>            Reporter: Josh Elser
>            Priority: Critical
>             Fix For: 1.7.0
>
>
> It's common for users to have four "arguments" to make a connection to Accumulo: zookeeper quorum string, instance name, username and password.
> The instance name is used to find the instanceID using {{/accumulo/instances/...}} in ZooKeeper. It appears that anyone can write in the {{/accumulo/instances}} ZNode. This seems suspect, because any unauthenticated user can alter the state of ZooKeeper and break users connecting to Accumulo or force them to connect to a different Accumulo instance.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)