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 <[email protected]> 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)
