Sentry Debugging and Failure Scenarios

Sentry treats all policies independently. Hence, for any operation, if Sentry can find a policy that allows it, that operation will be allowed. Consider an example with a table, test_db.test_tbl, whose HDFS directory is located at hdfs://user/hive/warehouse/test_db.db/test_tbl, and grant the following conflicting privileges to a user with the role, test_role. That is, you are granting ALL privilege to the role test_role on the URI, but only the SELECT privilege on the table itself.

GRANT ALL ON URI 'hdfs:///user/hive/warehouse/test_db.db/test_tbl' to role test_role; 
USE test_db; 
GRANT SELECT ON TABLE test_tbl to role test_role; 

With these privileges, all users with the role test_role will be able to carry out the EXPORT TABLE operation even though they should only have SELECT privileges on test_db.test_tbl:

EXPORT TABLE <another-table-user-can-read> TO 'hdfs:///user/hive/warehouse/test_db.db/test_tbl'

Sentry logs all facts that lead up to authorization decisions at the debug level. If you do not understand why Sentry is denying access, the best way to debug is to temporarily turn on debug logging:

• In Cloudera Manager, add log4j.logger.org.apache.sentry=DEBUG to the logging settings for your service through the corresponding Logging Safety Valve field for Impala or HiveServer2.
• On systems not managed by Cloudera Manager, add log4j.logger.org.apache.sentry=DEBUG to the log4j.properties file on each host in the cluster, in the appropriate configuration directory for each service.

Specifically, look for exceptions and messages such as:

FilePermission server..., RequestPermission server...., result [true|false]

which indicate each evaluation Sentry makes. The FilePermission is from the policy file, while RequestPermission is the privilege required for the query. A RequestPermission will iterate over all appropriate FilePermission settings until a match is found. If no matching privilege is found, Sentry returns false indicating "Access Denied" .

If the Sentry service fails and you attempt to access the Hive warehouse, Hive, Impala and HDFS will behave as follows:

• Hive: Queries to the Hive warehouse will fail with an authentication error.
• Impala: The Impala Catalog server caches Sentry privileges. If Sentry goes down, Impala queries will continue to work and will be authorized against this cached copy of the metadata. However, authorization DDLs such as CREATE ROLE or GRANT ROLE will fail.
• HDFS/Sentry Synchronized Permissions: Affected HDFS files will continue to use a cached copy of the synchronized ACLs for a configurable period of time, after which they will fall back to NameNode ACLs. The timeout value can be modified by adding the sentry.authorization-provider.cache-stale-threshold.ms parameter to the hdfs-site.xml Safety Valve in Cloudera Manager.

  While the default timeout value is very conservative (60 seconds), if you're working with a large cluster, these timeouts can be increased to a much longer period, anywhere between a few minutes to a few hours, as required by the cluster in the event that Sentry fails.

• Solr: Solr does not use the Sentry service, hence there will be no impact.