accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Tubbs (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (ACCUMULO-1318) Allow granting System.GRANT permission
Date Fri, 06 Mar 2015 21:05:39 GMT

     [ 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)

Mime
View raw message