[
https://issues.apache.org/jira/browse/HBASE-12823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14278286#comment-14278286
]
Andrew Purtell edited comment on HBASE-12823 at 1/15/15 5:45 AM:
-----------------------------------------------------------------
> It is possible that users with ACL (A or C) permission on TableA are not
> allowed to access data in TableA or bypass the visibility protection?
The bits are independent so A doesn't grant R or W. However, A and C both grant
the privilege to alter table attributes*. If the VisibilityController is
installed as a table coprocessor then it could be deactivated. This is less a
problem of design for us and much more a violation of the trust implicitly
placed in that user when they were granted A or C permissions on the table by
their organization. It would also be a problem of subpar site configuration, in
my opinion. I would not recommend either AccessController nor
VisibilityController be installed as table coprocessors. They should always be
installed as system coprocessors. If we agree on this point we can document it
as recommended configuration in the security section of the online manual.
* - and grant themselves additional perm bits on the scopes where they have A
or C perms.
was (Author: apurtell):
> It is possible that users with ACL (A or C) permission on TableA are not
> allowed to access data in TableA or bypass the visibility protection?
The bits are independent so A doesn't grant R or W. However, A and C both grant
the privilege to alter table attributes. If the VisibilityController is
installed as a table coprocessor then it could be deactivated. This is less a
problem of design for us and much more a violation of the trust implicitly
placed in that user when they were granted A or C permissions on the table by
their organization. It would also be a problem of subpar site configuration, in
my opinion. I would not recommend either AccessController nor
VisibilityController be installed as table coprocessors. They should always be
installed as system coprocessors. If we agree on this point we can document it
as recommended configuration in the security section of the online manual.
> Visibility label security at limited localized level
> ----------------------------------------------------
>
> Key: HBASE-12823
> URL: https://issues.apache.org/jira/browse/HBASE-12823
> Project: HBase
> Issue Type: Improvement
> Components: security
> Affects Versions: 1.0.0, 2.0.0, 0.98.10
> Reporter: Jerry He
> Fix For: 2.0.0
>
>
> Currently, if visibility label security is enabled for a HBase instance,
> after VisibilityController is configured, the cell level visibility label
> filtering will kick in across the HBase instance.
> Cell level visibility label filtering has non-negligible performance impact.
> On the other hand, in many use cases, only a small portion of the overall
> data needs visibility label protection.
> If we can support visibility label security at a limited and localized
> level, we will broaden the use cases and the adoption of this feature.
> We should be able to support visibility label security at per table or per
> column family level. This is quite common in many other HBase features.
> Cell level visibility label filtering will only be enabled and kick in for
> the tables or column families that the user designates.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
