I have seen lots of cases that Hive users were trying to give user permission to a certain directory using Sentry command to GRANT URI in the Sentry HDFS sync enabled cluster. This logic seems to be correct, however it will not work.

Sentry HDFS sync will only sync Sentry privileges to HDFS ACLs at database or table level, and it will ignore all the privileges for URIs.

So if your username is “test”, GROUP is “test_group” and ROLE is “test_role”, which as the following privilege:

0: jdbc:hive2://hiveserver2:10000> show grant role test_role;
+---------------------------------+-------+-----------+--------+----------------+----------------+------------+--------------+------------------+---------+
| database                        | table | partition | column | principal_name | principal_type | privilege  | grant_option | grant_time       | grantor |
+---------------------------------+-------+-----------+--------+----------------+----------------+------------+--------------+------------------+---------+
| hdfs://nameservice1/path/to/dir |       |           |        | test_role      | ROLE           | *          | false        | 1468340836037000 | --      |
+---------------------------------+-------+-----------+--------+----------------+----------------+------------+--------------+------------------+---------+

If you “getfacl” on path “hdfs://nameservice1/path/to/dir”, it will not show that GROUP “test_group” has READ and WRITE permissions. In order to get the Sentry privilege synced, a table will need to be linked to the URI.

Try the following:

CREATE DATABASE dummy; -- have any dummy tables under this database
USE dummy;
CREATE EXTERNAL TABLE dummy (a int) LOCATION "/path/to/dir";
GRANT ALL ON TABLE dummy TO ROLE test_role;

Now if you try to run “hdfs dfs -getfacl /path/to/dir”, the test_group should show up and have “rwx” permissions.

This is documented on Cloudera’s Official Documentation as below:

Leave a Reply

Your email address will not be published. Required fields are marked *