> On Aug. 10, 2020, 3:04 p.m., Madhan Neethiraj wrote:
> > pom.xml
> > Line 48 (original)
> > <https://reviews.apache.org/r/72624/diff/1/?file=2235132#file2235132line48>
> >
> >     Is it necessary to remove this prereq (maven 3.0.1)?

This is already take care by RANGER-2916 - by adding the following to the 
pom.xml :

                    <plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-enforcer-plugin</artifactId>
                        <version>1.4.1</version>
                        <executions>
                            <execution>
                                <id>enforce-maven</id>
                                <goals>
                                    <goal>enforce</goal>
                                </goals>
                                <configuration>
                                    <rules>
                                        <requireMavenVersion>
                                            <version>3.0.1</version>
                                        </requireMavenVersion>
                                    </rules>
                                </configuration>
                            </execution>
                        </executions>
                    </plugin>


- Abhay


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/72624/#review221082
-----------------------------------------------------------


On June 27, 2020, 1:18 a.m., Abhay Kulkarni wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/72624/
> -----------------------------------------------------------
> 
> (Updated June 27, 2020, 1:18 a.m.)
> 
> 
> Review request for ranger, Madhan Neethiraj, Ramesh Mani, and Velmurugan 
> Periasamy.
> 
> 
> Bugs: RANGER-2876
>     https://issues.apache.org/jira/browse/RANGER-2876
> 
> 
> Repository: ranger
> 
> 
> Description
> -------
> 
> Ranger plugins use an internal access-type '_any' to when access 
> authorization requires that the accessed resource has some permission for 
> given user/group/role. For a component that supports  three access-types viz. 
> 'read', 'write', 'delete', and a policy containing access specification for 
> some resource and some user, such as,
> 
> allowed accesses : {'read', 'write', 'delete'}
> 
> exceptions to allowed accesses: {'read', 'write'}
> 
> the user should be allowed '_any' access to the resource by this policy. 
> Similarly, a policy containing access specification such as 
> 
> allowed accesses : {'read', 'write'}
> 
> exceptions to allowed accesses: {'read', 'write'}
> 
> should not make authorization decision for '_any' access.
> 
> -----
> 
> Fix:
> 
> Authorizing "any" access for access-type policies now involves checking if 
> any of the accesses defined in the service-definition allows access using 
> policy-items of the policy being evaluated. If true, the "any" access is 
> authorized; else if none of defined accesses are allowed, then access is 
> explicitly denied, else no authorization decision is made by the policy.
> 
> 
> Diffs
> -----
> 
>   agents-audit/pom.xml b30474a9c 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/policyevaluator/RangerDefaultPolicyEvaluator.java
>  d75bf46a0 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/policyevaluator/RangerDefaultPolicyItemEvaluator.java
>  90d96d93d 
>   
> agents-common/src/test/resources/policyengine/test_policyengine_descendant_tags.json
>  a2ec460e6 
>   agents-common/src/test/resources/policyengine/test_policyengine_hive.json 
> ba5a53c30 
>   
> agents-common/src/test/resources/policyengine/test_policyengine_tag_hive.json 
> 79417a0cb 
>   
> agents-common/src/test/resources/policyengine/test_policyengine_tag_hive_filebased.json
>  73fe540c7 
>   pom.xml 5bfd08df2 
> 
> 
> Diff: https://reviews.apache.org/r/72624/diff/1/
> 
> 
> Testing
> -------
> 
> Ensured all existing unit tests are valid. New unit tests are developed, and 
> verified that all unit tests pass.
> 
> 
> Thanks,
> 
> Abhay Kulkarni
> 
>

Reply via email to