Sentry Debugging and Failure Scenarios
This topic explains how Sentry deals with policy conflicts and how different CDH components respond when the Sentry service fails. It also shows you how to debug Sentry authorization request failures. Always first review the CDH Release Notes and the list of Known Issues for Sentry when you have issues.
Resolving Policy Conflicts
Sentry treats all policies independently. That means that for any operation, if Sentry finds an 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'
Debugging Failed Sentry Authorization Requests
To figure out why Sentry has denied access in a specific instance, you can temporarily enable Sentry's debug level 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.
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" .
Symptoms of Sentry Service Failure
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 fail with an authentication error.
- Impala: The Impala Catalog server caches Sentry privileges, so if Sentry goes down, Impala queries continue to work because they are 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 the Hive System User and the Hive System Group (for example, hive:hive). 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. The default timeout value is 60 seconds, but you can increase this value from several minutes to a few hours, as needed to accommodate large clusters.
Page generated July 25, 2018.
<< Using the Sentry Web Server | ©2016 Cloudera, Inc. All rights reserved | Troubleshooting Sentry >> |
Terms and Conditions Privacy Policy |