[
https://issues.apache.org/jira/browse/HBASE-7367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13534341#comment-13534341
]
Jonathan Hsieh edited comment on HBASE-7367 at 12/17/12 9:50 PM:
-----------------------------------------------------------------
One argument from the RB is that this is on the snapshot dev branch that IMO
[~andrew.purt...@gmail.com]'s concern is would be a valid follow on issue that
would be a blocker that needed to be resolved before merging the branch to
trunk.
The first cut posted on RB basically says, snapshots not supported when
security is on. This patch's single concern is adding the cp hooks we'd come
up with something better before merging to trunk. (maybe remove the sec coproc
portions). The expectation here is that there would be a follow on that
implements a simple sane default.
Andrew suggests that we use global admin privs and that only folks with admin
privs would be able to clone/restore. The admins also would be responsible for
adding acls to the clones if they were a concern. This seems simple and
sufficient from my point of view.
[~andrew.purt...@gmail.com]: my question now is -- if we add the global admin
privs checks, would this be sufficient functionality for when attempting to
merge to trunk?
If it is, then hooray, I think we've know what we need to do to merge to trunk.
I personally prefer one-patch-one-concern (new snapshot cp hooks minus the
security cp policy, then another that implements the security+snapshot cp
policy), but this should be manageable enough to do in one patch with multiple
concerns.
If it isn't, then we need to discuss what semantics and functionality would
unblock the eventual merge to trunk.
was (Author: jmhsieh):
One argument from the RB is that this is on the snapshot dev branch that
IMO [~andrew.purt...@gmail.com]'s concern is would be a valid follow on issue
that would be a blocker that needed to be resolved before merging the branch
to trunk.
The first cut posted on RB basically says, snapshots not supported when
security is on. This patch's single concern is adding the cp hooks we'd come
up with something better before merging to trunk. (maybe remove the sec coproc
portions). The expectation here is that there would be a follow on that
implements a simple sane default.
Andrew suggests that we use global admin privs and that only folks with admin
privs would be able to clone/restore. The admins also would be responsible for
adding acls to the clones if they were a concern. This seems simple and
sufficient from my point of view.
[~andrew.purt...@gmail.com]: my question now is -- if we add the global admin
privs checks, would this be sufficient functionality for when attempting to
merge to trunk?
If it is, then hooray, I think we've got what we need to merge to trunk. I
personally prefer one-patch-one-concern (new snapshot cp hooks minus the
security cp policy, then another that implements the security+snapshot cp
policy), but this should be manageable enough to do in one patch with multiple
concerns.
If it isn't, then we need to discuss what semantics and functionality would
unblock the eventual merge to trunk.
> 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
