Re: Review Request 73983: RANGER-3754: Chained plugins access evaluation result is not considered in some cases

[Abhay Kulkarni]

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

(Updated May 11, 2022, 2:14 a.m.)


Review request for ranger, Madhan Neethiraj and Ramesh Mani.


Changes
---

Deleted unwanted file


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


Repository: ranger


Description
---

If the plugins are chained, the result of an access request combines the access 
result of the main plugin with the result reported by the plugin chained to the 
main plugin. In some cases (where fallback to native authorizer is not enabled 
for the main plugin), the result of the chained plugin's access result is not 
used if the chained plugin's policy that evaluated the access is of same or 
lower priority.


Diffs (updated)
-

  
agents-common/src/main/java/org/apache/ranger/plugin/service/RangerBasePlugin.java
 f157475bf 


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

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


Testing
---

Compiled and ran all unit tests successfully


Thanks,

Abhay Kulkarni

[jira] [Comment Edited] (RANGER-3182) Prestosql is renamed to Trino

[Aakash Nand (Jira)]

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

Aakash Nand edited comment on RANGER-3182 at 5/11/22 1:18 AM:
--

[~rmani] That's really sad. Any idea when Ranger will start using Java11? Can 
we make any setting in pom.xml to make only trino-plugin use JDK11 and keep the 
rest of the plugins to jdk8? 

 

There are so many trino users who wanted to use the trino-ranger-plugin and for 
them, I will keep my personal fork as an option to use the plugin and build 
with JDK11 and will try to maintain on best effort basis.

Whenever this issue status changes, let me know again. 

