[
https://issues.apache.org/jira/browse/HBASE-11070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13981442#comment-13981442
]
Andrew Purtell commented on HBASE-11070:
----------------------------------------
Opened subtasks
> [AccessController] Restore early-out access denial if the user has no access
> at the table or CF level
> -----------------------------------------------------------------------------------------------------
>
> Key: HBASE-11070
> URL: https://issues.apache.org/jira/browse/HBASE-11070
> Project: HBase
> Issue Type: Task
> Reporter: Andrew Purtell
> Assignee: Andrew Purtell
> Fix For: 0.99.0, 0.98.3
>
>
> We want to support two different use cases for cell ACLs:
> 1. The user can see all cells in a table or CF unless a cell ACL denies access
> 2. The user cannot see any cells in a table or CF unless a cell ACL grants
> access
> For the sake of flexibility we made it a toggle on an operation by operation
> basis. However this changed the behavior of the AccessController with respect
> to how requests for which a user has no grant at the table or CF level are
> handled. Prior to the cell ACL changes if a user had no grant at the table or
> CF level, they would see an AccessDeniedException. We can't do that if we
> want cell ACLs to provide exceptional access. Subsequent to the cell ACL
> changes if a user has no grant at the table or CF level, there is no
> exception, they simply won't see any cells except those granting exceptional
> access at the cell level. This also brings the AccessController semantics in
> line with those of the new VisibilityController.
> Feedback on dev@ is this change is a bridge too far for at least three
> reasons. First, it is surprising (Enis and Vandana). Second, the audit trail
> is affected or missing (Enis). Third, it allows any user on the cluster to
> mount targeted queries against all tables looking for timing differences,
> that depending on schema design could possibly leak the existence in row keys
> of sensitive information, or leak the size of the table (Todd). Although we
> can't prevent timing attacks in general we can limit the scope of what a user
> can explore by restoring early-out access denial if the user has no access at
> the table or CF level.
> We can make early-out access denial if the user has no access at the table or
> CF level configurable on a per table basis. Setting the default to "false",
> with a release note and paragraph in the security guide explaining how to
> reintroduce the old behavior, would address the above and not introduce
> another surprising change among 0.98 releases. If the consensus is
> (presumably a milder) surprise due to this change is fine, then the default
> could be "true"
--
This message was sent by Atlassian JIRA
(v6.2#6252)
