Known Issues in Apache Ranger

Learn about the known issues in Apache Ranger, the impact or changes to the functionality, and the workaround.

Known issues identified before Cloudera Runtime 7.3.2 include only unresolved issues from previous releases that continue to affect the Cloudera Runtime 7.3.2 base release.

Known issues identified in Cloudera Runtime 7.3.2.20000 SP2

There are no new known issues in this release.

Known issues identified in Cloudera Runtime 7.3.2.10000

There are no new known issues in this release.

Known issues identified in Cloudera Runtime 7.3.2.100 CHF 1

There are no new known issues in this release.

Known issues identified in Cloudera Runtime 7.3.2

CDPD-97234: Ranger RAZ client performance tuning configurations do not take effect: 7.3.2, 7.3.2.10000; In Cloudera Runtime 7.3.2.0, the Ranger RAZ client performance tuning parameters documented for adjusting connection timeout and retry behavior may not take effect as expected. During an Availability Zone (AZ) failover, HDFS operations continue to use default timeout and retry values even after explicitly lowering them through the documented configuration. This occurs because some configuration properties, such as ranger.raz.client.max.retry, do not honor the expected configuration prefix, causing the custom values to be ignored.; To apply RAZ client performance tuning correctly, use the following configuration properties in your core-site settings:
<property> <name>ranger.raz.client.max.retry</name> <value>1</value> </property> <property> <name>fs.s3a.ext.raz.rest.client.connection.pool.retry-count</name> <value>1</value> </property> <property> <name>fs.s3a.ext.raz.rest.client.connection.timeoutMs</name> <value>30000</value> </property> <property> <name>fs.s3a.ext.raz.rest.client.read.timeoutMs</name> <value>15000</value> </property>
CDPD-101412: Ranger upgrade may fail in MySQL 8.x when the default charset is set to utf8mb4: 7.3.2; In some environments, upgrading Ranger that uses an external MySQL 8.x database can fail if the server‑level default character set is configured as utf8mb4. The upgrade may stop with database or schema‑related errors because Ranger may not know the default charset of the MySQL server.; Create the required index manually by executing the following SQL statement in the Ranger DB:
CREATE INDEX x_trx_log_IDX_trx_id ON x_trx_log (trx_id(190));
This prefix index ensures the key length stays within the 3072-byte limit for utf8mb4 environments. For more details, check Additional Steps for Apache Ranger.

Known Issues identified before Cloudera Runtime 7.3.2

CDPD-106623: Ranger HDFS plugin incorrectly allows move-to-trash operations: 7.3.2 and its SPs and CHFs, 7.3.1 and its SPs and CHFs; When ranger.hdfs.authz.enable.optimization is set to true (the default), the directory-rename optimization in the Ranger HDFS plugin incorrectly short-circuits permission evaluation to ALLOW during move-to-trash operations. As a result, users who have permissions on their own .Trash directory may be able to move or delete files and directories to trash even if they do not have the required permissions on the source directory.; Set the ranger.hdfs.authz.enable.optimization property to false in the Ranger HDFS plugin configuration (ranger-hdfs-security.xml). This disables the optimization logic and enforces normal permission checks for all operations, including move-to-trash.
CDPD-94671: Knox-proxied Ranger Swagger UI generates incorrect API URLs: 7.3.2 and its SPs and CHFs, 7.3.1 and its SPs and CHFs, 7.1.9 and its SPs and CHFs; When you access the Ranger API Documentation (Swagger UI) through the Knox proxy (Knox UI > Ranger UI > API Documentation > Swagger UI), the generated REST API URLs and curl commands use an incorrect endpoint format. Executing these API calls results in a 404 Undocumented Error: Not Found. This issue also occurs when running the Swagger-generated curl commands from the command line.; APIs accessed directly using the Ranger Admin host and port (rangeradminhost:6182) work as expected.
OPSAPS-75673: Wrong enablement of Ranger RMS Database Full Sync command: 7.3.2, 7.3.1 and its SPs and CHFs, 7.1.9 SP1 and its CHFs, 7.1.9 and its SPs and CHFs, 7.1.8 and its SPs and CHFs; The Ranger RMS Database Full Sync command should be enabled only when all RMS server instances are stopped. This is required to ensure that the RMS database synchronizes correctly without introducing conflicts or data corruption. However, when HA (High Availability) is enabled on the cluster, the command becomes available from Cloudera Manager > Ranger RMS > Actions drop-down, even though only one Ranger RMS instance is stopped while the others are still running.; None.
Ranger DB upgrade failure with password authentication error: 7.3.2, 7.3.1 and its SPs and CHFs, 7.1.9 SP1 and its CHFs; During a cluster upgrade (such as upgrading to higher version), the Ranger PostgreSQL database upgrade step fails with a password authentication error similar to the following:
SQLException : SQL state: 28P01 org.postgresql.util.PSQLException: FATAL: password authentication failed for user "ranger" ErrorCode: 0
This issue occurs even if the password configured in Cloudera Manager matches the database. During the upgrade process, the installer executes a Jisql command where the password string is encapsulated in single quotes ('...'). If the password itself contains a single quote character, authentication fails.; To resolve this issue, remove single quote characters from the Ranger database user password and proceed with the upgrade:

