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

There are no new known issues identified in this release.

Known Issues identified before Cloudera Runtime 7.3.2

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.
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.