Support Questions

Find answers, ask questions, and share your expertise

Ranger Policies do not work for Metadata changes (touch, chown)

Expert Contributor


I am running a HDP 2.5 cluster, which is secured by Kerberos and Ranger.

On a folder, I have set permissive HDFS POSIX rights (600) on files and manage all access rights via Ranger. The folder is exported via NFS gateway and mounted on some client (options rw,sync,vers=3,proto=tcp,nolock). The UIDs are all synchronized over the hosts.

In this folder, a user, which has Read, Write, Execute via Ranger but is neither owner nor in the group of the file, IS able to read and delete files. However, he IS NOT allowed to "touch" files or change the owner. The owner of the file, however, is able to run the touch command on these files.

[ someuser@host ]$ ll
total 2
drwxr-xr-x 6 hdfs      hdfs       192 Jan 26 15:01 .
drwxr-xr-x 4 hdfs      hdfs       128 Sep  9 15:27 ..
-rw-r--r-- 1 otheruser hdfs       0   Sep  9 11:11 test1.txt
-rw-rw-r-- 1 someuser  hdfs       0   Jan 26 15:03 test2.txt
[ someuser@host ]$ touch test2.txt
[ someuser@host ]$ touch test1.txt
touch: cannot touch `test1.txt': Permission denied

Are the Ranger policies not applied on metadata changes on files, such as changing the access time or the owner? Is this a bug or by design?

The "Permission Denied" is not even audited in the Ranger Audit Log. The allowed touch-command is however audited.

Thanks for your help



This indicates to me that the "permission denied" error seems to be coming from the NFS mount client and is not even sending this command to HDFS namenode. Can you see if there are any audit records for the touch/chown command execution in the /var/log/hadoop/hdfs/hdfs-audit.log when it fails ?

Expert Contributor

When running the touch command, there are two identical accesses, which are both allowed.

2017-01-26 17:38:20,155 INFO FSNamesystem.audit: allowed=true   ugi=someuser (auth:PROXY) via nfs/host@REALM (auth:KERBEROS)    ip=/  cmd=getfileinfo src=/.reserved/.inodes/496960       dst=null        perm=null       proto=rpc

The chown command indeed leads to a failed access:

2017-01-26 17:38:20,156 INFO FSNamesystem.audit: allowed=false  ugi=someuser (auth:PROXY) via nfs/host@REALM (auth:KERBEROS)    ip=/  cmd=setOwner    src=/.reserved/.inodes/496960       dst=null        perm=null       proto=rpc
Take a Tour of the Community
Don't have an account?
Your experience may be limited. Sign in to explore more.