[
https://issues.apache.org/jira/browse/HBASE-7367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matteo Bertozzi updated HBASE-7367:
-----------------------------------
Attachment: HBASE-7365-v1.patch
requirePermission(Permission.Action.ADMIN) instead of the
UnsupportedOperationException.
If tested it, and the behaviour is the one Andrew described (thank you). Only
the creator can read/write to the table.
So what happens now is:
Only a GLOBAL ADMIN can take a snapshot, restore or clone a table.
In the restore case, if there're ACLs they are preserved, if there's nothing
related to the table, only the admin can read/write to table.
In the clone case, there're no rights in the table, and the admin should assign
the new ones needed.
> 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-7365-v1.patch, 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
