Cloudera Docs

Behavioral Changes in Apache Ranger

Behavioral changes denote a marked change in behavior from the previously released version to this version of Apache Ranger.

Cloudera Runtime 7.3.2.10000 SP1

READ permission now required for Ozone key create/delete operations
Summary:

READ permission is now required for Ozone key create/delete operations

Previous behavior:

Earlier, while performing file creation on Ozone, only create and write permissions were checked on the Ozone key resource. Similarly, for file deletion, only the delete permission was checked. No read permission was required for either operation.

With Ranger RMS enabled, Ozone filesystem’s create/write access was correctly translated to Hive create/update permissions, and Ozone delete access was correctly translated to Hive Drop permissions; without needing any read/select grant.

New behavior:

Ozone now calls getFileStatus before executing create, write, or delete operations on keys. This getFileStatus call performs a READ permission check. If the user lacks read access to the Ozone key resource, the request is denied with a READ permission error, even if the user has the correct create, write, or delete permissions.

When Ranger RMS is enabled, users now additionally need select permission (the Hive equivalent of read) in their Hive policy to perform create or delete operations on the underlying Ozone filesystem.

Ranger denies ALTER TABLE operations on tables with active row filter or column masking policies
Summary:

Ranger denies ALTER TABLE operations on tables with active row filter or column masking policies.

Previous behavior:

Earlier, when a row filter or column masking policy was active on a Hive table, the ALTER TABLE rename operation was permitted. As a result, the existing row filter and column masking policies become ineffective for the renamed table.

New behavior:

Currently, the ALTER TABLE operation is now denied when the source table has one or more active row filter or column masking policies. This change ensures that security policies remain valid and consistently applied to the intended table, regardless of any rename attempts.

GraalJS engine hardening for _expression policy conditions
Summary:

The GraalJS engine used to evaluate _expression policy conditions in Apache Ranger has been hardened for security.

Previous behavior:

Earlier, the GraalJS engine was configured with:

  • polyglot.js.allowHostAccess=true — allowed unrestricted access to Java host objects from scripts

  • polyglot.js.nashorn-compat=true — enabled Nashorn-style Java interop globals (Java.type(), java.*, Packages.*)

This permitted _expression policy conditions to use constructs such as:
Java.type('java.lang.Runtime')
java.lang.Runtime.getRuntime()
Packages.java.lang.String
new java.io.File('/tmp/test')
ctx.getClass().getClassLoader()
New behavior:

Currently, both allowHostAccess and nashorn-compat settings have been removed. The JavaScript constructs listed above will no longer work and will silently return null. When a blocked script is evaluated, evaluateScript() catches the exception and returns null. Depending on the policy structure, this could silently flip an ALLOW decision to DENY or vice versa.

If you are using Java class references directly in _expression conditions, you must rewrite them using the documented Ranger helper API. If a required capability is missing from the helper API, a JIRA should be filed to request a new helper method.

Enforcement of unauthenticated access properties
Summary:

The ranger.admin.allow.unauthenticated.access and ranger.admin.allow.unauthenticated.download.access properties are now enforced regardless of whether Kerberos authentication is configured on Ranger Admin. The default values remain unchanged.

Previous behavior:

Earlier, these settings were applied only when Ranger Admin was configured with Kerberos authentication. In non-Kerberos deployments, plugins and clients could access non-secure endpoints (to download policies, tags, roles, userstore, or to grant/revoke) without these properties being evaluated.

New behavior:
Currently, both properties are now honored consistently in all deployment modes (Kerberos and non-Kerberos). This is a breaking change for deployments where all of the following are true:
  1. Ranger Admin is not configured with Kerberos authentication.
  2. Ranger Admin is not configured to allow unauthenticated access.
  3. Plugins/clients use the non-secure endpoints to download policies/tags/roles/userstore or to grant/revoke.

In affected deployments, take one of the following actions:

  • Configure plugins/clients to use the secure endpoints. For example, set ranger.plugin.<serviceType>.forceSecureEndpointAccess=true.
  • Configure Ranger Admin to allow unauthenticated access by setting ranger.admin.allow.unauthenticated.access=true (and/or ranger.admin.allow.unauthenticated.download.access=true).
