You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@accumulo.apache.org by "Christopher Tubbs (JIRA)" <ji...@apache.org> on 2015/03/06 22:05:39 UTC
[jira] [Resolved] (ACCUMULO-1318) Allow granting System.GRANT
permission
[ https://issues.apache.org/jira/browse/ACCUMULO-1318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Christopher Tubbs resolved ACCUMULO-1318.
-----------------------------------------
Resolution: Fixed
Assignee: Josh Elser (was: Christopher Tubbs)
I'm okay with punting on the revoke. A workaround, which I think works (at least with the built-in ZK-based system), is to delete the user and re-create with new permissions. Not pretty, but also not a high priority case.
> Allow granting System.GRANT permission
> --------------------------------------
>
> Key: ACCUMULO-1318
> URL: https://issues.apache.org/jira/browse/ACCUMULO-1318
> Project: Accumulo
> Issue Type: Sub-task
> Components: master, tserver
> Reporter: Christopher Tubbs
> Assignee: Josh Elser
> Labels: release_notes, security
> Fix For: 1.7.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> With the addition of pluggable authentication/authorizor/permissions handler modules (ACCUMULO-259), it seems we should rely more on these modules to set their policy for who has which permissions.
> As such, I don't believe we should continue to constrain the System.GRANT permission, so that it is held only by the root user. This is an especially important consideration for ACCUMULO-1300, because in that ticket, there will always be a "local" root user, but there's no reason that should be the de-facto account that manages other users' permissions from.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)