I was working on something unrelated, but I hit this same error, detailed the issue in Jira, and have proposed a workaround.   The issue is that there is a feature in Hive called the REGEX Column Specification.  IMHO this feature was ill conceived and is not standard SQL.  It should be removed from Hive and this issue is yet another reason why.  That's what I was working on when I hit this issue.   When Hive looks at the table name surrounded by back ticks, it looks at that string and determines that it is a Regex.  When Hive looks at the table name surrounded by quotes, it looks at that string and determines that it is a Table Name. The basic rule it uses is "most anything ASCII surrounded by back ticks is a Regex."   However, when Hive sees the quotes, it sees the string as a table name.  Using quotes (and technically back ticks too, but that's clearly broken) around table names can be allowed/disallowed with a feature in Hive called "hive.support.quoted.identifiers".  This feature is enabled in the user's HS2 session by default.  However, when performing masking, it is a multi step process:   The query is parsed by HS2 The masking is applied The query is parsed again by HS2 The first parsing attempt respects the hive.support.quoted.identifiers configuration and allows a query with quotes to be parsed.  However, the masking code does not pass this configuration information to the parser on the second attempt.  And oddly enough, if the configuration information is not passed along, the parser will consider this feature to be disabled.  So, it's actually on the second pass that it fails because the parser rejects the quotes.   For the record, I hit this issue when I removed the Regex feature, because it forced all quoted strings to be considered table names (and subjected to this feature being enabled/disabled) instead of sneaking by as being considered a Regex.  All the masking unit tests failed.   https://issues.apache.org/jira/browse/HIVE-23182 https://issues.apache.org/jira/browse/HIVE-23176   ... View more

Hi @Juan Manuel Nieto, well done! I noticed AMBARI-18898 and suspected it's causing a havoc on the command line, but didn't have time to try it. Though, now, after fixing Solr, Ranger audit cannot connect to it and Ambari is showing "http 500" (false) alerts on both Infra Solr instances. Edit: I missed "DEFAULT" in the name rules, omitted as I tried with only one rule before. After adding DEFAULT everything is back to normal! ... View more

If you want to be sure whether one of the two components is updating the password, consider checking the md5sum before and after you change it (and make sure to change it to a different value). ... View more

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

@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

@Deepak Sharma While doing masking am getting 1111... instead of cross xxxx... any suggestion to fix it please ... View more

Provided Hive also is configured to use AD to get the right groups. Please see this -- http://hortonworks.com/blog/hadoop-groupmapping-ldap-integration/ ... View more