[
https://issues.apache.org/jira/browse/HBASE-7367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13534139#comment-13534139
]
Andrew Purtell commented on HBASE-7367:
---------------------------------------
bq. as I've said in the jira, this is just the first step to have all the code
ready.
I saw that, and I don't agree it is appropriate to commit in present form.
"Security is not compatible with snapshots" = no.
GLOBAL ADMIN is a reasonable first step, this punts all decisionmaking about
what to snapshot or restore and how to essentially the superuser.
Up to this point IIRC we've been allowing TABLE CREATE to have the same privs
on their specific tables that the GLOBAL ADMIN has.
Whether or not to restore the _acl_ table is an administrative decision. Allow
it if GLOBAL ADMIN says so I'd say.
> Snapshot coprocessor and ACL security
> -------------------------------------
>
> Key: HBASE-7367
> URL: https://issues.apache.org/jira/browse/HBASE-7367
> Project: HBase
> Issue Type: Sub-task
> Components: Client, master, regionserver, snapshots, Zookeeper
> Reporter: Matteo Bertozzi
> Assignee: Matteo Bertozzi
> Priority: Minor
> Fix For: hbase-6055, 0.96.0
>
> Attachments: HBASE-7367-v0.patch
>
>
> Currently snapshot don't care about ACL...
> and in the first draft snapshots should be disabled if the ACL coprocessor is
> enabled.
> After the first step, we can discuss how to handle the snapshot/restore/clone.
> Is saving and restoring the _acl_ related rights, the right way? maybe after
> 3 months we don't want to give the access the guys listed in the old _acl_...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira