date:20221206

Re: Review Request 74231: RANGER-3996: upgraded commons-configuration2 version to 2.8.0

2022-12-06 Thread Pradeep Agrawal



> On Dec. 6, 2022, 10:37 a.m., Ankita Sinha wrote:
> > Need to handle it in 
> > https://github.com/apache/ranger/blob/master/plugin-solr/pom.xml
> 
> Madhan Neethiraj wrote:
> Ankita - plugins-solr doesn't use configuration2. Can you please add 
> details?

Ankita : 

Without this patch solr plugin was having : 
ranger-3.0.0-SNAPSHOT-solr-plugin/install/lib/commons-configuration2-2.1.1.jar
With this patch solr plugin is having : 
ranger-3.0.0-SNAPSHOT-solr-plugin/install/lib/commons-configuration2-2.8.0.jar

Though the commons-configuration2 dependency is not mentioned in the solr 
plugin pom file 
(https://github.com/apache/ranger/blob/master/plugin-solr/pom.xml) it is being 
pulled transitively via ranger-plugins-common module.  

[INFO] org.apache.ranger:ranger-solr-plugin:jar:3.0.0-SNAPSHOT
[INFO] +- org.apache.ranger:ranger-plugins-common:jar:3.0.0-SNAPSHOT:compile
[INFO] |  +- org.apache.commons:commons-configuration2:jar:2.8.0:compile


and line 
https://github.com/apache/ranger/blob/master/distro/src/main/assembly/plugin-solr.xml#L91
 is adding the jar in the ranger-3.0.0-SNAPSHOT-solr-plugin/install/lib 
location.


- Pradeep


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


On Dec. 6, 2022, 6:19 p.m., Madhan Neethiraj wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/74231/
> ---
> 
> (Updated Dec. 6, 2022, 6:19 p.m.)
> 
> 
> Review request for ranger, Abhishek  Kumar, Ankita Sinha, Don Bosco Durai, 
> deepak sharma, Kishor Gollapalliwar, Abhay Kulkarni, Mehul Parikh, Pradeep 
> Agrawal, Ramesh Mani, Siddhesh Phatak, Selvamohan Neethiraj, Sailaja 
> Polavarapu, Subhrat Chaudhary, and Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-3996
> https://issues.apache.org/jira/browse/RANGER-3996
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> - updated commons-configurations2 version from 2.1.1 to 2.8.0
> 
> 
> Diffs
> -
> 
>   agents-audit/pom.xml 0b106633d 
>   agents-common/pom.xml 97a51fc32 
>   agents-cred/pom.xml 124a5a861 
>   credentialbuilder/pom.xml 6d7ff0e5b 
>   hbase-agent/pom.xml 4029fc0a5 
>   hdfs-agent/pom.xml 6b974e02b 
>   kms/pom.xml b6a2cf78e 
>   pom.xml dc09328dc 
>   ranger-authn/pom.xml 952b0d3e3 
>   ranger-examples/plugin-sampleapp/pom.xml 95e401b5a 
>   ranger-hdfs-plugin-shim/pom.xml 700905d0f 
>   ranger-storm-plugin-shim/pom.xml c5bcad48b 
>   security-admin/pom.xml 54bd231d8 
>   storm-agent/pom.xml 90fe25efd 
>   tagsync/pom.xml 8b453f44f 
>   ugsync/ldapconfigchecktool/ldapconfigcheck/pom.xml 3236d017d 
>   ugsync/pom.xml 22918e554 
>   unixauthclient/pom.xml 1d2a63e9a 
> 
> 
> Diff: https://reviews.apache.org/r/74231/diff/2/
> 
> 
> Testing
> ---
> 
> - verified that Ranger has no dependency on earlier version of 
> commons-configuration2
> - verified that all tests completed successfully
> - built and deployed Ranger and plugins using docker
> 
> 
> Thanks,
> 
> Madhan Neethiraj
> 
>

Review Request 74239: RANGER-4001:Wrong permission check for Hive 'Alter View as' command in Ranger HiveAuthorizer

2022-12-06 Thread Ramesh Mani


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

Review request for ranger, Abhay Kulkarni, Madhan Neethiraj, Mehul Parikh, 
Pradeep Agrawal, Selvamohan Neethiraj, Sailaja Polavarapu, and Velmurugan 
Periasamy.


Bugs: RANGER-4001
https://issues.apache.org/jira/browse/RANGER-4001


Repository: ranger


Description
---

RANGER-4001:Wrong permission check for Hive 'Alter View as' command in Ranger 
HiveAuthorizer


Diffs
-

  
hive-agent/src/main/java/org/apache/ranger/authorization/hive/authorizer/RangerHiveAuthorizer.java
 8f6801be1 


Diff: https://reviews.apache.org/r/74239/diff/1/


Testing
---

- Testing done in local vm for "alter view as select" operations.

Hive Alter View as command needs SELECT privilege alone for the selected table 
to create view.
command : alter view v1 as select * from db.t1
Expectation: This command needs alter permission for view v1, select permission 
for table "t1" and select permission on database "db"
Current Behavior: Currently the Ranger requires ALTER permission for table "t1" 
and database "db" in addition to ALTER permission for the view "v1" . This 
behavior is not correct.


Thanks,

Ramesh Mani

[jira] [Assigned] (RANGER-4001) Wrong permission check for Hive "Alter View as" command in Ranger HiveAuthorizer

2022-12-06 Thread Ramesh Mani (Jira)



 [ 
https://issues.apache.org/jira/browse/RANGER-4001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ramesh Mani reassigned RANGER-4001:
---

Assignee: Ramesh Mani

> Wrong permission check for Hive "Alter View as" command in Ranger 
> HiveAuthorizer
> 
>
> Key: RANGER-4001
> URL: https://issues.apache.org/jira/browse/RANGER-4001
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Affects Versions: 3.0.0, 2.4.0
>Reporter: Ramesh Mani
>Assignee: Ramesh Mani
>Priority: Minor
>
> Hive Alter View as command needs SELECT privilege alone for the selected 
> table to create view.
> command : alter view v1 as select * from db.t1
> Expectation: This command needs alter permission for view v1, select 
> permission for table "t1" and select permission on database "db"
> Current Behavior: Currently the Ranger requires ALTER permission for table 
> "t1" and database "db" in addition to ALTER permission for the view "v1" . 
> This behavior is not correct.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: Review Request 74237: RANGER-4000: fixed plugins-common library unit tests for JDK17

2022-12-06 Thread Ramesh Mani


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


Ship it!




Ship It!

- Ramesh Mani


On Dec. 6, 2022, 7:25 p.m., Madhan Neethiraj wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/74237/
> ---
> 
> (Updated Dec. 6, 2022, 7:25 p.m.)
> 
> 
> Review request for ranger and Abhay Kulkarni.
> 
> 
> Bugs: RANGER-4000
> https://issues.apache.org/jira/browse/RANGER-4000
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> fixed plugins-common library unit tests for JDK17
> 
> 
> Diffs
> -
> 
>   agents-common/src/test/resources/policyengine/test_policyengine_geo.json 
> 4249996b8 
> 
> 
> Diff: https://reviews.apache.org/r/74237/diff/1/
> 
> 
> Testing
> ---
> 
> - verified that all unit tests in plugins-common library pass with JDK17
> 
> 
> Thanks,
> 
> Madhan Neethiraj
> 
>

[jira] [Created] (RANGER-4001) Wrong permission check for Hive "Alter View as" command in Ranger HiveAuthorizer

2022-12-06 Thread Ramesh Mani (Jira)

Ramesh Mani created RANGER-4001:
---

 Summary: Wrong permission check for Hive "Alter View as" command 
in Ranger HiveAuthorizer
 Key: RANGER-4001
 URL: https://issues.apache.org/jira/browse/RANGER-4001
 Project: Ranger
  Issue Type: Bug
  Components: Ranger
Affects Versions: 3.0.0, 2.4.0
Reporter: Ramesh Mani


Hive Alter View as command needs SELECT privilege alone for the selected table 
to create view.
command : alter view v1 as select * from db.t1
Expectation: This command needs alter permission for view v1, select permission 
for table "t1" and select permission on database "db"
Current Behavior: Currently the Ranger requires ALTER permission for table "t1" 
and database "db" in addition to ALTER permission for the view "v1" . This 
behavior is not correct.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (RANGER-4000) unit test failure in JDK17

2022-12-06 Thread Abhay Kulkarni (Jira)



[ 
https://issues.apache.org/jira/browse/RANGER-4000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17644051#comment-17644051
 ] 

Abhay Kulkarni commented on RANGER-4000:


Ship it!

> unit test failure in JDK17
> --
>
> Key: RANGER-4000
> URL: https://issues.apache.org/jira/browse/RANGER-4000
> Project: Ranger
>  Issue Type: Bug
>  Components: plugins
>Reporter: Madhan Neethiraj
>Assignee: Madhan Neethiraj
>Priority: Major
> Fix For: 3.0.0, 2.4.0
>
> Attachments: RANGER-4000.patch
>
>
> Following expression in test_policyengine_geo.json fails with JDK17 (script 
> engine from org.graalvm.js):
> {code:java}
> (!!country_code_format_long && !!country_code_format_dot && 
> (country_code_format_long == country_code_format_dot)){code}
>  
> This expression should be updated with:
> {noformat}
> (country_code_format_long != null && country_code_format_dot != null && 
> (country_code_format_long == country_code_format_dot)) {noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: Review Request 74232: RANGER-3999: Implement more efficient way to handle _any access authorization

2022-12-06 Thread Madhan Neethiraj


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


Ship it!




Ship It!

- Madhan Neethiraj


On Dec. 6, 2022, 10:28 p.m., Abhay Kulkarni wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/74232/
> ---
> 
> (Updated Dec. 6, 2022, 10:28 p.m.)
> 
> 
> Review request for ranger, madhan, Madhan Neethiraj, Ramesh Mani, Sailaja 
> Polavarapu, and Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-3999
> https://issues.apache.org/jira/browse/RANGER-3999
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> If a user-initiated operation requires checking if more than one permission 
> is granted, then currently, each permission requires a call to internal 
> Policy Engine API for the same accessed resource. This leads to many 
> repetitive computations which may be avoided if the policy engine API 
> supports multiple permissions. In that case, optimization may be achieved by 
> pushing authorization for multiple permissions down to the lowest possible 
> level.
> 
> 
> Diffs
> -
> 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/policyengine/RangerAccessRequestWrapper.java
>  PRE-CREATION 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/policyengine/RangerPolicyEngineImpl.java
>  23db18f3a 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/policyevaluator/RangerDefaultPolicyEvaluator.java
>  520ddf865 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/policyevaluator/RangerOptimizedPolicyEvaluator.java
>  d3fc27d7d 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/util/RangerAccessRequestUtil.java
>  df03ed1c4 
> 
> 
> Diff: https://reviews.apache.org/r/74232/diff/3/
> 
> 
> Testing
> ---
> 
> Passed all existing unit tests.
> 
> 
> Thanks,
> 
> Abhay Kulkarni
> 
>

Re: Review Request 74232: RANGER-3999: Implement more efficient way to handle _any access authorization

2022-12-06 Thread Abhay Kulkarni


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

(Updated Dec. 6, 2022, 10:28 p.m.)


Review request for ranger, madhan, Madhan Neethiraj, Ramesh Mani, Sailaja 
Polavarapu, and Velmurugan Periasamy.


Changes
---

Addressed review comments


Bugs: RANGER-3999
https://issues.apache.org/jira/browse/RANGER-3999


Repository: ranger


Description
---

If a user-initiated operation requires checking if more than one permission is 
granted, then currently, each permission requires a call to internal Policy 
Engine API for the same accessed resource. This leads to many repetitive 
computations which may be avoided if the policy engine API supports multiple 
permissions. In that case, optimization may be achieved by pushing 
authorization for multiple permissions down to the lowest possible level.


Diffs (updated)
-

  
agents-common/src/main/java/org/apache/ranger/plugin/policyengine/RangerAccessRequestWrapper.java
 PRE-CREATION 
  
agents-common/src/main/java/org/apache/ranger/plugin/policyengine/RangerPolicyEngineImpl.java
 23db18f3a 
  
agents-common/src/main/java/org/apache/ranger/plugin/policyevaluator/RangerDefaultPolicyEvaluator.java
 520ddf865 
  
agents-common/src/main/java/org/apache/ranger/plugin/policyevaluator/RangerOptimizedPolicyEvaluator.java
 d3fc27d7d 
  
agents-common/src/main/java/org/apache/ranger/plugin/util/RangerAccessRequestUtil.java
 df03ed1c4 


Diff: https://reviews.apache.org/r/74232/diff/3/

Changes: https://reviews.apache.org/r/74232/diff/2-3/


Testing
---

Passed all existing unit tests.


Thanks,

Abhay Kulkarni

[jira] [Updated] (RANGER-3997) option to use default value when user/group/tag does not have the attribute

2022-12-06 Thread Madhan Neethiraj (Jira)



 [ 
https://issues.apache.org/jira/browse/RANGER-3997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Madhan Neethiraj updated RANGER-3997:
-
Description: 
Consider following row-filter expression that refers to a user attribute: 
{code:java}
dept = ${{USER.dept}}{code}
 

For this expression to evaluate correctly, all users who run query on the table 
should have an attribute named dept. To handle users for whom this attribute is 
not defined, an additional policy-item would be required, as shown below:
{noformat}
1. "condition": "!HAS_USER_ATTR('dept')", "filterExpr": "dept = -1"
 
2. "filterExpr": "dept = ${{USER.dept}}"{noformat}
 

Ability to use a default value when the attribute doesn't exist will eliminate 
the need for the additional policy item, like:
{noformat}
 "filterExpr": "dept = ${{GET_USER_ATTR('dept', -1)}}{noformat}
 

Added following macros to support optional default value:

 
||Macro||With default value||Description||Example return value||
|GET_TAG_NAMES()|GET_TAG_NAMES('none')|Names of tags associated with the
resource, separated by a comma|PII,PCI|
|GET_TAG_ATTR_NAMES()|GET_TAG_ATTR_NAMES('none')|Names of attributes in tags 
associated
with the resource, separated by a comma|piiType,score|
|GET_TAG_ATTR('score')|GET_TAG_ATTR('score', 0)|Attribute value in tags 
associated with the
resource, separated by a comma|0|
|GET_UG_NAMES()|GET_UG_NAMES('none')|Names of groups the user belongs to,
separated by a comma|analyst,manager|
|GET_UG_ATTR_NAMES()|GET_UG_ATTR_NAMES('none')|Names of all attributes in 
groups the user
belongs to, separated by a comma|dept,site|
|GET_UG_ATTR('site')|GET_UG_ATTR('site', 'none')|Attribute value in groups the 
user belongs to,
separated by a comma|10,20|
|GET_UR_NAMES()|GET_UR_NAMES('none')|Names of roles assigned to the user,
separated by a comma|data-steward,admin|
|GET_USER_ATTR_NAMES()|GET_USER_ATTR_NAMES('none')|Names of all attributes of 
the user,
separated by a comma|name,email|
|GET_USER_ATTR('email')|GET_USER_ATTR('email', 'none')|Value of user 
attribute|n...@domain.com|

 

For each macro listed above, there is another version with *_Q* added to the 
name, like:
{code:java}
GET_TAG_NAMES_Q(){code}
 These macros would quote each value, like:
{code:java}
'PII','PCI'{code}
 

  was:
Consider following row-filter expression that refers to a user attribute: 
{code:java}
dept = ${{USER.dept}}{code}
 

For this expression to evaluate correctly, all users who run query on the table 
should have an attribute named dept. To handle users for whom this attribute is 
not defined, an additional policy-item would be required, as shown below:
{noformat}
1. "condition": "!HAS_USER_ATTR('dept')", "filterExpr": "dept = -1"
 
2. "filterExpr": "dept = ${{USER.dept}}"{noformat}
 

Ability to use a default value when the attribute doesn't exist will eliminate 
the need for the additional policy item, like:
{noformat}
 "filterExpr": "dept = ${{GET_USER_ATTR('dept', -1)}}{noformat}
 

Added following macros to support optional default value:

 
||Macro||With default value||Description||Example return value||
|GET_TAG_NAMES()|GET_TAG_NAMES('none')|Names of tags associated with the 
resource,
separated by a comma|PII,PCI|
|GET_TAG_ATTR_NAMES()|GET_TAG_ATTR_NAMES('none')|Names of attributes in tags 
associated
with the resource, separated by a comma|piiType,score|
|GET_TAG_ATTR('score')|GET_TAG_ATTR('score', 0)|Attribute value in tags 
associated with the
resource, separated by a comma|0|
|GET_UG_NAMES()|GET_UG_NAMES('none')|Names of groups the user belongs to,
separated by a comma|analyst,manager|
|GET_UG_ATTR_NAMES()|GET_UG_ATTR_NAMES('none')|Names of all attributes in 
groups the user
belongs to, separated by a comma|dept,site|
|GET_UG_ATTR('site')|GET_UG_ATTR('site', 'none')|Attribute value in groups the 
user belongs to,
separated by a comma|10,20|
|GET_UR_NAMES()|GET_UR_NAMES('none')|Names of roles assigned to the user,
separated by a comma|data-steward,admin|
|GET_USER_ATTR_NAMES()|GET_USER_ATTR_NAMES('none')|Names of all attributes of 
the user,
separated by a comma|name,email|
|GET_USER_ATTR('email')|GET_USER_ATTR('email', 'none')|Value of user 
attribute|n...@domain.com|

 

For each macro listed above, there is another version with *_Q* added to the 
name, like:
{code:java}
GET_TAG_NAMES_Q(){code}
 These macros would quote each value, like:
{code:java}
'PII','PCI'{code}
 


> option to use default value when user/group/tag does not have the attribute
> ---
>
> Key: RANGER-3997
> URL: https://issues.apache.org/jira/browse/RANGER-3997
> Project: Ranger
>  Issue Type: Improvement
>  Components: plugins
>Reporter: Madhan Neethiraj
>Assignee: Madhan Neethiraj
>Priority: Major
> Fix For: 3.0.0, 2.4.0
>
> Attachments:

[jira] [Updated] (RANGER-3997) option to use default value when user/group/tag does not have the attribute

2022-12-06 Thread Madhan Neethiraj (Jira)



 [ 
https://issues.apache.org/jira/browse/RANGER-3997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Madhan Neethiraj updated RANGER-3997:
-
Description: 
Consider following row-filter expression that refers to a user attribute: 
{code:java}
dept = ${{USER.dept}}{code}
 

For this expression to evaluate correctly, all users who run query on the table 
should have an attribute named dept. To handle users for whom this attribute is 
not defined, an additional policy-item would be required, as shown below:
{noformat}
1. "condition": "!HAS_USER_ATTR('dept')", "filterExpr": "dept = -1"
 
2. "filterExpr": "dept = ${{USER.dept}}"{noformat}
 

Ability to use a default value when the attribute doesn't exist will eliminate 
the need for the additional policy item, like:
{noformat}
 "filterExpr": "dept = ${{GET_USER_ATTR('dept', -1)}}{noformat}
 

Added following macros to support optional default value:

 
||Macro||With default value||Description||Example return value||
|GET_TAG_NAMES()|GET_TAG_NAMES('none')|Names of tags associated with the
resource, separated by a comma|PII,PCI|
|GET_TAG_ATTR_NAMES()|GET_TAG_ATTR_NAMES('none')|Names of attributes in tags 
associated
with the resource, separated by a comma|piiType,score|
|GET_TAG_ATTR('score')|GET_TAG_ATTR('score', 0)|Attribute value in tags 
associated with the
resource, separated by a comma|0|
|GET_UG_NAMES()|GET_UG_NAMES('none')|Names of groups the user belongs to,
separated by a comma|analyst,manager|
|GET_UG_ATTR_NAMES()|GET_UG_ATTR_NAMES('none')|Names of all attributes in 
groups the user
belongs to, separated by a comma|dept,site|
|GET_UG_ATTR('site')|GET_UG_ATTR('site', 'none')|Attribute value in groups the 
user belongs
to, separated by a comma|10,20|
|GET_UR_NAMES()|GET_UR_NAMES('none')|Names of roles assigned to the user,
separated by a comma|data-steward,admin|
|GET_USER_ATTR_NAMES()|GET_USER_ATTR_NAMES('none')|Names of all attributes of 
the user,
separated by a comma|name,email|
|GET_USER_ATTR('email')|GET_USER_ATTR('email', 'none')|Value of user 
attribute|n...@domain.com|

 

For each macro listed above, there is another version with *_Q* added to the 
name, like:
{code:java}
GET_TAG_NAMES_Q(){code}
 These macros would quote each value, like:
{code:java}
'PII','PCI'{code}
 

  was:
Consider following row-filter expression that refers to a user attribute: 
{code:java}
dept = ${{USER.dept}}{code}
 

For this expression to evaluate correctly, all users who run query on the table 
should have an attribute named dept. To handle users for whom this attribute is 
not defined, an additional policy-item would be required, as shown below:
{noformat}
1. "condition": "!HAS_USER_ATTR('dept')", "filterExpr": "dept = -1"
 
2. "filterExpr": "dept = ${{USER.dept}}"{noformat}
 

Ability to use a default value when the attribute doesn't exist will eliminate 
the need for the additional policy item, like:
{noformat}
 "filterExpr": "dept = ${{GET_USER_ATTR('dept', -1)}}{noformat}
 

Added following macros to support optional default value:

 
||Macro||With default value||Description||Example return value||
|GET_TAG_NAMES()|GET_TAG_NAMES('none')|Names of tags associated with the
resource, separated by a comma|PII,PCI|
|GET_TAG_ATTR_NAMES()|GET_TAG_ATTR_NAMES('none')|Names of attributes in tags 
associated
with the resource, separated by a comma|piiType,score|
|GET_TAG_ATTR('score')|GET_TAG_ATTR('score', 0)|Attribute value in tags 
associated with the
resource, separated by a comma|0|
|GET_UG_NAMES()|GET_UG_NAMES('none')|Names of groups the user belongs to,
separated by a comma|analyst,manager|
|GET_UG_ATTR_NAMES()|GET_UG_ATTR_NAMES('none')|Names of all attributes in 
groups the user
belongs to, separated by a comma|dept,site|
|GET_UG_ATTR('site')|GET_UG_ATTR('site', 'none')|Attribute value in groups the 
user belongs to,
separated by a comma|10,20|
|GET_UR_NAMES()|GET_UR_NAMES('none')|Names of roles assigned to the user,
separated by a comma|data-steward,admin|
|GET_USER_ATTR_NAMES()|GET_USER_ATTR_NAMES('none')|Names of all attributes of 
the user,
separated by a comma|name,email|
|GET_USER_ATTR('email')|GET_USER_ATTR('email', 'none')|Value of user 
attribute|n...@domain.com|

 

For each macro listed above, there is another version with *_Q* added to the 
name, like:
{code:java}
GET_TAG_NAMES_Q(){code}
 These macros would quote each value, like:
{code:java}
'PII','PCI'{code}
 


> option to use default value when user/group/tag does not have the attribute
> ---
>
> Key: RANGER-3997
> URL: https://issues.apache.org/jira/browse/RANGER-3997
> Project: Ranger
>  Issue Type: Improvement
>  Components: plugins
>Reporter: Madhan Neethiraj
>Assignee: Madhan Neethiraj
>Priority: Major
> Fix For: 3.0.0, 2.4.0
>
> Attachments:

[jira] [Updated] (RANGER-3997) option to use default value when user/group/tag does not have the attribute

2022-12-06 Thread Madhan Neethiraj (Jira)



 [ 
https://issues.apache.org/jira/browse/RANGER-3997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Madhan Neethiraj updated RANGER-3997:
-
Description: 
Consider following row-filter expression that refers to a user attribute: 
{code:java}
dept = ${{USER.dept}}{code}
 

For this expression to evaluate correctly, all users who run query on the table 
should have an attribute named dept. To handle users for whom this attribute is 
not defined, an additional policy-item would be required, as shown below:
{noformat}
1. "condition": "!HAS_USER_ATTR('dept')", "filterExpr": "dept = -1"
 
2. "filterExpr": "dept = ${{USER.dept}}"{noformat}
 

Ability to use a default value when the attribute doesn't exist will eliminate 
the need for the additional policy item, like:
{noformat}
 "filterExpr": "dept = ${{GET_USER_ATTR('dept', -1)}}{noformat}
 

Added following macros to support optional default value:

 
||Macro||With default value||Description||Example return value||
|GET_TAG_NAMES()|GET_TAG_NAMES('none')|Names of tags associated with the 
resource,
separated by a comma|PII,PCI|
|GET_TAG_ATTR_NAMES()|GET_TAG_ATTR_NAMES('none')|Names of attributes in tags 
associated
with the resource, separated by a comma|piiType,score|
|GET_TAG_ATTR('score')|GET_TAG_ATTR('score', 0)|Attribute value in tags 
associated with the
resource, separated by a comma|0|
|GET_UG_NAMES()|GET_UG_NAMES('none')|Names of groups the user belongs to,
separated by a comma|analyst,manager|
|GET_UG_ATTR_NAMES()|GET_UG_ATTR_NAMES('none')|Names of all attributes in 
groups the user
belongs to, separated by a comma|dept,site|
|GET_UG_ATTR('site')|GET_UG_ATTR('site', 'none')|Attribute value in groups the 
user belongs to,
separated by a comma|10,20|
|GET_UR_NAMES()|GET_UR_NAMES('none')|Names of roles assigned to the user,
separated by a comma|data-steward,admin|
|GET_USER_ATTR_NAMES()|GET_USER_ATTR_NAMES('none')|Names of all attributes of 
the user,
separated by a comma|name,email|
|GET_USER_ATTR('email')|GET_USER_ATTR('email', 'none')|Value of user 
attribute|n...@domain.com|

 

For each macro listed above, there is another version with *_Q* added to the 
name, like:
{code:java}
GET_TAG_NAMES_Q(){code}
 These macros would quote each value, like:
{code:java}
'PII','PCI'{code}
 

  was:
Consider following row-filter expression that refers to a user attribute: 
{code:java}
dept = ${{USER.dept}}{code}
 

For this expression to evaluate correctly, all users who run query on the table 
should have an attribute named dept. To handle users for whom this attribute is 
not defined, an additional policy-item would be required, as shown below:
{noformat}
1. "condition": "!HAS_USER_ATTR('dept')", "filterExpr": "dept = -1"
 
2. "filterExpr": "dept = ${{USER.dept}}"{noformat}
 

Ability to use a default value when the attribute doesn't exist will eliminate 
the need for the additional policy item, like:
{noformat}
 "filterExpr": "dept = ${{GET_USER_ATTR('dept', -1)}}{noformat}
 

Added following macros to support optional default value:

 
||Macro||With default value||Description||Example return value||
|GET_TAG_NAMES()|GET_TAG_NAMES('none')|Names of tags associated with the 
resource, separated by a comma|PII,PCI|
|GET_TAG_ATTR_NAMES()|GET_TAG_ATTR_NAMES('none')|Names of attributes in tags 
associated with the resource, separated by a comma|piiType,score|
|GET_TAG_ATTR('score')|GET_TAG_ATTR('score', 0)|Attribute value in tags 
associated with the resource, separated by a comma|0|
|GET_UG_NAMES()|GET_UG_NAMES('none')|Names of groups the user belongs to, 
separated by a comma|analyst,manager|
|GET_UG_ATTR_NAMES()|GET_UG_ATTR_NAMES('none')|Names of all attributes in 
groups the user belongs to, separated by a comma|dept,site|
|GET_UG_ATTR('site')|GET_UG_ATTR('site', 'none')|Attribute value in groups the 
user belongs to, separated by a comma|10,20|
|GET_UR_NAMES()|GET_UR_NAMES('none')|Names of roles assigned to the user, 
separated by a comma|data-steward,admin|
|GET_USER_ATTR_NAMES()|GET_USER_ATTR_NAMES('none')|Names of all attributes of 
the user, separated by a comma|name,email|
|GET_USER_ATTR('email')|GET_USER_ATTR('email', 'none')|Value of user 
attribute|n...@domain.com|

 

For each macro listed above, there is another version with *_Q* added to the 
name, like:
{code:java}
GET_TAG_NAMES_Q(){code}
 These macros would quote each value, like:
{code:java}
'PII','PCI'{code}
 


> option to use default value when user/group/tag does not have the attribute
> ---
>
> Key: RANGER-3997
> URL: https://issues.apache.org/jira/browse/RANGER-3997
> Project: Ranger
>  Issue Type: Improvement
>  Components: plugins
>Reporter: Madhan Neethiraj
>Assignee: Madhan Neethiraj
>Priority: Major
> Fix For: 3.0.0, 2.4.0
>
>

[jira] [Updated] (RANGER-3997) option to use default value when user/group/tag does not have the attribute

2022-12-06 Thread Madhan Neethiraj (Jira)



 [ 
https://issues.apache.org/jira/browse/RANGER-3997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Madhan Neethiraj updated RANGER-3997:
-
Description: 
Consider following row-filter expression that refers to a user attribute: 
{code:java}
dept = ${{USER.dept}}{code}
 

For this expression to evaluate correctly, all users who run query on the table 
should have an attribute named dept. To handle users for whom this attribute is 
not defined, an additional policy-item would be required, as shown below:
{noformat}
1. "condition": "!HAS_USER_ATTR('dept')", "filterExpr": "dept = -1"
 
2. "filterExpr": "dept = ${{USER.dept}}"{noformat}
 

Ability to use a default value when the attribute doesn't exist will eliminate 
the need for the additional policy item, like:
{noformat}
 "filterExpr": "dept = ${{GET_USER_ATTR('dept', -1)}}{noformat}
 

Added following macros to support optional default value:

 
||Macro||With default value||Description||Example return value||
|GET_TAG_NAMES()|GET_TAG_NAMES('none')|Names of tags associated with the 
resource, separated by a comma|PII,PCI|
|GET_TAG_ATTR_NAMES()|GET_TAG_ATTR_NAMES('none')|Names of attributes in tags 
associated with the resource, separated by a comma|piiType,score|
|GET_TAG_ATTR('score')|GET_TAG_ATTR('score', 0)|Attribute value in tags 
associated with the resource, separated by a comma|0|
|GET_UG_NAMES()|GET_UG_NAMES('none')|Names of groups the user belongs to, 
separated by a comma|analyst,manager|
|GET_UG_ATTR_NAMES()|GET_UG_ATTR_NAMES('none')|Names of all attributes in 
groups the user belongs to, separated by a comma|dept,site|
|GET_UG_ATTR('site')|GET_UG_ATTR('site', 'none')|Attribute value in groups the 
user belongs to, separated by a comma|10,20|
|GET_UR_NAMES()|GET_UR_NAMES('none')|Names of roles assigned to the user, 
separated by a comma|data-steward,admin|
|GET_USER_ATTR_NAMES()|GET_USER_ATTR_NAMES('none')|Names of all attributes of 
the user, separated by a comma|name,email|
|GET_USER_ATTR('email')|GET_USER_ATTR('email', 'none')|Value of user 
attribute|n...@domain.com|

 

For each macro listed above, there is another version with *_Q* added to the 
name, like:
{code:java}
GET_TAG_NAMES_Q(){code}
 These macros would quote each value, like:
{code:java}
'PII','PCI'{code}
 

  was:
Consider following row-filter expression that refers to a user attribute: 
{code:java}
dept = ${{USER.dept}}{code}
 

For this expression to evaluate correctly, all users who run query on the table 
should have an attribute named dept. To handle users for whom this attribute is 
not defined, an additional policy-item would be required, as shown below:
{noformat}
1. "condition": "!HAS_USER_ATTR('dept')", "filterExpr": "dept = -1"
 
2. "filterExpr": "dept = ${{USER.dept}}"{noformat}
 

Ability to use a default value when the attribute doesn't exist will eliminate 
the need for the additional policy item, like:
{noformat}
 "filterExpr": "dept = ${{GET_USER_ATTR('dept', -1)}}{noformat}
 

Added following macros to support optional default value:

 

- GET_TAG_NAMES(), GET_TAG_NAMES('none')


> option to use default value when user/group/tag does not have the attribute
> ---
>
> Key: RANGER-3997
> URL: https://issues.apache.org/jira/browse/RANGER-3997
> Project: Ranger
>  Issue Type: Improvement
>  Components: plugins
>Reporter: Madhan Neethiraj
>Assignee: Madhan Neethiraj
>Priority: Major
> Fix For: 3.0.0, 2.4.0
>
> Attachments: RANGER-3997.patch
>
>
> Consider following row-filter expression that refers to a user attribute: 
> {code:java}
> dept = ${{USER.dept}}{code}
>  
> For this expression to evaluate correctly, all users who run query on the 
> table should have an attribute named dept. To handle users for whom this 
> attribute is not defined, an additional policy-item would be required, as 
> shown below:
> {noformat}
> 1. "condition": "!HAS_USER_ATTR('dept')", "filterExpr": "dept = -1"
>  
> 2. "filterExpr": "dept = ${{USER.dept}}"{noformat}
>  
> Ability to use a default value when the attribute doesn't exist will 
> eliminate the need for the additional policy item, like:
> {noformat}
>  "filterExpr": "dept = ${{GET_USER_ATTR('dept', -1)}}{noformat}
>  
> Added following macros to support optional default value:
>  
> ||Macro||With default value||Description||Example return value||
> |GET_TAG_NAMES()|GET_TAG_NAMES('none')|Names of tags associated with the 
> resource, separated by a comma|PII,PCI|
> |GET_TAG_ATTR_NAMES()|GET_TAG_ATTR_NAMES('none')|Names of attributes in tags 
> associated with the resource, separated by a comma|piiType,score|
> |GET_TAG_ATTR('score')|GET_TAG_ATTR('score', 0)|Attribute value in tags 
> associated with the resource, separated by a comma|0|
>

[jira] [Updated] (RANGER-3997) option to use default value when user/group/tag does not have the attribute

2022-12-06 Thread Madhan Neethiraj (Jira)



 [ 
https://issues.apache.org/jira/browse/RANGER-3997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Madhan Neethiraj updated RANGER-3997:
-
Description: 
Consider following row-filter expression that refers to a user attribute: 
{code:java}
dept = ${{USER.dept}}{code}
 

For this expression to evaluate correctly, all users who run query on the table 
should have an attribute named dept. To handle users for whom this attribute is 
not defined, an additional policy-item would be required, as shown below:
{noformat}
1. "condition": "!HAS_USER_ATTR('dept')", "filterExpr": "dept = -1"
 
2. "filterExpr": "dept = ${{USER.dept}}"{noformat}
 

Ability to use a default value when the attribute doesn't exist will eliminate 
the need for the additional policy item, like:
{noformat}
 "filterExpr": "dept = ${{GET_USER_ATTR('dept', -1)}}{noformat}
 

Added following macros to support optional default value:

 

- GET_TAG_NAMES(), GET_TAG_NAMES('none')

  was:
Consider following row-filter expression that refers to a user attribute: 
{code:java}
dept = ${{USER.dept}}{code}
 

For this expression to evaluate correctly, all users who run query on the table 
should have an attribute named dept. To handle users for whom this attribute is 
not defined, an additional policy-item would be required, as shown below:
{noformat}
1. "condition": "!HAS_USER_ATTR('dept')", "filterExpr": "dept = -1"
 
2. "filterExpr": "dept = ${{USER.dept}}"{noformat}
 

Ability to use a default value when the attribute doesn't exist will eliminate 
the need for the additional policy item, like:
{noformat}
 "filterExpr": "dept = ${{GET_USER_ATTR('dept', -1)}}{noformat}


> option to use default value when user/group/tag does not have the attribute
> ---
>
> Key: RANGER-3997
> URL: https://issues.apache.org/jira/browse/RANGER-3997
> Project: Ranger
>  Issue Type: Improvement
>  Components: plugins
>Reporter: Madhan Neethiraj
>Assignee: Madhan Neethiraj
>Priority: Major
> Fix For: 3.0.0, 2.4.0
>
> Attachments: RANGER-3997.patch
>
>
> Consider following row-filter expression that refers to a user attribute: 
> {code:java}
> dept = ${{USER.dept}}{code}
>  
> For this expression to evaluate correctly, all users who run query on the 
> table should have an attribute named dept. To handle users for whom this 
> attribute is not defined, an additional policy-item would be required, as 
> shown below:
> {noformat}
> 1. "condition": "!HAS_USER_ATTR('dept')", "filterExpr": "dept = -1"
>  
> 2. "filterExpr": "dept = ${{USER.dept}}"{noformat}
>  
> Ability to use a default value when the attribute doesn't exist will 
> eliminate the need for the additional policy item, like:
> {noformat}
>  "filterExpr": "dept = ${{GET_USER_ATTR('dept', -1)}}{noformat}
>  
> Added following macros to support optional default value:
>  
> - GET_TAG_NAMES(), GET_TAG_NAMES('none')



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (RANGER-4000) unit test failure in JDK17

2022-12-06 Thread Madhan Neethiraj (Jira)



 [ 
https://issues.apache.org/jira/browse/RANGER-4000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Madhan Neethiraj updated RANGER-4000:
-
Attachment: RANGER-4000.patch

> unit test failure in JDK17
> --
>
> Key: RANGER-4000
> URL: https://issues.apache.org/jira/browse/RANGER-4000
> Project: Ranger
>  Issue Type: Bug
>  Components: plugins
>Reporter: Madhan Neethiraj
>Assignee: Madhan Neethiraj
>Priority: Major
> Fix For: 3.0.0, 2.4.0
>
> Attachments: RANGER-4000.patch
>
>
> Following expression in test_policyengine_geo.json fails with JDK17 (script 
> engine from org.graalvm.js):
> {code:java}
> (!!country_code_format_long && !!country_code_format_dot && 
> (country_code_format_long == country_code_format_dot)){code}
>  
> This expression should be updated with:
> {noformat}
> (country_code_format_long != null && country_code_format_dot != null && 
> (country_code_format_long == country_code_format_dot)) {noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Review Request 74237: RANGER-4000: fixed plugins-common library unit tests for JDK17

2022-12-06 Thread Madhan Neethiraj


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

Review request for ranger and Abhay Kulkarni.


Bugs: RANGER-4000
https://issues.apache.org/jira/browse/RANGER-4000


Repository: ranger


Description
---

fixed plugins-common library unit tests for JDK17


Diffs
-

  agents-common/src/test/resources/policyengine/test_policyengine_geo.json 
4249996b8 


Diff: https://reviews.apache.org/r/74237/diff/1/


Testing
---

- verified that all unit tests in plugins-common library pass with JDK17


Thanks,

Madhan Neethiraj

[jira] [Created] (RANGER-4000) unit test failure in JDK17

2022-12-06 Thread Madhan Neethiraj (Jira)

Madhan Neethiraj created RANGER-4000:


 Summary: unit test failure in JDK17
 Key: RANGER-4000
 URL: https://issues.apache.org/jira/browse/RANGER-4000
 Project: Ranger
  Issue Type: Bug
  Components: plugins
Reporter: Madhan Neethiraj
Assignee: Madhan Neethiraj


Following expression in test_policyengine_geo.json fails with JDK17 (script 
engine from org.graalvm.js):
{code:java}
(!!country_code_format_long && !!country_code_format_dot && 
(country_code_format_long == country_code_format_dot)){code}
 

This expression should be updated with:
{noformat}
(country_code_format_long != null && country_code_format_dot != null && 
(country_code_format_long == country_code_format_dot)) {noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: Review Request 74232: RANGER-3999: Implement more efficient way to handle _any access authorization

2022-12-06 Thread Madhan Neethiraj


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




agents-common/src/main/java/org/apache/ranger/plugin/policyengine/RangerPolicyEngineImpl.java
Line 704 (original), 700 (patched)


"all" seems to be an accessType in Hive. Is this special handling necessary 
in policy engine?



agents-common/src/main/java/org/apache/ranger/plugin/policyevaluator/RangerDefaultPolicyEvaluator.java
Lines 838 (patched)


if request is not RangerAccessRequestImpl, #838 would result in cast error. 
Please consider handling this case - perhaps by a request-wrapper class like:

public class RangerAccessRequestWrapper implements RangerAccessRequest {
  private final RangerAccessRequest request;
  private final String  accessType;
  private final boolean isAccessTypeAny;
  private final boolean isAccessTypeDelegatedAdmin;

  public RangerAccessRequestWrapper(RangerAccessRequest request, String 
accessType) {
this.request= request;
this.accessType = accessType;
this.isAccessTypeAny= StringUtils.equals(accessType, 
RangerPolicyEngine.ANY_ACCESS)
this.isAccessTypeDelegatedAdmin = StringUtils.equals(accessType, 
RangerPolicyEngine.ADMIN_ACCESS);
  }

  @Override
  public String getAccessType() { return accessType; }

  @Override
  public boolean isAccessTypeAny() { return isAccessTypeAny; }

  @Override
  public boolean isAccessTypeDelegatedAdmin() { return 
isAccessTypeDelegatedAdmin; }

  // other methods simply call corresponding method on request, like:
  @Override
  public RangerAccessResource getResource() { return request.getResource(); 
}

  ...
}



agents-common/src/main/java/org/apache/ranger/plugin/policyevaluator/RangerOptimizedPolicyEvaluator.java
Lines 262 (patched)


Consider adding following method to have all type casting in one place:

class RangerAccessRequestUtil {
  ...

  public static Set getAllRequestedAccessTypes(Map 
context) {
return (Set) context.get(KEY_CONTEXT_ACCESSTYPES);
  }
}


- Madhan Neethiraj


On Dec. 6, 2022, 5:58 p.m., Abhay Kulkarni wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/74232/
> ---
> 
> (Updated Dec. 6, 2022, 5:58 p.m.)
> 
> 
> Review request for ranger, madhan, Madhan Neethiraj, Ramesh Mani, Sailaja 
> Polavarapu, and Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-3999
> https://issues.apache.org/jira/browse/RANGER-3999
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> If a user-initiated operation requires checking if more than one permission 
> is granted, then currently, each permission requires a call to internal 
> Policy Engine API for the same accessed resource. This leads to many 
> repetitive computations which may be avoided if the policy engine API 
> supports multiple permissions. In that case, optimization may be achieved by 
> pushing authorization for multiple permissions down to the lowest possible 
> level.
> 
> 
> Diffs
> -
> 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/policyengine/RangerPolicyEngineImpl.java
>  23db18f3a 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/policyevaluator/RangerDefaultPolicyEvaluator.java
>  520ddf865 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/policyevaluator/RangerOptimizedPolicyEvaluator.java
>  d3fc27d7d 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/util/RangerAccessRequestUtil.java
>  df03ed1c4 
> 
> 
> Diff: https://reviews.apache.org/r/74232/diff/2/
> 
> 
> Testing
> ---
> 
> Passed all existing unit tests.
> 
> 
> Thanks,
> 
> Abhay Kulkarni
> 
>

Re: Review Request 74231: RANGER-3996: upgraded commons-configuration2 version to 2.8.0

2022-12-06 Thread Madhan Neethiraj



> On Dec. 6, 2022, 10:37 a.m., Ankita Sinha wrote:
> > Need to handle it in 
> > https://github.com/apache/ranger/blob/master/plugin-solr/pom.xml

Ankita - plugins-solr doesn't use configuration2. Can you please add details?


- Madhan


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


On Dec. 6, 2022, 6:19 p.m., Madhan Neethiraj wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/74231/
> ---
> 
> (Updated Dec. 6, 2022, 6:19 p.m.)
> 
> 
> Review request for ranger, Abhishek  Kumar, Ankita Sinha, Don Bosco Durai, 
> deepak sharma, Kishor Gollapalliwar, Abhay Kulkarni, Mehul Parikh, Pradeep 
> Agrawal, Ramesh Mani, Siddhesh Phatak, Selvamohan Neethiraj, Sailaja 
> Polavarapu, Subhrat Chaudhary, and Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-3996
> https://issues.apache.org/jira/browse/RANGER-3996
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> - updated commons-configurations2 version from 2.1.1 to 2.8.0
> 
> 
> Diffs
> -
> 
>   agents-audit/pom.xml 0b106633d 
>   agents-common/pom.xml 97a51fc32 
>   agents-cred/pom.xml 124a5a861 
>   credentialbuilder/pom.xml 6d7ff0e5b 
>   hbase-agent/pom.xml 4029fc0a5 
>   hdfs-agent/pom.xml 6b974e02b 
>   kms/pom.xml b6a2cf78e 
>   pom.xml dc09328dc 
>   ranger-authn/pom.xml 952b0d3e3 
>   ranger-examples/plugin-sampleapp/pom.xml 95e401b5a 
>   ranger-hdfs-plugin-shim/pom.xml 700905d0f 
>   ranger-storm-plugin-shim/pom.xml c5bcad48b 
>   security-admin/pom.xml 54bd231d8 
>   storm-agent/pom.xml 90fe25efd 
>   tagsync/pom.xml 8b453f44f 
>   ugsync/ldapconfigchecktool/ldapconfigcheck/pom.xml 3236d017d 
>   ugsync/pom.xml 22918e554 
>   unixauthclient/pom.xml 1d2a63e9a 
> 
> 
> Diff: https://reviews.apache.org/r/74231/diff/2/
> 
> 
> Testing
> ---
> 
> - verified that Ranger has no dependency on earlier version of 
> commons-configuration2
> - verified that all tests completed successfully
> - built and deployed Ranger and plugins using docker
> 
> 
> Thanks,
> 
> Madhan Neethiraj
> 
>

Re: Review Request 74231: RANGER-3996: upgraded commons-configuration2 version to 2.8.0

2022-12-06 Thread Madhan Neethiraj


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

(Updated Dec. 6, 2022, 6:19 p.m.)


Review request for ranger, Abhishek  Kumar, Ankita Sinha, Don Bosco Durai, 
deepak sharma, Kishor Gollapalliwar, Abhay Kulkarni, Mehul Parikh, Pradeep 
Agrawal, Ramesh Mani, Siddhesh Phatak, Selvamohan Neethiraj, Sailaja 
Polavarapu, Subhrat Chaudhary, and Velmurugan Periasamy.


Changes
---

excluding older version commons-text library pulled in by configuration2


Bugs: RANGER-3996
https://issues.apache.org/jira/browse/RANGER-3996


Repository: ranger


Description
---

- updated commons-configurations2 version from 2.1.1 to 2.8.0


Diffs (updated)
-

  agents-audit/pom.xml 0b106633d 
  agents-common/pom.xml 97a51fc32 
  agents-cred/pom.xml 124a5a861 
  credentialbuilder/pom.xml 6d7ff0e5b 
  hbase-agent/pom.xml 4029fc0a5 
  hdfs-agent/pom.xml 6b974e02b 
  kms/pom.xml b6a2cf78e 
  pom.xml dc09328dc 
  ranger-authn/pom.xml 952b0d3e3 
  ranger-examples/plugin-sampleapp/pom.xml 95e401b5a 
  ranger-hdfs-plugin-shim/pom.xml 700905d0f 
  ranger-storm-plugin-shim/pom.xml c5bcad48b 
  security-admin/pom.xml 54bd231d8 
  storm-agent/pom.xml 90fe25efd 
  tagsync/pom.xml 8b453f44f 
  ugsync/ldapconfigchecktool/ldapconfigcheck/pom.xml 3236d017d 
  ugsync/pom.xml 22918e554 
  unixauthclient/pom.xml 1d2a63e9a 


Diff: https://reviews.apache.org/r/74231/diff/2/

Changes: https://reviews.apache.org/r/74231/diff/1-2/


Testing
---

- verified that Ranger has no dependency on earlier version of 
commons-configuration2
- verified that all tests completed successfully
- built and deployed Ranger and plugins using docker


Thanks,

Madhan Neethiraj

Re: Review Request 74232: RANGER-3999: Implement more efficient way to handle _any access authorization

2022-12-06 Thread Abhay Kulkarni


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

(Updated Dec. 6, 2022, 5:58 p.m.)


Review request for ranger, madhan, Madhan Neethiraj, Ramesh Mani, Sailaja 
Polavarapu, and Velmurugan Periasamy.


Changes
---

Updated with the JIRA details


Summary (updated)
-

RANGER-3999: Implement more efficient way to handle _any access authorization


Bugs: RANGER-3999
https://issues.apache.org/jira/browse/RANGER-3999


Repository: ranger


Description (updated)
---

If a user-initiated operation requires checking if more than one permission is 
granted, then currently, each permission requires a call to internal Policy 
Engine API for the same accessed resource. This leads to many repetitive 
computations which may be avoided if the policy engine API supports multiple 
permissions. In that case, optimization may be achieved by pushing 
authorization for multiple permissions down to the lowest possible level.


Diffs
-

  
agents-common/src/main/java/org/apache/ranger/plugin/policyengine/RangerPolicyEngineImpl.java
 23db18f3a 
  
agents-common/src/main/java/org/apache/ranger/plugin/policyevaluator/RangerDefaultPolicyEvaluator.java
 520ddf865 
  
agents-common/src/main/java/org/apache/ranger/plugin/policyevaluator/RangerOptimizedPolicyEvaluator.java
 d3fc27d7d 
  
agents-common/src/main/java/org/apache/ranger/plugin/util/RangerAccessRequestUtil.java
 df03ed1c4 


Diff: https://reviews.apache.org/r/74232/diff/2/


Testing
---

Passed all existing unit tests.


Thanks,

Abhay Kulkarni

[jira] [Assigned] (RANGER-3999) Implement more efficient way to handle _any access authorization

2022-12-06 Thread Abhay Kulkarni (Jira)



 [ 
https://issues.apache.org/jira/browse/RANGER-3999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Abhay Kulkarni reassigned RANGER-3999:
--

Assignee: Abhay Kulkarni

> Implement more efficient way to handle _any access authorization
> 
>
> Key: RANGER-3999
> URL: https://issues.apache.org/jira/browse/RANGER-3999
> Project: Ranger
>  Issue Type: Improvement
>  Components: Ranger
>Reporter: Abhay
>Assignee: Abhay Kulkarni
>Priority: Major
>
> If a user-initiated operation requires checking if more than one permission 
> is granted, then currently, each permission requires a call to internal 
> Policy Engine API for the same accessed resource. This leads to many 
> repetitive computations which may be avoided if the policy engine API 
> supports multiple permissions. In that case, optimization may be achieved by 
> pushing authorization for multiple permissions down to the lowest possible 
> level.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (RANGER-3999) Implement more efficient way to handle _any access authorization

2022-12-06 Thread Abhay (Jira)

Abhay created RANGER-3999:
-

 Summary: Implement more efficient way to handle _any access 
authorization
 Key: RANGER-3999
 URL: https://issues.apache.org/jira/browse/RANGER-3999
 Project: Ranger
  Issue Type: Improvement
  Components: Ranger
Reporter: Abhay


If a user-initiated operation requires checking if more than one permission is 
granted, then currently, each permission requires a call to internal Policy 
Engine API for the same accessed resource. This leads to many repetitive 
computations which may be avoided if the policy engine API supports multiple 
permissions. In that case, optimization may be achieved by pushing 
authorization for multiple permissions down to the lowest possible level.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: Review Request 74231: RANGER-3996: upgraded commons-configuration2 version to 2.8.0

2022-12-06 Thread Ankita Sinha


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



Need to handle it in 
https://github.com/apache/ranger/blob/master/plugin-solr/pom.xml

- Ankita Sinha


On Dec. 4, 2022, 12:13 a.m., Madhan Neethiraj wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/74231/
> ---
> 
> (Updated Dec. 4, 2022, 12:13 a.m.)
> 
> 
> Review request for ranger, Abhishek  Kumar, Ankita Sinha, Don Bosco Durai, 
> deepak sharma, Kishor Gollapalliwar, Abhay Kulkarni, Mehul Parikh, Pradeep 
> Agrawal, Ramesh Mani, Siddhesh Phatak, Selvamohan Neethiraj, Sailaja 
> Polavarapu, Subhrat Chaudhary, and Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-3996
> https://issues.apache.org/jira/browse/RANGER-3996
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> - updated commons-configurations2 version from 2.1.1 to 2.8.0
> 
> 
> Diffs
> -
> 
>   agents-audit/pom.xml 0b106633d 
>   agents-common/pom.xml 97a51fc32 
>   agents-cred/pom.xml 124a5a861 
>   credentialbuilder/pom.xml 6d7ff0e5b 
>   hbase-agent/pom.xml 4029fc0a5 
>   hdfs-agent/pom.xml 6b974e02b 
>   kms/pom.xml b6a2cf78e 
>   pom.xml dc09328dc 
>   ranger-authn/pom.xml 952b0d3e3 
>   ranger-examples/plugin-sampleapp/pom.xml 95e401b5a 
>   ranger-hdfs-plugin-shim/pom.xml 700905d0f 
>   ranger-storm-plugin-shim/pom.xml c5bcad48b 
>   security-admin/pom.xml 54bd231d8 
>   storm-agent/pom.xml 90fe25efd 
> 
> 
> Diff: https://reviews.apache.org/r/74231/diff/1/
> 
> 
> Testing
> ---
> 
> - verified that Ranger has no dependency on earlier version of 
> commons-configuration2
> - verified that all tests completed successfully
> - built and deployed Ranger and plugins using docker
> 
> 
> Thanks,
> 
> Madhan Neethiraj
> 
>

[jira] [Created] (RANGER-3998) Support Ranger KMS integration with AWS KMS

2022-12-06 Thread kirby zhou (Jira)

kirby zhou created RANGER-3998:
--

 Summary: Support Ranger KMS integration with AWS KMS
 Key: RANGER-3998
 URL: https://issues.apache.org/jira/browse/RANGER-3998
 Project: Ranger
  Issue Type: Improvement
  Components: kms
Affects Versions: 3.0.0, 2.4.0
Reporter: kirby zhou


AWS KMS is widely used by many customers.

Therefore, RangerKMS should support hosting MasterKey to AWS KMS.

 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: Review Request 74231: RANGER-3996: upgraded commons-configuration2 version to 2.8.0

Review Request 74239: RANGER-4001:Wrong permission check for Hive 'Alter View as' command in Ranger HiveAuthorizer

[jira] [Assigned] (RANGER-4001) Wrong permission check for Hive "Alter View as" command in Ranger HiveAuthorizer

Re: Review Request 74237: RANGER-4000: fixed plugins-common library unit tests for JDK17

[jira] [Created] (RANGER-4001) Wrong permission check for Hive "Alter View as" command in Ranger HiveAuthorizer

[jira] [Commented] (RANGER-4000) unit test failure in JDK17

Re: Review Request 74232: RANGER-3999: Implement more efficient way to handle _any access authorization

Re: Review Request 74232: RANGER-3999: Implement more efficient way to handle _any access authorization

[jira] [Updated] (RANGER-3997) option to use default value when user/group/tag does not have the attribute

[jira] [Updated] (RANGER-3997) option to use default value when user/group/tag does not have the attribute

[jira] [Updated] (RANGER-3997) option to use default value when user/group/tag does not have the attribute

[jira] [Updated] (RANGER-3997) option to use default value when user/group/tag does not have the attribute

[jira] [Updated] (RANGER-3997) option to use default value when user/group/tag does not have the attribute

[jira] [Updated] (RANGER-4000) unit test failure in JDK17

Review Request 74237: RANGER-4000: fixed plugins-common library unit tests for JDK17

[jira] [Created] (RANGER-4000) unit test failure in JDK17

Re: Review Request 74232: RANGER-3999: Implement more efficient way to handle _any access authorization

Re: Review Request 74231: RANGER-3996: upgraded commons-configuration2 version to 2.8.0

Re: Review Request 74231: RANGER-3996: upgraded commons-configuration2 version to 2.8.0

Re: Review Request 74232: RANGER-3999: Implement more efficient way to handle _any access authorization

[jira] [Assigned] (RANGER-3999) Implement more efficient way to handle _any access authorization

[jira] [Created] (RANGER-3999) Implement more efficient way to handle _any access authorization

Re: Review Request 74231: RANGER-3996: upgraded commons-configuration2 version to 2.8.0

[jira] [Created] (RANGER-3998) Support Ranger KMS integration with AWS KMS

24 matches

Site Navigation

Mail list logo

Footer information