Updated permission error response for unauthorized Ozone key deletion
Previous behavior:

Previously, attempting to delete an Ozone key without sufficient privileges returned a DELETE permission denied error.

New behavior:

The Ozone Manager now checks permissions through the getFileStatus() API during key deletion. Consequently, unauthorized delete requests return a READ permission denied error instead of a DELETE error. This aligns with AWS S3 behavior to prevent unauthorized users from verifying whether a resource exists.

Cloudera Runtime 7.3.2.100 CHF 1

There are no behavioral changes in this release.

Cloudera Runtime 7.3.2.0

The behavioral changes for Apache Ranger in Cloudera Runtime 7.3.2.0 include all cumulative updates from previous releases (such as 7.3.1.x). This version specifically incorporates changes introduced in Cloudera Runtime 7.3.1.100 through 7.3.1.706 alongside the following functional adjustments. For a complete list, see Behavioral Changes.

Summary:
The new column authorization optimization property in the Ranger-HBase plugin changes Ranger audit behavior, when enabled. There is no behavioral change if the property is disabled.
Previous behavior:

Earlier, there were more audit entries when the service configuration for optimization was not present and, hence, not enabled.

For example, the audit behavior for the hbase ltt -tn multitest -families cf0,cf1 -write 3:2:1 -multiput -num_keys 1 -num_regions_per_server 1 command was as follows:

15 audit entries

New behavior:

Currently, there are fewer audit entries when the service configuration for optimization is enabled.

For example, the audit behavior for the hbase ltt -tn multitest -families cf0,cf1 -write 3:2:1 -multiput -num_keys 1 -num_regions_per_server 1 command is as follows:

2 audit entries (multitest/cf1 and multitest/cf2)

Summary:
The following service configurations have been added to a new place in the Ranger Admin Web UI:
  • Policy Download Users (policy.download.auth.users)
  • Tag Download Users (tag.download.auth.users)
  • Service Admin Users (service.admin.users)
  • Service Admin Groups (service.admin.groups)
  • Superusers (ranger.plugin.super.users)
  • Superuser Groups (ranger.plugin.super.groups)
  • Userstore Download Users (userstore.download.auth.users)
Previous behavior:

Previously, the above service configurations were available under the Add New Custom Configurations section.

New behavior:

Now, the above service configurations are directly available under the Config Properties section. Additionally, the configurations are added as dropdowns, where you can select the users and groups.

Also, after you upgrade to Cloudera Runtime 7.3.2.0 from any previous release, your existing configurations will be shifted to the Config Properties section with values.

Summary:

Policy resources in the Ranger Admin UI are being added using React JS instead of Backbone JS

Previous behavior:

Earlier with Backbone JS, when you copied and pasted resource values containing commas or spaces (for example, in Hive policy resources: database1, database2), the UI automatically split them into separate values — database1 and database2. The same behaviour applied to space-separated values. Because of this, you were not allowed to enter resource names containing commas and spaces, and this limitation affected all service policy resources.

New behavior:

After upgrading from Backbone JS to React JS, this restriction has been removed. Now, React JS treats pasted values with commas or spaces as a single entry. Hence, you can no longer paste multiple values at once; you must manually add each resource value.

Summary:

Hive authorization from Ranger for Alter Table Rename command does not require CREATE database permission on the database where the renamed table will be created.

Previous behavior:
Earlier, whenever Alter Table Rename command was used across databases in Hive, authorization from Ranger required CREATE database permission for the user on the target database in which the renamed table was created.
New behavior:
Now, whenever Alter Table Rename command is used across databases in Hive, authorization from Ranger does not check for CREATE database permission for the user on the target database in which the renamed table will be created.
Summary:

Added support for multiple columns policy creation in Ranger for Grant/Revoke request.

Previous behavior:
Previously, when a request with multiple columns, such as GRANT SELECT (col1, col2, col3, col4, col5, col6, col7, col8, col9, col10) ON TABLE demo.data5 TO ROLE testrole_09289898, is executed in Impala, it results in the creation of a separate grant policy for each column in Ranger.
New behavior:
Now, a request with multiple columns results in creation of a single policy for Grant request for all the columns in Ranger. Same is true for Revoke request.