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)