[
https://issues.apache.org/jira/browse/HBASE-11432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14046840#comment-14046840
]
ramkrishna.s.vasudevan commented on HBASE-11432:
------------------------------------------------
{code}
if (!authResult.isAllowed()) {
if (!cellFeaturesEnabled || compatibleEarlyTermination) {
{code}
This first 'if' check will mean that even if compatibleEarlyTermination is
false or true it is not going to check the cell level permission. This is
already existing code and not part of this patch. So my question is if a user
is set with READ permission then there narrowing the permission on a cell level
does not make sense? So user A has permssion to read a table and CF but not
authorised to read a CELL?
But if we allow that then the || condition in
{code}
if (authManager.authorize(user, table, family, qualifier,
Permission.Action.READ) ||
authManager.authorize(user, table, cell, Permission.Action.READ)) {
return ReturnCode.INCLUDE;
}
{code}
has to be changed to
{code}
authManager.authorize(user, table, cell, Permission.Action.READ))
{code}
Anyway CELL_DEFAULT can be changed to just reading the cell permission.
+1 on deprecating in 0.98 and removing from trunk.
> [AccessController] Remove cell first strategy
> ---------------------------------------------
>
> Key: HBASE-11432
> URL: https://issues.apache.org/jira/browse/HBASE-11432
> Project: HBase
> Issue Type: Bug
> Reporter: Andrew Purtell
> Assignee: Andrew Purtell
> Fix For: 0.99.0, 0.98.4
>
> Attachments: HBASE-11432.patch
>
>
> The cell first evaluation strategy for cell ACLs has been a problem since
> introduction. It was an afterthought and a mistake. It's not possible to use
> at all with the default config on trunk after HBASE-11077. Fairly certain
> there are no users. Remove. Deprecate related client API methods on Query.
> (Remove on trunk?)
--
This message was sent by Atlassian JIRA
(v6.2#6252)