Update the password in the database:
Log in to your PostgreSQL/database host and alter the ranger user's password so that it does not contain single quotes (').

Update Cloudera Manager configuration:

Go to the Ranger service in Cloudera Manager.

Navigate to the Configuration tab.

Search for Ranger Database User Password and enter the new password without single quotes.

Save the configuration changes.

Resume the upgrade:
Resume or retry the Ranger database upgrade process from Cloudera Manager.
CDPD-68806: The Revoke operation for users belonging to a group or role permission does not function as expected: 7.3.2, 7.3.1 and its SPs and CHFs, 7.1.9 SP1 and its CHFs; List command is listing all the tables even when the user permission is revoked. And also the command does not add any deny policy to Ranger for that specific user.; This behavior is currently not supported in HBase shell. Must be handled manually using the Ranger policy change.
CDPD-68739: The revoke command does not work when using the HBase shell: 7.3.2, 7.3.1 and its SPs and CHFs, 7.1.9 SP1 and its CHFs; While using the HBase shell, running the revoke command does not cancel the user permission. Users are able to perform actions even after running the revoke command.; None.
CDPD-58704: hadoop roll key/key delete command shows operation failed error when one KMS host is down, even when operation succeeds: 7.3.2, 7.3.1 and its SPs and CHFs, 7.1.9 SP1 and its CHFs, 7.1.9 and its SPs and CHFs; In case of rollover/delete, client sends one more (last after delete request) request to KMS instances to clean their cache and that too to all registered kms instances. if one KMS instance is stopped (not deleted), the client gets a runtime exception.; This simply returns the runtime exception on client end for stopped instances but doesn't break any functionality.
CDPD-56803: When there is no existing policy for user and a revoke request comes from hbase, then will get this error: 7.3.2, 7.3.1 and its SPs and CHFs, 7.1.9 SP1 and its CHFs, 7.1.9 and its SPs and CHFs; None.
CDPD-56741: Improvement in log message when jwtauth not used: 7.3.2, 7.3.1 and its SPs and CHFs, 7.1.9 SP1 and its CHFs, 7.1.9 and its SPs and CHFs; None.
CDPD-56738: Ranger RMS showing FileNotFoundException: /usr/share/java/oraclepki.jar in Oracle 19 setup: 7.3.2, 7.3.1 and its SPs and CHFs, 7.1.9 SP1 and its CHFs, 7.1.9 and its SPs and CHFs; This is a warning log printed in catalina.out file when Ranger RMS server is initialized. The following exception is observed only in Oracle 19 setup: FileNotFoundException: /usr/share/java/oraclepki.jar; None.
CDPD-48975: Ranger KMS KTS to KMS DB migration: keys with the same name but different case are not migrated: 7.3.2, 7.3.1 and its SPs and CHFs, 7.1.9 SP1 and its CHFs, 7.1.9 and its SPs and CHFs; KMS keys are not case sensitive.; No workaround. Such key combinations are very rare and the migration doc was updated to check such keys before starting the migration.
CDPD-42598: Kafka policy creation allowed with incorrect permissions: 7.3.2, 7.3.1 and its SPs and CHFs, 7.1.9 SP1 and its CHFs, 7.1.9 and its SPs and CHFs, 7.1.8 and its SPs and CHFs; When creating a Kafka policy from the UI, the permissions "Idempotent write"and "Cluster action" are not displayed as they are not applicable for the "topic" resource, but when creating a policy for the "topic" resource with the permissions "Idempotent write" and "Cluster Action", the policy is created successfully when the expected behaviour is that the policy creation must fail as the permission is not applicable for the Kafka topic resource.; None.
CDPD-41582: Atlas Resource Lookup : Classification for "entity-type" lists only classification for the following payload: {"resourceName": "classification", "userInput": "", "resources": {"classification": []}}]: 7.3.2, 7.3.1 and its SPs and CHFs, 7.1.9 SP1 and its CHFs, 7.1.9 and its SPs and CHFs, 7.1.8 and its SPs and CHFs; Expectation is to return all the classifications. But the response has only "classification". Happens similarly for entity-label, entity-business-metadata.; None.