Get / Scan without table ACLs no longer throws AccessDeniedException

[Enis Söztutar <en...@apache.org>]

I was a bit surprised to find out about the case where there is a
behavioral change in trying to read from tables that the user do not have
table/cf level permission.

Previous to cell-level-acls, trying to read from a table without R priv
would result in an AccessDeniedException:


0.94:

hbase(main):002:0> scan 't1'

ROW                                                  COLUMN+CELL




ERROR: org.apache.hadoop.hbase.security.AccessDeniedException:
org.apache.hadoop.hbase.security.AccessDeniedException: Insufficient
permissions for user 'hdfs' for scanner open on table t1


However, 0.98 results in get / scan not seeing the data (because of the
injected AccessContolFilter) and returning as if there was no data:
0.98:

hbase(main):002:0> scan 'table1'

ROW                                                  COLUMN+CELL



0 row(s) in 0.0320 seconds

Also this behavioral change is applicable to the audit log as well, we no
longer mark the access granted / denied requests for gets and scans in the
audit log which is concerning.

>From the lsat paragraph in
https://blogs.apache.org/hbase/entry/hbase_cell_security, Andrew states
that there are two modes now, check cell first or not
(Query.setACLStrategy()).

However, my understanding was that the default behavior should check table
first, and then not do the scan at all if that is denied. From the code
TableAuthManager.authorize(), it does not look to be the case. My questions
are:
 1) This is a behavioral change, and changes the default behavior as well
regardless of whether cell level security is used or not. Should we revert
back to the original behavior?
 2) Even if we do not revert, should we record get / scans in the audit log
?
 3) Are we targeting two use cases (a) user do not have table level auth,
but selectively have cell level access, and (b) user do have table level
auth but selectively NOT have cell level access? For these two use cases,
should the strategy be a table level property rather than an per-op
property ?





Enis

Re: Get / Scan without table ACLs no longer throws AccessDeniedException

[Andrew Purtell <ap...@apache.org>]

The answer is #3.

It could be made a table level property.

> Also this behavioral change is applicable to the audit log as well, we no longer
mark the access granted / denied requests for gets and scans in the
​
audit log which is concerning.

This is some kind of logic bug or oversight, please file a jira.



On Wed, Apr 16, 2014 at 2:01 PM, Enis Söztutar <en...@apache.org> wrote:

> I was a bit surprised to find out about the case where there is a
> behavioral change in trying to read from tables that the user do not have
> table/cf level permission.
>
> Previous to cell-level-acls, trying to read from a table without R priv
> would result in an AccessDeniedException:
>
>
> 0.94:
>
> hbase(main):002:0> scan 't1'
>
> ROW                                                  COLUMN+CELL
>
>
>
>
> ERROR: org.apache.hadoop.hbase.security.AccessDeniedException:
> org.apache.hadoop.hbase.security.AccessDeniedException: Insufficient
> permissions for user 'hdfs' for scanner open on table t1
>
>
> However, 0.98 results in get / scan not seeing the data (because of the
> injected AccessContolFilter) and returning as if there was no data:
> 0.98:
>
> hbase(main):002:0> scan 'table1'
>
> ROW                                                  COLUMN+CELL
>
>
>
> 0 row(s) in 0.0320 seconds
>
> Also this behavioral change is applicable to the audit log as well, we no
> longer mark the access granted / denied requests for gets and scans in the
> audit log which is concerning.
>
> From the lsat paragraph in
> https://blogs.apache.org/hbase/entry/hbase_cell_security, Andrew states
> that there are two modes now, check cell first or not
> (Query.setACLStrategy()).
>
> However, my understanding was that the default behavior should check table
> first, and then not do the scan at all if that is denied. From the code
> TableAuthManager.authorize(), it does not look to be the case. My questions
> are:
>  1) This is a behavioral change, and changes the default behavior as well
> regardless of whether cell level security is used or not. Should we revert
> back to the original behavior?
>  2) Even if we do not revert, should we record get / scans in the audit log
> ?
>  3) Are we targeting two use cases (a) user do not have table level auth,
> but selectively have cell level access, and (b) user do have table level
> auth but selectively NOT have cell level access? For these two use cases,
> should the strategy be a table level property rather than an per-op
> property ?
>
>
>
>
>
> Enis
>



-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)