Hi Qi Wang: To your question "I know row level filter only has select. But does it also remove the permission from other policy? Like hive users universal access from the base policy.” --> In this case your user 'hive' has all permissions on all tables through the default access based policy. Also there is a row level policy for user 'hive’ on 'rowfilter' table. We have only ‘select’ privilege to choose in row level policy, what this means is that you are giving user ‘hive’ only ‘select' privilege on the table and that too with restrictions on what he can view on doing ‘select’. Why this is done? If you as a user are not allowed to even see the full contents of a particular table, you cannot be allowed to perform operations on that table. When Hive request comes in from a user, all row level policies are scanned for that user. If a row level policy found for the user, the access privileges are scanned on that resource by going through access policies. (An access policy needs to grant the user access to that resource, row filer policy does not grant access). Now since update is not granted by masking policy, the operation is denied. The request does not even reach access policy. Hope this helps. ... View more

Hi @Juan Manuel Nieto: You need to regenerate keytabs after the upgrade completes. [Ambari UI->Admin->Kerberos->regenerate key tabs btn] Else Ranger Admin will fail to start. ... View more

@ Manoj Dhake : To be able to create ur own DB/tables as a user say user1, you will first need an access policy in Ranger for user1 with create permission atleast. I am guessing you know this part. Then you need to tag your Hive resources through Atlas UI. For that you would need an Atlas Ranger policy which will give appropriate permissions to the user used for tagging . Once your resources are tagged, you can create a tag based policy in Ranger depending on your need. Like, if you want user2 to be restricted from seeing any table, say table2 tagged with PII (Table level tag), you create a tag policy with Tag=PII, Under DENY CONDITIONS, put user=user2, and for Component Permissions, select Hive and the Hive operations the user should not be able to perform on the table. Then add the tag service name in Hive Service by editing Hive service and using field: 'Select Tag Service'. Now when you try to do any operation on table2 as user2, you will be denied access, even if there is an access policy granting all permissions to user2 on table2. OR IF you want user2 access to ONLY tagged resources like table2, table3 tagged with 'user' tag, then make sure there is no access based policy for user2 or any of its groups and create a tag based policy with tag='user', in Allow conditions, put user='user2', and for Component Permissions, select Hive and the Hive operations the user should be able to perform on resources tagged with 'user' tag. Hope this helps. The above 2 examples are typical usages of tag based policies. Pls vote up if you find the answer useful. ... View more

Hi @Eugene Koifman: I was able to reproduce the exact scenario that Navendu mentioned and table create cmd I used was: [create table testtable1(Name String,`Account number` String,Age int); ...log/webhcat/webhcat.log.2017-02-14:hive.support.quoted.identifiers=column] ... View more

I tried the above scenario and @Navendu Garg's exact issue is described below: There is a table say 'default.testtable1' with one of the column names containing a space say 'account name'. [create table testtable1(Name String,`Account number` String,Age int); ...log/webhcat/webhcat.log.2017-02-14:hive.support.quoted.identifiers=column] A user say 'user1' has a Hive access policy granting all permissions to user1 on default.testtable1, all columns. There is also a masking policy which masks column 'name' in same table 'default.testtable1' with mask type='redact' for user1. select * from default.testtable1 throws: Error: Error while compiling statement: FAILED: SemanticException org.apache.hadoop.hive.ql.parse.ParseException: line 1:41 rule Identifier failed predicate: {allowQuotedId()}? line 1:56 rule Identifier failed predicate: {allowQuotedId()}? line 1:129 rule Identifier failed predicate: {allowQuotedId()}? line 1:144 rule Identifier failed predicate: {allowQuotedId()}? (state=42000,code=40000) Audit shows only masking policy allowed the txn. There is no deny and no access policy mentioned in the audit. The flow didn't reach the access policies auth. On disabling the masking policy, the select shows correct results. NOTE: I tried it with mask type as 'Hash','Partial mask','Nullify' and same result. @Madhan Neethiraj, Will you pls confirm if this is expected - If any of the column names in a table contain spaces and there is a mask policy on any of that table's columns, then select with fail with the above exception. ... View more

@Navendu Garg: I tried your scenario in my test environment and had no issues accessing column with masking option set to 'redact'. On giving select cmd, the values were shown as xxxxx instead of usual values. Also, based on https://issues.apache.org/jira/browse/HIVE-6013, I inserted values into my column with ` and ', also set column name with ` and ' but the behavior was fine. What hive client are you using? Also, can you let me know what kind of value was in your column? Did the column name or any of column values contain any kind of quotes? I am assuming that you have an access level hive policy granting ur user atleast select privilege to the table and the columns you are accessing in ur select statement, and then a masking policy which masks one of the columns for the same user running the query. ... View more

@Sami Ahmad: You have an HDFS policy which does not grant permissions to your user for viewing resources. In most of the components, this would boil down to access request being denied. However, in HDFS, if a Ranger policy does not grant access to a resource, native Hadoop privileges are checked as well. If HDFS grants user 'SAMI' access to resources, 'SAMI' will be able to access the same (inspite of Ranger policy not granting permission). You can check whether its Ranger policy responsible for your user being able to view resources or its native Hadoop ACLs through Audit page->Access tab. In screenshot, Policy ID is -- and also, Access Enforcer=hadoop-acl which means the user had access through native Hadoop ACL. None of the Ranger Hadoop policies are responsible for the Access/ Deny. Hope this helps. screen-shot-2017-02-08-at-104435-am.png ... View more