Cloudera Runtime Release NotesPDF version

Behavioral Changes

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

Summary:

The ranger.plugin.ozone.optimized.subaccesspath.enabled property is enabled, by default, to enable authorization for rename and recursive delete operations in the Ranger Ozone plugin.

Previous behavior:

In releases earlier than 7.3.1.200, when the ranger.plugin.ozone.optimized.subaccesspath.enabled property was set to false, if a request for recursive delete operation for a directory came, then all the subdirectories were iteratively checked for authorization before returning the authorization result. This was an expensive operation and caused performance degradation.

New behavior:

In order to prevent performance degradation, the default value of the property has been set to true by default i.e ranger.plugin.ozone.optimized.subaccesspath.enabled=true. When this flag is set to true, then instead of iterating over subdirectories of the parent directory and checking authorization for each subdirectory, an optimized authorization flow is used wherein it is checked if this user has access to the subdirectories for which policies are defined (instead of checking access to all the subdirectories) in addition to authorization at the parent directory level.

For example, let’s consider a directory abc which has 1000 directories; abc/pqr1, abc/pqr2abc/pqr1000. If there are two policies called policy1 for abc and policy2 for abc/pqr1000 and a request comes for recursive delete on abc directory, then only 2 authorization requests are made: request #1 for abc and request #2 for abc/pqr1000 instead of 1000 authorization requests made for abc/pqr1abc/pqr1000, which were made in case when ranger.plugin.ozone.optimized.subaccesspath.enabled=false.

Caveats of ranger.plugin.ozone.optimized.subaccesspath.enabled=true: User might get access denied if there are any subdirectories which does not exist but for which a policy might exist. For example, let’s say there is an empty directory abc but a policy exists for abc/pqr1. In this case, the user might get access denied. This is now the expected behavior when optimization is enabled. This also implies that a user might also get access denied for recursive delete when there is a policy for a subdirectory for which the user does not have explicit authorization to.

Set ranger.plugin.ozone.optimized.subaccesspath.enabled=false in Ozone Manager Advanced Configuration Snippet (Safety Valve) for ozone-conf/ranger-ozone-security.xml if this optimized behavior is not desired and you are okay to take performance hit for explicit authorization for each subdirectory.

We want your opinion

How can we improve this page?

What kind of feedback do you have?