For anyone looking for alternative resources on this issue:
 * [https://github.com/aakashnand/ranger]
 * [https://github.com/aakashnand/trino-ranger-demo]
 * Tutorial: [Integrating-Trino-Ranger 
|https://towardsdatascience.com/integrating-trino-and-apache-ranger-b808f6b96ad8]


was (Author: aakashnand):
[~rmani] That's really sad. Any idea when Ranger will start using Java11? 

 

There are so many trino users who wanted to use the trino-ranger-plugin and for 
them, I will keep my personal fork as an option to use the plugin and build 
with JDK11 and will try to maintain on best effort basis.

Whenever this issue status changes, let me know again. 

For anyone looking for alternative resources on this issue:
 * [https://github.com/aakashnand/ranger]
 * [https://github.com/aakashnand/trino-ranger-demo]
 * Tutorial: [Integrating-Trino-Ranger 
|https://towardsdatascience.com/integrating-trino-and-apache-ranger-b808f6b96ad8]

> Prestosql is renamed to Trino
> -
>
> Key: RANGER-3182
> URL: https://issues.apache.org/jira/browse/RANGER-3182
> Project: Ranger
>  Issue Type: Improvement
>  Components: plugins
>Affects Versions: 2.1.0
>Reporter: Viacheslav Kriuchkov
>Assignee: Ramesh Mani
>Priority: Blocker
> Fix For: 3.0.0
>
> Attachments: 0001-RANGER-3182-Rename-Prestosql-to-Trino-master.patch, 
> 0001-RANGER-3182-Rename-Prestosql-to-Trino-ranger-2.3.patch, 
> ranger-commons-lang3-master.patch
>
>  Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> All "prestosql" classes are "trino" now and Presto plugin can't integrate 
> with Trino because of that. It means all Presto deployments that use Ranger 
> are stuck on version 350 and can't upgrade further.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Commented] (RANGER-3182) Prestosql is renamed to Trino

[Aakash Nand (Jira)]

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

Aakash Nand commented on RANGER-3182:
-

[~rmani] That's really sad. Any idea when Ranger will start using Java11? 

 

There are so many trino users who wanted to use the trino-ranger-plugin and for 
them, I will keep my personal fork as an option to use the plugin and build 
with JDK11 and will try to maintain on best effort basis.

Whenever this issue status changes, let me know again. 

For anyone looking for alternative resources on this issue:
 * [https://github.com/aakashnand/ranger]
 * [https://github.com/aakashnand/trino-ranger-demo]
 * Tutorial: [Integrating-Trino-Ranger 
|https://towardsdatascience.com/integrating-trino-and-apache-ranger-b808f6b96ad8]

> Prestosql is renamed to Trino
> -
>
> Key: RANGER-3182
> URL: https://issues.apache.org/jira/browse/RANGER-3182
> Project: Ranger
>  Issue Type: Improvement
>  Components: plugins
>Affects Versions: 2.1.0
>Reporter: Viacheslav Kriuchkov
>Assignee: Ramesh Mani
>Priority: Blocker
> Fix For: 3.0.0
>
> Attachments: 0001-RANGER-3182-Rename-Prestosql-to-Trino-master.patch, 
> 0001-RANGER-3182-Rename-Prestosql-to-Trino-ranger-2.3.patch, 
> ranger-commons-lang3-master.patch
>
>  Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> All "prestosql" classes are "trino" now and Presto plugin can't integrate 
> with Trino because of that. It means all Presto deployments that use Ranger 
> are stuck on version 350 and can't upgrade further.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

Re: Review Request 73983: RANGER-3754: Chained plugins access evaluation result is not considered in some cases

[Ramesh Mani]

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




RANGER-3590.patch
Lines 11 (patched)


I think this file has to be removed. May be accidently uploaded.


- Ramesh Mani


On May 10, 2022, 5:43 p.m., Abhay Kulkarni wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/73983/
> ---
> 
> (Updated May 10, 2022, 5:43 p.m.)
> 
> 
> Review request for ranger, Madhan Neethiraj and Ramesh Mani.
> 
> 
> Bugs: RANGER-3754
> https://issues.apache.org/jira/browse/RANGER-3754
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> If the plugins are chained, the result of an access request combines the 
> access result of the main plugin with the result reported by the plugin 
> chained to the main plugin. In some cases (where fallback to native 
> authorizer is not enabled for the main plugin), the result of the chained 
> plugin's access result is not used if the chained plugin's policy that 
> evaluated the access is of same or lower priority.
> 
> 
> Diffs
> -
> 
>   RANGER-3590.patch PRE-CREATION 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/service/RangerBasePlugin.java
>  f157475bf 
> 
> 
> Diff: https://reviews.apache.org/r/73983/diff/1/
> 
> 
> Testing
> ---
> 
> Compiled and ran all unit tests successfully
> 
> 
> Thanks,
> 
> Abhay Kulkarni
> 
>

Re: Review Request 73981: RANGER-3752: Restrict duplicate access types entries in policy creation

[Abhay Kulkarni]

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


Ship it!




Ship It!

- Abhay Kulkarni


On May 10, 2022, 7:31 p.m., Pradeep Agrawal wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/73981/
> ---
> 
> (Updated May 10, 2022, 7:31 p.m.)
> 
> 
> Review request for ranger, bhavik patel, Dhaval Shah, Abhay Kulkarni, Madhan 
> Neethiraj, Ramesh Mani, Sailaja Polavarapu, and Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-3752
> https://issues.apache.org/jira/browse/RANGER-3752
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> **Problem Statement:** While making a REST request to create Ranger policy, 
> it is possible that user can put same access type more than one. Since there 
> is no validation or restriction on duplicate entry of access type in the same 
> policy resource-policy items, policy get created successfully and policy text 
> json contains duplicate entries. 
> When user makes a GET request then duplicate entries are also shown. To 
> display the policy content, policy is read from policy text column of 
> x_policy table, since json entry also contains duplicate entry user will get 
> duplicate entry of access permission as response.
> 
> This is not an issue if user uses create/update policy rest from Ranger UI as 
> restriction is placed from UI itself.
> 
> **Steps to reproduce:** 
> 1. Make the following request to create ranger policy in the "dev_hive" 
> service (if needed, please change the request data as per you env)
> 
> curl -ivk --header text/json -H 'Content-Type: text/json' -u admin:admin -X 
> POST http://localhost:6080/service/public/v2/api/policy -d 
> '{"service":"dev_hive","name":"URL policy: 
> /dev/db/table/resource","policyType":0,"policyPriority":0,"isAuditEnabled":true,"resources":{"url":{"values":["hdfs://localhost/dev/db/table/resource"],"isExcludes":false,"isRecursive":true}},"policyItems":[{"accesses":[{"type":"alter","isAllowed":true},{"type":"drop","isAllowed":true},{"type":"select","isAllowed":true},{"type":"create","isAllowed":true},{"type":"update","isAllowed":true},{"type":"lock","isAllowed":true},{"type":"all","isAllowed":true},{"type":"alter","isAllowed":true},{"type":"drop","isAllowed":true},{"type":"select","isAllowed":true},{"type":"create","isAllowed":true},{"type":"update","isAllowed":true},{"type":"lock","isAllowed":true},{"type":"all","isAllowed":true}],"users":[],"groups":["public"],"roles":[],"conditions":[],"delegateAdmin":true}],"denyPolicyItems":[],"allowExceptions":[],
 
"denyExceptions":[{"accesses":[{"type":"alter","isAllowed":true},{"type":"drop","isAllowed":true},{"type":"select","isAllowed":true},{"type":"create","isAllowed":true},{"type":"update","isAllowed":true},{"type":"lock","isAllowed":true},{"type":"all","isAllowed":true},{"type":"alter","isAllowed":true},{"type":"drop","isAllowed":true},{"type":"select","isAllowed":true},{"type":"create","isAllowed":true},{"type":"update","isAllowed":true},{"type":"lock","isAllowed":true},{"type":"all","isAllowed":true}],"users":[],"groups":["public"],"roles":[],"conditions":[],"delegateAdmin":true}],"dataMaskPolicyItems":[],"rowFilterPolicyItems":[],"serviceType":"hive","options":{},"validitySchedules":[],"policyLabels":[],"zoneName":"","isDenyAllElse":false}'
> 
> 
> 2. make a curl request to get the policy and compare the json. json content 
> will be having the duplicate entries of access permissions as provided in the 
> create policy request.
> 
> **Proposed solution:** 
> Option-1: Since policy validation is done before policy creation, hence 
> during validation phase we can filter out duplicate access permissions.
> Option-2: Add a validation to detect duplicate entries of access-permissions 
> and if there are any duplicate entries then fail the policy request.
> 
> I have provided the patch with option-1 mentioned above.
> 
> 
> Diffs
> -
> 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/model/validation/RangerPolicyValidator.java
>  fb6556b59 
> 
> 
> Diff: https://reviews.apache.org/r/73981/diff/2/
> 
> 
> Testing
> ---
> 
> With patch tested the create policy request with duplicate access-permissions 
> entries, policy was created successfully and get request is not having 
> duplicate access-permissions entries.
> With patch tested the update policy request with duplicate access-permissions 
> entries, policy was updated successfully and get request is not having 
> duplicate access-permissions entries.
> 
> 
> Thanks,
> 
> Pradeep Agrawal
> 
>

Re: Review Request 73981: RANGER-3752: Restrict duplicate access types entries in policy creation

[Pradeep Agrawal]

> On May 10, 2022, 3:59 p.m., Abhay Kulkarni wrote:
> > agents-common/src/main/java/org/apache/ranger/plugin/model/validation/RangerPolicyValidator.java
> > Lines 982 (patched)
> > 
> >
> > The following rewrite will avoid checking validity of a duplicate 
> > access-type repeatedly.
> > 
> > if (uniqueAccesses.contains(access.getType()) {
> > itrRangerPolicyAcccess.remove();
> > } else {
> > valid = isValidPolicyItemAccess(access, failures, accessTypes) && 
> > valid;
> > uniqueAccesses.add(access.getType());
> > }

Thanks for this one.


- Pradeep


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


On May 10, 2022, 7:31 p.m., Pradeep Agrawal wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/73981/
> ---
> 
> (Updated May 10, 2022, 7:31 p.m.)
> 
> 
> Review request for ranger, bhavik patel, Dhaval Shah, Abhay Kulkarni, Madhan 
> Neethiraj, Ramesh Mani, Sailaja Polavarapu, and Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-3752
> https://issues.apache.org/jira/browse/RANGER-3752
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> **Problem Statement:** While making a REST request to create Ranger policy, 
> it is possible that user can put same access type more than one. Since there 
> is no validation or restriction on duplicate entry of access type in the same 
> policy resource-policy items, policy get created successfully and policy text 
> json contains duplicate entries. 
> When user makes a GET request then duplicate entries are also shown. To 
> display the policy content, policy is read from policy text column of 
> x_policy table, since json entry also contains duplicate entry user will get 
> duplicate entry of access permission as response.
> 
> This is not an issue if user uses create/update policy rest from Ranger UI as 
> restriction is placed from UI itself.
> 
> **Steps to reproduce:** 
> 1. Make the following request to create ranger policy in the "dev_hive" 
> service (if needed, please change the request data as per you env)
> 
> curl -ivk --header text/json -H 'Content-Type: text/json' -u admin:admin -X 
> POST http://localhost:6080/service/public/v2/api/policy -d 
> '{"service":"dev_hive","name":"URL policy: 
> /dev/db/table/resource","policyType":0,"policyPriority":0,"isAuditEnabled":true,"resources":{"url":{"values":["hdfs://localhost/dev/db/table/resource"],"isExcludes":false,"isRecursive":true}},"policyItems":[{"accesses":[{"type":"alter","isAllowed":true},{"type":"drop","isAllowed":true},{"type":"select","isAllowed":true},{"type":"create","isAllowed":true},{"type":"update","isAllowed":true},{"type":"lock","isAllowed":true},{"type":"all","isAllowed":true},{"type":"alter","isAllowed":true},{"type":"drop","isAllowed":true},{"type":"select","isAllowed":true},{"type":"create","isAllowed":true},{"type":"update","isAllowed":true},{"type":"lock","isAllowed":true},{"type":"all","isAllowed":true}],"users":[],"groups":["public"],"roles":[],"conditions":[],"delegateAdmin":true}],"denyPolicyItems":[],"allowExceptions":[],
 
"denyExceptions":[{"accesses":[{"type":"alter","isAllowed":true},{"type":"drop","isAllowed":true},{"type":"select","isAllowed":true},{"type":"create","isAllowed":true},{"type":"update","isAllowed":true},{"type":"lock","isAllowed":true},{"type":"all","isAllowed":true},{"type":"alter","isAllowed":true},{"type":"drop","isAllowed":true},{"type":"select","isAllowed":true},{"type":"create","isAllowed":true},{"type":"update","isAllowed":true},{"type":"lock","isAllowed":true},{"type":"all","isAllowed":true}],"users":[],"groups":["public"],"roles":[],"conditions":[],"delegateAdmin":true}],"dataMaskPolicyItems":[],"rowFilterPolicyItems":[],"serviceType":"hive","options":{},"validitySchedules":[],"policyLabels":[],"zoneName":"","isDenyAllElse":false}'
> 
> 
> 2. make a curl request to get the policy and compare the json. json content 
> will be having the duplicate entries of access permissions as provided in the 
> create policy request.
> 
> **Proposed solution:** 
> Option-1: Since policy validation is done before policy creation, hence 
> during validation phase we can filter out duplicate access permissions.
> Option-2: Add a validation to detect duplicate entries of access-permissions 
> and if there are any duplicate entries then fail the policy request.
> 
> I have provided the patch with option-1 mentioned above.
> 
> 
> Diffs
> -
> 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/model/validation/RangerPolicyValidator.java
>  fb6556b59 
> 
> 
> Diff: 

Re: Review Request 73981: RANGER-3752: Restrict duplicate access types entries in policy creation

[Pradeep Agrawal]

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

(Updated May 10, 2022, 7:31 p.m.)


Review request for ranger, bhavik patel, Dhaval Shah, Abhay Kulkarni, Madhan 
Neethiraj, Ramesh Mani, Sailaja Polavarapu, and Velmurugan Periasamy.


Changes
---

Addressed review comments


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


Repository: ranger


Description
---

**Problem Statement:** While making a REST request to create Ranger policy, it 
is possible that user can put same access type more than one. Since there is no 
validation or restriction on duplicate entry of access type in the same policy 
resource-policy items, policy get created successfully and policy text json 
contains duplicate entries. 
When user makes a GET request then duplicate entries are also shown. To display 
the policy content, policy is read from policy text column of x_policy table, 
since json entry also contains duplicate entry user will get duplicate entry of 
access permission as response.

This is not an issue if user uses create/update policy rest from Ranger UI as 
restriction is placed from UI itself.

**Steps to reproduce:** 
1. Make the following request to create ranger policy in the "dev_hive" service 
(if needed, please change the request data as per you env)

curl -ivk --header text/json -H 'Content-Type: text/json' -u admin:admin -X 
POST http://localhost:6080/service/public/v2/api/policy -d 
'{"service":"dev_hive","name":"URL policy: 
/dev/db/table/resource","policyType":0,"policyPriority":0,"isAuditEnabled":true,"resources":{"url":{"values":["hdfs://localhost/dev/db/table/resource"],"isExcludes":false,"isRecursive":true}},"policyItems":[{"accesses":[{"type":"alter","isAllowed":true},{"type":"drop","isAllowed":true},{"type":"select","isAllowed":true},{"type":"create","isAllowed":true},{"type":"update","isAllowed":true},{"type":"lock","isAllowed":true},{"type":"all","isAllowed":true},{"type":"alter","isAllowed":true},{"type":"drop","isAllowed":true},{"type":"select","isAllowed":true},{"type":"create","isAllowed":true},{"type":"update","isAllowed":true},{"type":"lock","isAllowed":true},{"type":"all","isAllowed":true}],"users":[],"groups":["public"],"roles":[],"conditions":[],"delegateAdmin":true}],"denyPolicyItems":[],"allowExceptions":[],"d
 
enyExceptions":[{"accesses":[{"type":"alter","isAllowed":true},{"type":"drop","isAllowed":true},{"type":"select","isAllowed":true},{"type":"create","isAllowed":true},{"type":"update","isAllowed":true},{"type":"lock","isAllowed":true},{"type":"all","isAllowed":true},{"type":"alter","isAllowed":true},{"type":"drop","isAllowed":true},{"type":"select","isAllowed":true},{"type":"create","isAllowed":true},{"type":"update","isAllowed":true},{"type":"lock","isAllowed":true},{"type":"all","isAllowed":true}],"users":[],"groups":["public"],"roles":[],"conditions":[],"delegateAdmin":true}],"dataMaskPolicyItems":[],"rowFilterPolicyItems":[],"serviceType":"hive","options":{},"validitySchedules":[],"policyLabels":[],"zoneName":"","isDenyAllElse":false}'


2. make a curl request to get the policy and compare the json. json content 
will be having the duplicate entries of access permissions as provided in the 
create policy request.

**Proposed solution:** 
Option-1: Since policy validation is done before policy creation, hence during 
validation phase we can filter out duplicate access permissions.
Option-2: Add a validation to detect duplicate entries of access-permissions 
and if there are any duplicate entries then fail the policy request.

I have provided the patch with option-1 mentioned above.


Diffs (updated)
-

  
agents-common/src/main/java/org/apache/ranger/plugin/model/validation/RangerPolicyValidator.java
 fb6556b59 


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

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


Testing
---

With patch tested the create policy request with duplicate access-permissions 
entries, policy was created successfully and get request is not having 
duplicate access-permissions entries.
With patch tested the update policy request with duplicate access-permissions 
entries, policy was updated successfully and get request is not having 
duplicate access-permissions entries.


Thanks,

Pradeep Agrawal

[jira] [Commented] (RANGER-3753) Hive masking policies don't recognize {OWNER} user

[Ramesh Mani (Jira)]

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

Ramesh Mani commented on RANGER-3753:
-

[~madhan]  This patch is now in Apache Ranger 2.3 branch 
[https://github.com/apache/ranger/commit/9a2b9a0b8db215a8a149372ae9334dc09284a62d.]

Thanks.

> Hive masking policies don't recognize {OWNER} user
> --
>
> Key: RANGER-3753
> URL: https://issues.apache.org/jira/browse/RANGER-3753
> Project: Ranger
>  Issue Type: Bug
>  Components: plugins
>Reporter: Madhan Neethiraj
>Assignee: Madhan Neethiraj
>Priority: Major
> Fix For: 3.0.0, 2.3.0
>
> Attachments: RANGER-3753.patch
>
>
> Hive masking policies don't recognize \{OWNER} user. Consider the following 
> masking policy:
> {noformat}
> resource: database=db1, table=tbl1, column=col1
> policyItem-1: user={OWNER}, accessType=select, maskType=MASK_NONE
> policyItem-2: group=public, accessType=select, maskType=MASK_NULL{noformat}
>  
> Expected result:
> When column db1.tbl1.col1 is accessed by the owner of table, the column value 
> should be returned to the user without applying any masking. For all other 
> users, NULL value should be returned.
> Observed result:
> Value returned for all users is NULL, even for the owner of the table.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Updated] (RANGER-3182) Prestosql is renamed to Trino

[Ramesh Mani (Jira)]

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

Ramesh Mani updated RANGER-3182:

Fix Version/s: (was: 2.3.0)

> Prestosql is renamed to Trino
> -
>
> Key: RANGER-3182
> URL: https://issues.apache.org/jira/browse/RANGER-3182
> Project: Ranger
>  Issue Type: Improvement
>  Components: plugins
>Affects Versions: 2.1.0
>Reporter: Viacheslav Kriuchkov
>Assignee: Ramesh Mani
>Priority: Blocker
> Fix For: 3.0.0
>
> Attachments: 0001-RANGER-3182-Rename-Prestosql-to-Trino-master.patch, 
> 0001-RANGER-3182-Rename-Prestosql-to-Trino-ranger-2.3.patch, 
> ranger-commons-lang3-master.patch
>
>  Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> All "prestosql" classes are "trino" now and Presto plugin can't integrate 
> with Trino because of that. It means all Presto deployments that use Ranger 
> are stuck on version 350 and can't upgrade further.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Assigned] (RANGER-3182) Prestosql is renamed to Trino

[Ramesh Mani (Jira)]

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

Ramesh Mani reassigned RANGER-3182:
---

Assignee: Ramesh Mani

> Prestosql is renamed to Trino
> -
>
> Key: RANGER-3182
> URL: https://issues.apache.org/jira/browse/RANGER-3182
> Project: Ranger
>  Issue Type: Improvement
>  Components: plugins
>Affects Versions: 2.1.0
>Reporter: Viacheslav Kriuchkov
>Assignee: Ramesh Mani
>Priority: Blocker
> Fix For: 3.0.0, 2.3.0
>
> Attachments: 0001-RANGER-3182-Rename-Prestosql-to-Trino-master.patch, 
> 0001-RANGER-3182-Rename-Prestosql-to-Trino-ranger-2.3.patch, 
> ranger-commons-lang3-master.patch
>
>  Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> All "prestosql" classes are "trino" now and Presto plugin can't integrate 
> with Trino because of that. It means all Presto deployments that use Ranger 
> are stuck on version 350 and can't upgrade further.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

Review Request 73983: RANGER-3754: Chained plugins access evaluation result is not considered in some cases

[Abhay Kulkarni]

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

Review request for ranger, Madhan Neethiraj and Ramesh Mani.


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


Repository: ranger


Description
---

If the plugins are chained, the result of an access request combines the access 
result of the main plugin with the result reported by the plugin chained to the 
main plugin. In some cases (where fallback to native authorizer is not enabled 
for the main plugin), the result of the chained plugin's access result is not 
used if the chained plugin's policy that evaluated the access is of same or 
lower priority.


Diffs
-

  RANGER-3590.patch PRE-CREATION 
  
agents-common/src/main/java/org/apache/ranger/plugin/service/RangerBasePlugin.java
 f157475bf 


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


Testing
---

Compiled and ran all unit tests successfully


Thanks,

Abhay Kulkarni

[jira] [Created] (RANGER-3754) Chained plugins access evaluation result is not considered in some cases

[Abhay Kulkarni (Jira)]

Abhay Kulkarni created RANGER-3754:
--

 Summary: Chained plugins access evaluation result is not 
considered in some cases
 Key: RANGER-3754
 URL: https://issues.apache.org/jira/browse/RANGER-3754
 Project: Ranger
  Issue Type: Bug
  Components: Ranger
Reporter: Abhay Kulkarni
Assignee: Abhay Kulkarni


If the plugins are chained, the result of an access request combines the access 
result of the main plugin with the result reported by the plugin chained to the 
main plugin. In some cases (where fallback to native authorizer is not enabled 
for the main plugin), the result of the chained plugin's access result is not 
used if the chained plugin's policy that evaluated the access is of same or 
lower priority.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Commented] (RANGER-3753) Hive masking policies don't recognize {OWNER} user

[Ramesh Mani (Jira)]

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

Ramesh Mani commented on RANGER-3753:
-

[~madhan]  I shall review and have it in 2.3 release. Thanks

> Hive masking policies don't recognize {OWNER} user
> --
>
> Key: RANGER-3753
> URL: https://issues.apache.org/jira/browse/RANGER-3753
> Project: Ranger
>  Issue Type: Bug
>  Components: plugins
>Reporter: Madhan Neethiraj
>Assignee: Madhan Neethiraj
>Priority: Major
> Fix For: 3.0.0, 2.3.0
>
> Attachments: RANGER-3753.patch
>
>
> Hive masking policies don't recognize \{OWNER} user. Consider the following 
> masking policy:
> {noformat}
> resource: database=db1, table=tbl1, column=col1
> policyItem-1: user={OWNER}, accessType=select, maskType=MASK_NONE
> policyItem-2: group=public, accessType=select, maskType=MASK_NULL{noformat}
>  
> Expected result:
> When column db1.tbl1.col1 is accessed by the owner of table, the column value 
> should be returned to the user without applying any masking. For all other 
> users, NULL value should be returned.
> Observed result:
> Value returned for all users is NULL, even for the owner of the table.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Commented] (RANGER-3182) Prestosql is renamed to Trino

[Ramesh Mani (Jira)]

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

Ramesh Mani commented on RANGER-3182:
-

[~aakashnand]  Apache Ranger java version is still 1.8. 
[https://github.com/apache/ranger/blob/master/pom.xml#L71]

Changing this will result in testing the Apahce Ranger project as a whole. Lets 
revert this patch as this is blocking the release task.

1.81.8
1.8

> Prestosql is renamed to Trino
> -
>
> Key: RANGER-3182
> URL: https://issues.apache.org/jira/browse/RANGER-3182
> Project: Ranger
>  Issue Type: Improvement
>  Components: plugins
>Affects Versions: 2.1.0
>Reporter: Viacheslav Kriuchkov
>Priority: Blocker
> Fix For: 3.0.0, 2.3.0
>
> Attachments: 0001-RANGER-3182-Rename-Prestosql-to-Trino-master.patch, 
> 0001-RANGER-3182-Rename-Prestosql-to-Trino-ranger-2.3.patch, 
> ranger-commons-lang3-master.patch
>
>  Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> All "prestosql" classes are "trino" now and Presto plugin can't integrate 
> with Trino because of that. It means all Presto deployments that use Ranger 
> are stuck on version 350 and can't upgrade further.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Commented] (RANGER-3753) Hive masking policies don't recognize {OWNER} user

[Madhan Neethiraj (Jira)]

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

Madhan Neethiraj commented on RANGER-3753:
--

Fix committed in master branch:
{noformat}
commit 2c62d8b7824351a06861d1acafc853a62dd97e4c (HEAD -> master, origin/master, 
origin/HEAD)
Author: Madhan Neethiraj 
Date:   Tue May 10 00:49:01 2022 -0700    RANGER-3753: fix for masking and 
row-filter policies to recognize {OWNER} user {noformat}
 

[~rmani] - I suggest to include this fix in 2.3 release. Can you please review 
and approve? Thanks!

> Hive masking policies don't recognize {OWNER} user
> --
>
> Key: RANGER-3753
> URL: https://issues.apache.org/jira/browse/RANGER-3753
> Project: Ranger
>  Issue Type: Bug
>  Components: plugins
>Reporter: Madhan Neethiraj
>Assignee: Madhan Neethiraj
>Priority: Major
> Fix For: 3.0.0, 2.3.0
>
> Attachments: RANGER-3753.patch
>
>
> Hive masking policies don't recognize \{OWNER} user. Consider the following 
> masking policy:
> {noformat}
> resource: database=db1, table=tbl1, column=col1
> policyItem-1: user={OWNER}, accessType=select, maskType=MASK_NONE
> policyItem-2: group=public, accessType=select, maskType=MASK_NULL{noformat}
>  
> Expected result:
> When column db1.tbl1.col1 is accessed by the owner of table, the column value 
> should be returned to the user without applying any masking. For all other 
> users, NULL value should be returned.
> Observed result:
> Value returned for all users is NULL, even for the owner of the table.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

Re: Review Request 73981: RANGER-3752: Restrict duplicate access types entries in policy creation

[Abhay Kulkarni]

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




agents-common/src/main/java/org/apache/ranger/plugin/model/validation/RangerPolicyValidator.java
Line 966 (original), 966 (patched)


Please consider renaming newAccessTypes as uniqueAccesses. Also, it can be 
written as

Set uniqueAccesses = new HashSet<>();



agents-common/src/main/java/org/apache/ranger/plugin/model/validation/RangerPolicyValidator.java
Lines 967 (patched)


Consider naming itrRangerPoicyAccesses simply as accessTypeIterator.



agents-common/src/main/java/org/apache/ranger/plugin/model/validation/RangerPolicyValidator.java
Lines 982 (patched)


The following rewrite will avoid checking validity of a duplicate 
access-type repeatedly.

if (uniqueAccesses.contains(access.getType()) {
itrRangerPolicyAcccess.remove();
} else {
valid = isValidPolicyItemAccess(access, failures, accessTypes) && valid;
uniqueAccesses.add(access.getType());
}


- Abhay Kulkarni


On May 10, 2022, 7:43 a.m., Pradeep Agrawal wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/73981/
> ---
> 
> (Updated May 10, 2022, 7:43 a.m.)
> 
> 
> Review request for ranger, bhavik patel, Dhaval Shah, Abhay Kulkarni, Madhan 
> Neethiraj, Ramesh Mani, Sailaja Polavarapu, and Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-3752
> https://issues.apache.org/jira/browse/RANGER-3752
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> **Problem Statement:** While making a REST request to create Ranger policy, 
> it is possible that user can put same access type more than one. Since there 
> is no validation or restriction on duplicate entry of access type in the same 
> policy resource-policy items, policy get created successfully and policy text 
> json contains duplicate entries. 
> When user makes a GET request then duplicate entries are also shown. To 
> display the policy content, policy is read from policy text column of 
> x_policy table, since json entry also contains duplicate entry user will get 
> duplicate entry of access permission as response.
> 
> This is not an issue if user uses create/update policy rest from Ranger UI as 
> restriction is placed from UI itself.
> 
> **Steps to reproduce:** 
> 1. Make the following request to create ranger policy in the "dev_hive" 
> service (if needed, please change the request data as per you env)
> 
> curl -ivk --header text/json -H 'Content-Type: text/json' -u admin:admin -X 
> POST http://localhost:6080/service/public/v2/api/policy -d 
> '{"service":"dev_hive","name":"URL policy: 
> /dev/db/table/resource","policyType":0,"policyPriority":0,"isAuditEnabled":true,"resources":{"url":{"values":["hdfs://localhost/dev/db/table/resource"],"isExcludes":false,"isRecursive":true}},"policyItems":[{"accesses":[{"type":"alter","isAllowed":true},{"type":"drop","isAllowed":true},{"type":"select","isAllowed":true},{"type":"create","isAllowed":true},{"type":"update","isAllowed":true},{"type":"lock","isAllowed":true},{"type":"all","isAllowed":true},{"type":"alter","isAllowed":true},{"type":"drop","isAllowed":true},{"type":"select","isAllowed":true},{"type":"create","isAllowed":true},{"type":"update","isAllowed":true},{"type":"lock","isAllowed":true},{"type":"all","isAllowed":true}],"users":[],"groups":["public"],"roles":[],"conditions":[],"delegateAdmin":true}],"denyPolicyItems":[],"allowExceptions":[],
 
"denyExceptions":[{"accesses":[{"type":"alter","isAllowed":true},{"type":"drop","isAllowed":true},{"type":"select","isAllowed":true},{"type":"create","isAllowed":true},{"type":"update","isAllowed":true},{"type":"lock","isAllowed":true},{"type":"all","isAllowed":true},{"type":"alter","isAllowed":true},{"type":"drop","isAllowed":true},{"type":"select","isAllowed":true},{"type":"create","isAllowed":true},{"type":"update","isAllowed":true},{"type":"lock","isAllowed":true},{"type":"all","isAllowed":true}],"users":[],"groups":["public"],"roles":[],"conditions":[],"delegateAdmin":true}],"dataMaskPolicyItems":[],"rowFilterPolicyItems":[],"serviceType":"hive","options":{},"validitySchedules":[],"policyLabels":[],"zoneName":"","isDenyAllElse":false}'
> 
> 
> 2. make a curl request to get the policy and compare the json. json content 
> will be having the duplicate entries of access permissions as provided in the 
> create policy request.
> 
> **Proposed solution:** 
> Option-1: Since policy validation is done before policy creation, hence 
> during validation phase we can filter out 

Re: Review Request 73982: RANGER-3753: fixed masking and row-filter policies to recognize {OWNER} user

[Abhay Kulkarni]

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


Ship it!




Ship It!

- Abhay Kulkarni


On May 10, 2022, 7:56 a.m., Madhan Neethiraj wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/73982/
> ---
> 
> (Updated May 10, 2022, 7:56 a.m.)
> 
> 
> Review request for ranger, Ankita Sinha, Kishor Gollapalliwar, Abhay 
> Kulkarni, Mehul Parikh, Pradeep Agrawal, Ramesh Mani, Sailaja Polavarapu, and 
> Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-3753
> https://issues.apache.org/jira/browse/RANGER-3753
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> Fixed resource creation used to evaluate masking and row-filter policies to 
> populate ownerName
> 
> 
> Diffs
> -
> 
>   
> hive-agent/src/main/java/org/apache/ranger/authorization/hive/authorizer/RangerHiveAuthorizer.java
>  2fd257722 
> 
> 
> Diff: https://reviews.apache.org/r/73982/diff/1/
> 
> 
> Testing
> ---
> 
> Verified in Hive that masking and row-filter policies recognize {OWNER} user 
> in policies.
> 
> 
> Thanks,
> 
> Madhan Neethiraj
> 
>

[jira] [Commented] (RANGER-3182) Prestosql is renamed to Trino

[Ramesh Mani (Jira)]

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

Ramesh Mani commented on RANGER-3182:
-

[~aakashnand]  I see that it is failing in my build also.

I have an empty settings.xml file and failed with same error.

mvn --settings ~/.m2/empty-settings.xml clean compile install

> Prestosql is renamed to Trino
> -
>
> Key: RANGER-3182
> URL: https://issues.apache.org/jira/browse/RANGER-3182
> Project: Ranger
>  Issue Type: Improvement
>  Components: plugins
>Affects Versions: 2.1.0
>Reporter: Viacheslav Kriuchkov
>Priority: Blocker
> Fix For: 3.0.0, 2.3.0
>
> Attachments: 0001-RANGER-3182-Rename-Prestosql-to-Trino-master.patch, 
> 0001-RANGER-3182-Rename-Prestosql-to-Trino-ranger-2.3.patch, 
> ranger-commons-lang3-master.patch
>
>  Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> All "prestosql" classes are "trino" now and Presto plugin can't integrate 
> with Trino because of that. It means all Presto deployments that use Ranger 
> are stuck on version 350 and can't upgrade further.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Commented] (RANGER-3182) Prestosql is renamed to Trino

[Aakash Nand (Jira)]

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

Aakash Nand commented on RANGER-3182:
-

[~madhan] [~rmani] 

Trino plugin requires JDK11+ and I thought from Ranger 2, java11 support is 
added. How should we proceed with this?

> Prestosql is renamed to Trino
> -
>
> Key: RANGER-3182
> URL: https://issues.apache.org/jira/browse/RANGER-3182
> Project: Ranger
>  Issue Type: Improvement
>  Components: plugins
>Affects Versions: 2.1.0
>Reporter: Viacheslav Kriuchkov
>Priority: Blocker
> Fix For: 3.0.0, 2.3.0
>
> Attachments: 0001-RANGER-3182-Rename-Prestosql-to-Trino-master.patch, 
> 0001-RANGER-3182-Rename-Prestosql-to-Trino-ranger-2.3.patch, 
> ranger-commons-lang3-master.patch
>
>  Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> All "prestosql" classes are "trino" now and Presto plugin can't integrate 
> with Trino because of that. It means all Presto deployments that use Ranger 
> are stuck on version 350 and can't upgrade further.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Commented] (RANGER-3182) Prestosql is renamed to Trino

[Madhan Neethiraj (Jira)]

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

Madhan Neethiraj commented on RANGER-3182:
--

[~aakashnand]  - here is my build env details. I see that you are using JDK 11, 
while I use JDK 8. Please note that Ranger continue to support JDK 8.
{noformat}
$ mvn --version
Apache Maven 3.8.1 (05c21c65bdfed0f71a2f2ada8b84da59348c4c5d)
Maven home: /opt/apache/maven
Java version: 1.8.0_282-internal, vendor: OpenLogic-OpenJDK, runtime: 
/Library/Java/JavaVirtualMachines/openlogic-openjdk-8.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac" {noformat}

> Prestosql is renamed to Trino
> -
>
> Key: RANGER-3182
> URL: https://issues.apache.org/jira/browse/RANGER-3182
> Project: Ranger
>  Issue Type: Improvement
>  Components: plugins
>Affects Versions: 2.1.0
>Reporter: Viacheslav Kriuchkov
>Priority: Blocker
> Fix For: 3.0.0, 2.3.0
>
> Attachments: 0001-RANGER-3182-Rename-Prestosql-to-Trino-master.patch, 
> 0001-RANGER-3182-Rename-Prestosql-to-Trino-ranger-2.3.patch, 
> ranger-commons-lang3-master.patch
>
>  Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> All "prestosql" classes are "trino" now and Presto plugin can't integrate 
> with Trino because of that. It means all Presto deployments that use Ranger 
> are stuck on version 350 and can't upgrade further.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Commented] (RANGER-3182) Prestosql is renamed to Trino

[Pradeep Agrawal (Jira)]

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

Pradeep Agrawal commented on RANGER-3182:
-

Build is failing for me too with the below command
{code:java}
mvn clean install {code}

> Prestosql is renamed to Trino
> -
>
> Key: RANGER-3182
> URL: https://issues.apache.org/jira/browse/RANGER-3182
> Project: Ranger
>  Issue Type: Improvement
>  Components: plugins
>Affects Versions: 2.1.0
>Reporter: Viacheslav Kriuchkov
>Priority: Blocker
> Fix For: 3.0.0, 2.3.0
>
> Attachments: 0001-RANGER-3182-Rename-Prestosql-to-Trino-master.patch, 
> 0001-RANGER-3182-Rename-Prestosql-to-Trino-ranger-2.3.patch, 
> ranger-commons-lang3-master.patch
>
>  Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> All "prestosql" classes are "trino" now and Presto plugin can't integrate 
> with Trino because of that. It means all Presto deployments that use Ranger 
> are stuck on version 350 and can't upgrade further.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Commented] (RANGER-3165) Upgrade Elasticsearch version in Ranger to Elasticsearch 7.17.2

[YangCheng (Jira)]

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

YangCheng commented on RANGER-3165:
---

[~rmani] [~kirbyzhou] [~bpatel]  

Since opensearch has its own security 
management（https://opensearch.org/docs/latest/security-plugin/index/）, it is 
better to upgrade the ES plug-in to 7.10.2.

 

> Upgrade Elasticsearch version in Ranger to Elasticsearch 7.17.2
> ---
>
> Key: RANGER-3165
> URL: https://issues.apache.org/jira/browse/RANGER-3165
> Project: Ranger
>  Issue Type: Improvement
>  Components: Ranger
>Affects Versions: 3.0.0
>Reporter: YangCheng
>Assignee: Bhavik Patel
>Priority: Major
> Attachments: 
> 0001-RANGER-3165-Upgrade-Elasticsearch-version-in-Ranger-.patch
>
>
> Current ES version 7.6.0 affected with many CVE's issue, so it's better to 
> update the version to 7.17.2
>  
>  
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Commented] (RANGER-3182) Prestosql is renamed to Trino

[Aakash Nand (Jira)]

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

Aakash Nand commented on RANGER-3182:
-

[~madhan] I tried building again in a different environment and it is working 
for me. I am not sure why you are getting that error. Please check the below 
environment information I used, 


{code:java}
Apache Maven 3.8.1 (05c21c65bdfed0f71a2f2ada8b84da59348c4c5d)
Maven home: /home/aakashnand/opt/apache-maven-3.8.1
Java version: 11.0.13, vendor: Oracle Corporation, runtime: 
/home/aakashnand/opt/openjdk-11.0.13_8
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.4.0-100-generic", arch: "amd64", family: "unix"
{code}
 

Command used


{code:java}
mvn clean compile package install -P ranger-trino-plugin,'!linux' -am{code}
 
{code:java}
[INFO] ranger . SUCCESS [ 13.884 s]
[INFO] Credential Support . SUCCESS [ 15.712 s]
[INFO] Audit Component  SUCCESS [ 20.878 s]
[INFO] ranger-plugin-classloader .. SUCCESS [  7.247 s]
[INFO] Common library for Plugins . SUCCESS [ 57.027 s]
[INFO] Installer Support Component  SUCCESS [  5.306 s]
[INFO] Credential Builder . SUCCESS [ 12.259 s]
[INFO] Ranger Util  SUCCESS [ 13.222 s]
[INFO] Trino Security Plugin .. SUCCESS [ 18.628 s]
[INFO] Trino Security Plugin Shim . SUCCESS [ 10.845 s]
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time:  02:55 min
[INFO] Finished at: 2022-05-10T07:58:54Z
[INFO]  
{code}

> Prestosql is renamed to Trino
> -
>
> Key: RANGER-3182
> URL: https://issues.apache.org/jira/browse/RANGER-3182
> Project: Ranger
>  Issue Type: Improvement
>  Components: plugins
>Affects Versions: 2.1.0
>Reporter: Viacheslav Kriuchkov
>Priority: Blocker
> Fix For: 3.0.0, 2.3.0
>
> Attachments: 0001-RANGER-3182-Rename-Prestosql-to-Trino-master.patch, 
> 0001-RANGER-3182-Rename-Prestosql-to-Trino-ranger-2.3.patch, 
> ranger-commons-lang3-master.patch
>
>  Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> All "prestosql" classes are "trino" now and Presto plugin can't integrate 
> with Trino because of that. It means all Presto deployments that use Ranger 
> are stuck on version 350 and can't upgrade further.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Updated] (RANGER-3753) Hive masking policies don't recognize {OWNER} user

[Madhan Neethiraj (Jira)]

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

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

> Hive masking policies don't recognize {OWNER} user
> --
>
> Key: RANGER-3753
> URL: https://issues.apache.org/jira/browse/RANGER-3753
> Project: Ranger
>  Issue Type: Bug
>  Components: plugins
>Reporter: Madhan Neethiraj
>Assignee: Madhan Neethiraj
>Priority: Major
> Attachments: RANGER-3753.patch
>
>
> Hive masking policies don't recognize \{OWNER} user. Consider the following 
> masking policy:
> {noformat}
> resource: database=db1, table=tbl1, column=col1
> policyItem-1: user={OWNER}, accessType=select, maskType=MASK_NONE
> policyItem-2: group=public, accessType=select, maskType=MASK_NULL{noformat}
>  
> Expected result:
> When column db1.tbl1.col1 is accessed by the owner of table, the column value 
> should be returned to the user without applying any masking. For all other 
> users, NULL value should be returned.
> Observed result:
> Value returned for all users is NULL, even for the owner of the table.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

Review Request 73982: RANGER-3753: fixed masking and row-filter policies to recognize {OWNER} user

[Madhan Neethiraj]

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

Review request for ranger, Ankita Sinha, Kishor Gollapalliwar, Abhay Kulkarni, 
Mehul Parikh, Pradeep Agrawal, Ramesh Mani, Sailaja Polavarapu, and Velmurugan 
Periasamy.


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


Repository: ranger


Description
---

Fixed resource creation used to evaluate masking and row-filter policies to 
populate ownerName


Diffs
-

  
hive-agent/src/main/java/org/apache/ranger/authorization/hive/authorizer/RangerHiveAuthorizer.java
 2fd257722 


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


Testing
---

Verified in Hive that masking and row-filter policies recognize {OWNER} user in 
policies.


Thanks,

Madhan Neethiraj

[jira] [Created] (RANGER-3753) Hive masking policies don't recognize {OWNER} user

[Madhan Neethiraj (Jira)]

Madhan Neethiraj created RANGER-3753:


 Summary: Hive masking policies don't recognize {OWNER} user
 Key: RANGER-3753
 URL: https://issues.apache.org/jira/browse/RANGER-3753
 Project: Ranger
  Issue Type: Bug
  Components: plugins
Reporter: Madhan Neethiraj
Assignee: Madhan Neethiraj


Hive masking policies don't recognize \{OWNER} user. Consider the following 
masking policy:
{noformat}
resource: database=db1, table=tbl1, column=col1
policyItem-1: user={OWNER}, accessType=select, maskType=MASK_NONE
policyItem-2: group=public, accessType=select, maskType=MASK_NULL{noformat}
 

Expected result:

When column db1.tbl1.col1 is accessed by the owner of table, the column value 
should be returned to the user without applying any masking. For all other 
users, NULL value should be returned.

Observed result:

Value returned for all users is NULL, even for the owner of the table.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

Review Request 73981: RANGER-3752: Restrict duplicate access types entries in policy creation

[Pradeep Agrawal]

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

Review request for ranger, bhavik patel, Dhaval Shah, Abhay Kulkarni, Madhan 
Neethiraj, Ramesh Mani, Sailaja Polavarapu, and Velmurugan Periasamy.


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


Repository: ranger


Description
---

**Problem Statement:** While making a REST request to create Ranger policy, it 
is possible that user can put same access type more than one. Since there is no 
validation or restriction on duplicate entry of access type in the same policy 
resource-policy items, policy get created successfully and policy text json 
contains duplicate entries. 
When user makes a GET request then duplicate entries are also shown. To display 
the policy content, policy is read from policy text column of x_policy table, 
since json entry also contains duplicate entry user will get duplicate entry of 
access permission as response.

This is not an issue if user uses create/update policy rest from Ranger UI as 
restriction is placed from UI itself.

**Steps to reproduce:** 
1. Make the following request to create ranger policy in the "dev_hive" service 
(if needed, please change the request data as per you env)

curl -ivk --header text/json -H 'Content-Type: text/json' -u admin:admin -X 
POST http://localhost:6080/service/public/v2/api/policy -d 
'{"service":"dev_hive","name":"URL policy: 
/dev/db/table/resource","policyType":0,"policyPriority":0,"isAuditEnabled":true,"resources":{"url":{"values":["hdfs://localhost/dev/db/table/resource"],"isExcludes":false,"isRecursive":true}},"policyItems":[{"accesses":[{"type":"alter","isAllowed":true},{"type":"drop","isAllowed":true},{"type":"select","isAllowed":true},{"type":"create","isAllowed":true},{"type":"update","isAllowed":true},{"type":"lock","isAllowed":true},{"type":"all","isAllowed":true},{"type":"alter","isAllowed":true},{"type":"drop","isAllowed":true},{"type":"select","isAllowed":true},{"type":"create","isAllowed":true},{"type":"update","isAllowed":true},{"type":"lock","isAllowed":true},{"type":"all","isAllowed":true}],"users":[],"groups":["public"],"roles":[],"conditions":[],"delegateAdmin":true}],"denyPolicyItems":[],"allowExceptions":[],"d
 
enyExceptions":[{"accesses":[{"type":"alter","isAllowed":true},{"type":"drop","isAllowed":true},{"type":"select","isAllowed":true},{"type":"create","isAllowed":true},{"type":"update","isAllowed":true},{"type":"lock","isAllowed":true},{"type":"all","isAllowed":true},{"type":"alter","isAllowed":true},{"type":"drop","isAllowed":true},{"type":"select","isAllowed":true},{"type":"create","isAllowed":true},{"type":"update","isAllowed":true},{"type":"lock","isAllowed":true},{"type":"all","isAllowed":true}],"users":[],"groups":["public"],"roles":[],"conditions":[],"delegateAdmin":true}],"dataMaskPolicyItems":[],"rowFilterPolicyItems":[],"serviceType":"hive","options":{},"validitySchedules":[],"policyLabels":[],"zoneName":"","isDenyAllElse":false}'


2. make a curl request to get the policy and compare the json. json content 
will be having the duplicate entries of access permissions as provided in the 
create policy request.

**Proposed solution:** 
Option-1: Since policy validation is done before policy creation, hence during 
validation phase we can filter out duplicate access permissions.
Option-2: Add a validation to detect duplicate entries of access-permissions 
and if there are any duplicate entries then fail the policy request.

I have provided the patch with option-1 mentioned above.


Diffs
-

  
agents-common/src/main/java/org/apache/ranger/plugin/model/validation/RangerPolicyValidator.java
 fb6556b59 


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


Testing
---

With patch tested the create policy request with duplicate access-permissions 
entries, policy was created successfully and get request is not having 
duplicate access-permissions entries.
With patch tested the update policy request with duplicate access-permissions 
entries, policy was updated successfully and get request is not having 
duplicate access-permissions entries.


Thanks,

Pradeep Agrawal

[jira] [Updated] (RANGER-3752) Restrict duplicate access types entries in policy creation

[Pradeep Agrawal (Jira)]

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

Pradeep Agrawal updated RANGER-3752:

Attachment: 0001-RANGER-3752-Restrict-duplicate-access-types-entries-.patch

> Restrict duplicate access types entries in policy creation
> --
>
> Key: RANGER-3752
> URL: https://issues.apache.org/jira/browse/RANGER-3752
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Reporter: Pradeep Agrawal
>Assignee: Pradeep Agrawal
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: 
> 0001-RANGER-3752-Restrict-duplicate-access-types-entries-.patch
>
>




--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Created] (RANGER-3752) Restrict duplicate access types entries in policy creation

[Pradeep Agrawal (Jira)]

Pradeep Agrawal created RANGER-3752:
---

 Summary: Restrict duplicate access types entries in policy creation
 Key: RANGER-3752
 URL: https://issues.apache.org/jira/browse/RANGER-3752
 Project: Ranger
  Issue Type: Bug
  Components: Ranger
Reporter: Pradeep Agrawal
Assignee: Pradeep Agrawal
 Fix For: 3.0.0






--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Assigned] (RANGER-3139) Create service SQLException: Lock wait timeout exceeded; try restarting transaction Error Code: 1205

[Pradeep Agrawal (Jira)]

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

Pradeep Agrawal reassigned RANGER-3139:
---

Assignee: Pradeep Agrawal

> Create service SQLException: Lock wait timeout exceeded; try restarting 
> transaction Error Code: 1205
> 
>
> Key: RANGER-3139
> URL: https://issues.apache.org/jira/browse/RANGER-3139
> Project: Ranger
>  Issue Type: Bug
>  Components: admin
>Affects Versions: 2.0.0
>Reporter: panwu
>Assignee: Pradeep Agrawal
>Priority: Major
>
> I use Mysql as a backend DB. When creating a new service, it always throws an 
> exception
> {code:java}
> 2021-01-03 08:24:12,317 [http-bio-6080-exec-10] ERROR 
> org.apache.ranger.rest.ServiceREST (ServiceREST.java:717) - 
> createService(RangerService={id={null} guid={null} isEnabled={true} 
> createdBy={null} updatedBy={null} createTime={null} updateTime={null} 
> version={1} name={hadoop} type={hdfs} description={} tagService={} 
> configs={commonNameForCertificate={} 
> dfs.secondary.namenode.kerberos.principal={sn/_h...@bdp.com} 
> hadoop.security.authentication={kerberos} 
> hadoop.security.auth_to_local={RULE:[2:$1/$2@$0]([nds]n/.*@BDP\.COM)s/.*/hdfs/
>  RULE:[2:$1/$2@$0]([rn]m/.*@BDP\.COM)s/.*/yarn/ 
> RULE:[2:$1/$2@$0](jhs/.*@BDP\.COM)s/.*/mapred/} 
> dfs.datanode.kerberos.principal={dn/_h...@bdp.com} 
> tag.download.auth.users={hdfs} password={123456} 
> policy.download.auth.users={hdfs} 
> dfs.namenode.kerberos.principal={nn/_h...@bdp.com} 
> hadoop.rpc.protection={authentication} 
> fs.default.name={hdfs://bigdata-server-05:9820} 
> hadoop.security.authorization={true} username={hdfs} } policyVersion={null} 
> policyUpdateTime={null} tagVersion={1} tagUpdateTime={null} }) 
> failed2021-01-03 08:24:12,317 [http-bio-6080-exec-10] ERROR 
> org.apache.ranger.rest.ServiceREST (ServiceREST.java:717) - 
> createService(RangerService={id={null} guid={null} isEnabled={true} 
> createdBy={null} updatedBy={null} createTime={null} updateTime={null} 
> version={1} name={hadoop} type={hdfs} description={} tagService={} 
> configs={commonNameForCertificate={} 
> dfs.secondary.namenode.kerberos.principal={sn/_h...@bdp.com} 
> hadoop.security.authentication={kerberos} 
> hadoop.security.auth_to_local={RULE:[2:$1/$2@$0]([nds]n/.*@BDP\.COM)s/.*/hdfs/
>  RULE:[2:$1/$2@$0]([rn]m/.*@BDP\.COM)s/.*/yarn/ 
> RULE:[2:$1/$2@$0](jhs/.*@BDP\.COM)s/.*/mapred/} 
> dfs.datanode.kerberos.principal={dn/_h...@bdp.com} 
> tag.download.auth.users={hdfs} password={123456} 
> policy.download.auth.users={hdfs} 
> dfs.namenode.kerberos.principal={nn/_h...@bdp.com} 
> hadoop.rpc.protection={authentication} 
> fs.default.name={hdfs://bigdata-server-05:9820} 
> hadoop.security.authorization={true} username={hdfs} } policyVersion={null} 
> policyUpdateTime={null} tagVersion={1} tagUpdateTime={null} }) 
> failedjavax.persistence.PersistenceException: Exception [EclipseLink-4002] 
> (Eclipse Persistence Services - 2.5.2.v20140319-9ad6abd): 
> org.eclipse.persistence.exceptions.DatabaseExceptionInternal Exception: 
> java.sql.SQLException: Lock wait timeout exceeded; try restarting 
> transactionError Code: 1205Call: INSERT INTO x_service (ADDED_BY_ID, 
> CREATE_TIME, description, guid, is_enabled, name, policy_update_time, 
> policy_version, tag_service, tag_update_time, tag_version, type, UPDATE_TIME, 
> UPD_BY_ID, version) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) bind 
> => [15 parameters bound]Query: InsertObjectQuery(XXService [id=null]) at 
> org.eclipse.persistence.internal.jpa.EntityManagerImpl.flush(EntityManagerImpl.java:868)
>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  at java.lang.reflect.Method.invoke(Method.java:498) at 
> org.springframework.orm.jpa.SharedEntityManagerCreator$SharedEntityManagerInvocationHandler.invoke(SharedEntityManagerCreator.java:301)
>  at com.sun.proxy.$Proxy27.flush(Unknown Source) at 
> org.apache.ranger.common.db.BaseDao.create(BaseDao.java:89) at 
> org.apache.ranger.service.RangerBaseModelService.create(RangerBaseModelService.java:225)
>  at 
> org.apache.ranger.biz.ServiceDBStore.createService(ServiceDBStore.java:1430) 
> at org.apache.ranger.rest.ServiceREST.createService(ServiceREST.java:713) at 
> org.apache.ranger.rest.ServiceREST$$FastClassBySpringCGLIB$$92dab672.invoke()
>  at org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:204) 
> at 
> org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:736)
>  at 
> 

[jira] [Assigned] (RANGER-3393) Stop using deprecated mysql driver class

[Pradeep Agrawal (Jira)]

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

Pradeep Agrawal reassigned RANGER-3393:
---

Assignee: Pradeep Agrawal

> Stop using deprecated mysql driver class
> 
>
> Key: RANGER-3393
> URL: https://issues.apache.org/jira/browse/RANGER-3393
> Project: Ranger
>  Issue Type: Bug
>  Components: build-infra
>Reporter: Tsung-Ju Lii
>Assignee: Pradeep Agrawal
>Priority: Major
>




--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Assigned] (RANGER-3680) mysql ErrorCode:1118 when Importing DB schema to database

[Pradeep Agrawal (Jira)]

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

Pradeep Agrawal reassigned RANGER-3680:
---

Assignee: Pradeep Agrawal

> mysql ErrorCode:1118 when Importing DB schema to database
> -
>
> Key: RANGER-3680
> URL: https://issues.apache.org/jira/browse/RANGER-3680
> Project: Ranger
>  Issue Type: Bug
>  Components: admin
>Affects Versions: 2.2.0
> Environment: os: centos 7
> mysql: 5.7.30
> jdk: 1.8.0_251
>Reporter: vesence
>Assignee: Pradeep Agrawal
>Priority: Major
>
> ranger_core_db_mysql.sql file import failed when initializing admin database, 
> here is the specific imformation below:
> [I] Importing DB schema to database bdp_ranger from file: 
> ranger_core_db_mysql.sql
> Error executing: 
> CREATE TABLE `x_portal_user` (   `id` bigint(20) NOT NULL AUTO_INCREMENT,   
> `create_time` datetime DEFAULT NULL,   
> `update_time` datetime DEFAULT NULL,   
> `added_by_id` bigint(20) DEFAULT NULL,   
> `upd_by_id` bigint(20) DEFAULT NULL,   
> `first_name` varchar(1022) DEFAULT NULL,   
> `last_name` varchar(1022) DEFAULT NULL,   
> `pub_scr_name` varchar(2048) DEFAULT NULL,   
> `login_id` varchar(767) DEFAULT NULL,   
> `password` varchar(512) NOT NULL,   
> `email` varchar(512) DEFAULT NULL,   
> `status` int(11) NOT NULL DEFAULT '0',   
> `user_src` int(11) NOT NULL DEFAULT '0',   
> `notes` varchar(4000) DEFAULT NULL,   
> `other_attributes` varchar(4000) DEFAULT NULL,   
> `sync_source` varchar(4000) DEFAULT NULL,   
> PRIMARY KEY (`id`),   
> UNIQUE KEY `x_portal_user_UK_login_id` (`login_id`),   
> UNIQUE KEY `x_portal_user_UK_email` (`email`),   
> KEY `x_portal_user_FK_added_by_id` (`added_by_id`),   
> KEY `x_portal_user_FK_upd_by_id` (`upd_by_id`),   
> KEY `x_portal_user_cr_time` (`create_time`),   
> KEY `x_portal_user_up_time` (`update_time`),   
> KEY `x_portal_user_name` (`first_name`(767)),   
> KEY `x_portal_user_email` (`email`),   
> CONSTRAINT `x_portal_user_FK_added_by_id` FOREIGN KEY (`added_by_id`) 
> REFERENCES `x_portal_user` (`id`),   
> CONSTRAINT `x_portal_user_FK_upd_by_id` FOREIGN KEY (`upd_by_id`) REFERENCES 
> `x_portal_user` (`id`) ) ROW_FORMAT=DYNAMIC; 
> com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: 
> Row size too large. The maximum row size for the used table type, not 
> counting BLOBs, is 65535. 
> This includes storage overhead, check the manual. You have to change some 
> columns to TEXT or BLOBs
> SQLException : SQL state: 42000 
> com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Row size too 
> large. The maximum row size for the used table type, not counting BLOBs, is 
> 65535. This includes storage overhead, check the manual. You have to change 
> some columns to TEXT or BLOBs ErrorCode: 1118
>  
> [E] ranger_core_db_mysql.sql file import failed!
>  



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Assigned] (RANGER-3394) Too much `varchar(4000)` causes table to exceed ROW SIZE limit in MySQL

[Pradeep Agrawal (Jira)]

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

Pradeep Agrawal reassigned RANGER-3394:
---

Assignee: Pradeep Agrawal

> Too much `varchar(4000)` causes table to exceed ROW SIZE limit in MySQL
> ---
>
> Key: RANGER-3394
> URL: https://issues.apache.org/jira/browse/RANGER-3394
> Project: Ranger
>  Issue Type: Bug
>  Components: build-infra
>Reporter: Tsung-Ju Lii
>Assignee: Pradeep Agrawal
>Priority: Major
>
> The patch is just substituting all occurrences of `varchar(4000)` with 
> `TEXT`. Probably not the best way to do this but it works for me.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Commented] (RANGER-3733) owasp-java-html-sanitizer impacted with CVE-2021-42575

[Bhavik Patel (Jira)]

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

Bhavik Patel commented on RANGER-3733:
--

master branch commit link: 
https://github.com/apache/ranger/commit/75e113cf7aa4f69cbc3ae3173ba96e0f5f9cdf1b

> owasp-java-html-sanitizer impacted with CVE-2021-42575 
> ---
>
> Key: RANGER-3733
> URL: https://issues.apache.org/jira/browse/RANGER-3733
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Affects Versions: 3.0.0
>Reporter: Bhavik Patel
>Assignee: Bhavik Patel
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: 0001-RANGER-3733-Upgrade-owasp-java-html-sanitizer.patch
>
>
> owasp-java-html-sanitizer impacted with CVE-2021-42575 



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Updated] (RANGER-3733) owasp-java-html-sanitizer impacted with CVE-2021-42575

[Bhavik Patel (Jira)]

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

Bhavik Patel updated RANGER-3733:
-
Fix Version/s: 3.0.0

> owasp-java-html-sanitizer impacted with CVE-2021-42575 
> ---
>
> Key: RANGER-3733
> URL: https://issues.apache.org/jira/browse/RANGER-3733
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Affects Versions: 3.0.0
>Reporter: Bhavik Patel
>Assignee: Bhavik Patel
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: 0001-RANGER-3733-Upgrade-owasp-java-html-sanitizer.patch
>
>
> owasp-java-html-sanitizer impacted with CVE-2021-42575 



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Assigned] (RANGER-3733) owasp-java-html-sanitizer impacted with CVE-2021-42575

