Sentry Debugging and Failure Scenarios
This topic describes how Sentry deals with conflicting policies, how to debug Sentry authorization request failures and how different CDH components respond when the Sentry service fails. Before debugging, ensure you have read through the CDH Release Notes annd the list of Known Issues for Sentry.
Resolving Policy Conflicts
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
- 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" .
Sentry Service Failure Scenarios
- 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.