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
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
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:
Ranger Admin is not configured with Kerberos authentication.
Ranger Admin is not configured to allow unauthenticated access.
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:
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:
In Ranger RMS, the property for Ranger S3 service
name has been changed.
Previous behavior:
Earlier, the name of the property was
ranger-rms.HMS.source.service.name.
New behavior:
Starting from Cloudera Runtime 7.3.2.0 release, the name of the property is
ranger-rms.HMS.source.service.name.s3.
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.