[Bhavik Patel (Jira)]

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

Bhavik Patel reassigned RANGER-3733:


Assignee: Bhavik Patel

> owasp-java-html-sanitizer impacted with CVE-2021-42575 
> ---
>
> Key: RANGER-3733
> URL: https://issues.apache.org/jira/browse/RANGER-3733
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Affects Versions: 3.0.0
>Reporter: Bhavik Patel
>Assignee: Bhavik Patel
>Priority: Major
> Attachments: 0001-RANGER-3733-Upgrade-owasp-java-html-sanitizer.patch
>
>
> owasp-java-html-sanitizer impacted with CVE-2021-42575 



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

Re: Review Request 73980: RANGER-3730 use reload4j to replace log4j-1.2

[bhavik patel]

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




pom.xml
Line 167 (original), 167 (patched)


To avoid the confusion, update the attribute name to reload4j


- bhavik patel


On May 10, 2022, 2:17 a.m., Kirby Zhou wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/73980/
> ---
> 
> (Updated May 10, 2022, 2:17 a.m.)
> 
> 
> Review request for ranger, Dhaval Shah, Dineshkumar Yadav, Kishor 
> Gollapalliwar, Abhay Kulkarni, Madhan Neethiraj, Mateen Mansoori, Mehul 
> Parikh, Pradeep Agrawal, Ramesh Mani, and Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-3730
> https://issues.apache.org/jira/browse/RANGER-3730
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> use ch.qos.reload4j:reload4j to replace old log4j-1.2 for unit test in 
> knox-agent.
> 
> 
> Diffs
> -
> 
>   knox-agent/pom.xml 9cd84e07c4fdfc5729d76c051f89b8bc6dab3a47 
>   pom.xml 7eac176c79799983101e3c2676568fc11e1d0799 
> 
> 
> Diff: https://reviews.apache.org/r/73980/diff/1/
> 
> 
> Testing
> ---
> 
> Done
> 
> 
> Thanks,
> 
> Kirby Zhou
> 
>

