Fateh Singh created RANGER-4977:
-----------------------------------
Summary: Hbase scan operation returns denied columns in result
Key: RANGER-4977
URL: https://issues.apache.org/jira/browse/RANGER-4977
Project: Ranger
Issue Type: Bug
Components: Ranger
Reporter: Fateh Singh
Assignee: Fateh Singh
*Scenario 1 (works as expected):*
There are 2 column families in table1 i.e. cf1 and cf2
Data in table 1 is (cf1,c1,10), (cf1,c2,20)Policies:
There are 2 policies :
Policy 1: Allow (table1, cf1, *) for the user systest
Policy 2: Deny (table1, cf1, c1) for the user systest
*In hbase shell:*
{quote} > scan 'table1'{quote}
Returns one result for (cf1,c2,10)
This is the expected behavior{*}Security Hole Scenario:{*}
Add one more policy to the above scenario
Allow (table1, cf2,*) for the user systest{*}In hbase shell:{*}
{quote} > scan 'table1'{quote}
Returns two results
(cf1,c1,10) and (cf1,c2,20)This is not the expected resultThe user systest had
an explicit deny for (cf1, c1) by Policy2 and should not have been returned
Another simpler way to reproduce the issue is to have just one column family
cf1 in the table
2 Policies
Policy 1: Allow (table1, cf1, *) for the user systest
Policy 2: Deny (table1, cf1, c1) for the user systestData in table 1 is
(cf1,c1,10), (cf1,c2,20)
{quote} scan 'table1'{quote}
This will always return both (cf1,c1,10), (cf1,c2,20)
Which is not expected behavior since there is explicit deny for (table1, cf1,
c1)
Analysis:
Till the time there was no policy for (table1,cf2) a filter is returned by
ranger which helps in doing explicit column level authorization.
However the moment an allow policy for cf2 is added then no filter is returned
which results in no column authorization being applied for a given column
family, hence all columns are allowed access.
The bug can be attributed to bug in the column family authorization which is in
place today.
We use ResourceMatchingScope=SELF_OR_DESCENDANTS for column family which
essentially has no effect since any deny policy items for a column are ignored
because MatchType is DESCENDANT in such cases (and thus we say access allowed
for the full column family even when there is a column which is denied)
In the current logic, if all the column families are access allowed then we do
not return the filter. If there is a column family access denied then we return
a filter which results in explicit column authorization later in the pipeline
because of the filter (thus the issue is not observed in Scenario1 wherein
there was a column family cf2 for which because there was no policy it was
denied and we end up doing column auth later and everything works as expected).
There is a possibility, this could have been caused by
https://issues.apache.org/jira/browse/RANGER-3617
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
