I have ranger plugin enabled for HDFS and the policy is in place and I am not in the list of users that have access to the policy (see picture) but I can still access all the HDFS directories ?
-bash-4.1$ klist Ticket cache: FILE:/tmp/krb5cc_600 Default principal: sami@MY.COM Valid starting Expires Service principal 11/30/16 23:22:44 12/01/16 23:22:44 krbtgt/MY.COM@MY.COM renew until 11/30/16 23:22:44 -bash-4.1$ -bash-4.1$ -bash-4.1$ hdfs dfs -ls /user/flume/ Found 4 items drwx------ - flume hdfs 0 2016-11-28 19:00 /user/flume/.Trash drwxr-xr-x - flume hdfs 0 2016-10-12 16:50 /user/flume/.hiveJars drwxrwxr-x - flume hdfs 0 2016-11-23 10:03 /user/flume/tweets drwxr-xr-x - flume hdfs 0 2016-11-03 10:54 /user/flume/tweets2 -bash-4.1$ <a href="/storage/attachments/10019-capture.jpg">capture.jpg</a>
if I destroy the ticket then I don't get access .
-bash-4.1$ kdestroy -bash-4.1$ -bash-4.1$ -bash-4.1$ klist klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_600) -bash-4.1$ -bash-4.1$ hdfs dfs -ls /user/flume/ 16/12/01 13:19:08 WARN ipc.Client: Exception encountered while connecting to the server : javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt)]
Can you snapshot the page where you have the policies ? If the profile is public, I believe it overrides any other permissions. How about you introducing your user and denying any privileges from him over HDFS.
@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.