Re: Review Request 73841: RANGER-3612: Ranger plugin should cause kms to fail at startup when auth to krb5 failed.

[bhavik patel]

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


Ship it!




Ship It!

- bhavik patel


On March 2, 2022, 3:51 a.m., Kirby Zhou wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/73841/
> ---
> 
> (Updated March 2, 2022, 3:51 a.m.)
> 
> 
> Review request for ranger, Bhavik Bavishi, Dhaval Shah, Dineshkumar Yadav, 
> Gautam Borad, Jayendra Parab, Kishor Gollapalliwar, Abhay Kulkarni, Mateen 
> Mansoori, Madhan Neethiraj, Mehul Parikh, Pradeep Agrawal, VaradreawiZTV 
> VaradreawiZTV, Vishal Suvagia, and Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-3612
> https://issues.apache.org/jira/browse/RANGER-3612
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> If we install ranger agent to KMS, the agent would auth itself to KDC at 
> startup. But if it failed due to network or keytab problem, it just print a 
> log in ranger-kms-.log, and the KMS can never recover to refresh 
> its policies.
> 
> ]$ tail -f log/ranger-kms-ranger_kms-.log  | fgrep ERROR 
> 2022-02-09 19:00:18,227 ERROR MiscUtil - Failed to login with given keytab 
> and principal
> 
> There seems only one chance for plugin to auth to KDC, so it can not auto 
> recover.
> And MiscUtil.authWithKerberos never fail when auth failed, so KMS would not 
> die when the plugin failed.
> 
> This situation is too unfriendly to administrators. 
> KMS should either Die or Auto-Recover when its ranger-agent auth to KDC 
> failed.
> 
> My patch here is let it die on startup. Auto recovery is only useful when KDC 
> temporarily unavailable.
> 
> 
> Diffs
> -
> 
>   agents-audit/src/main/java/org/apache/ranger/audit/provider/MiscUtil.java 
> b69e27693 
>   
> plugin-kms/src/main/java/org/apache/ranger/authorization/kms/authorizer/RangerKmsAuthorizer.java
>  799eb322c 
>   
> ranger-kms-plugin-shim/src/main/java/org/apache/ranger/authorization/kms/authorizer/RangerKmsAuthorizer.java
>  7fa36ce79 
> 
> 
> Diff: https://reviews.apache.org/r/73841/diff/1/
> 
> 
> Testing
> ---
> 
> mvn clean compile package test
> 
> 
> Thanks,
> 
> Kirby Zhou
> 
>