[jira] [Created] (RANGER-4778) dnpattern only takes one value

2024-04-19 Thread Jira
Loïc C. Chanel created RANGER-4778:
--

 Summary: dnpattern only takes one value
 Key: RANGER-4778
 URL: https://issues.apache.org/jira/browse/RANGER-4778
 Project: Ranger
  Issue Type: Bug
  Components: admin
Affects Versions: 2.3.0
Reporter: Loïc C. Chanel


Hi team,

As discussed on the mailing list, when using an array of values in 
{{ranger.ldap.user.dnpattern}} property we get the following error :

{{LDAP Authentication Failed:}}
{{org.springframework.security.authentication.InternalAuthenticationServiceException:
 Failed to parse DN; nested exception is 
org.springframework.ldap.core.TokenMgrError: Lexical error at line 1, column 
10.  Encountered: "(" (40), after : ""}}



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


[jira] [Created] (RANGER-4779) Policy Conditions don't work on mask policy tags

2024-04-19 Thread Jonny Daenen (Jira)
Jonny Daenen created RANGER-4779:


 Summary: Policy Conditions don't work on mask policy tags
 Key: RANGER-4779
 URL: https://issues.apache.org/jira/browse/RANGER-4779
 Project: Ranger
  Issue Type: Bug
  Components: Ranger
Affects Versions: 2.3.0
Reporter: Jonny Daenen


When I try to add *policy conditions* to a {*}mask policy tag{*}, I cannot use 
built-in properties.

Example 1: only activate a mask whenever the user is part of a role/group:
{code:javascript}
IS_IN_GROUP('demo_masking')
{code}
{code:javascript}
_ctx.request.userGroups.indexOf('demo_masking') != -1
{code}
*Example 2: *deactivate the mask for a specific user, so that they can write to 
a Starburst table:
{code:javascript}
GET_USER_ATTR('name')=='some name' || GET_USER_ATTR('user name')=='some name' 
|| GET_USER_ATTR('User Name')=='some name' 
{code}
{code:javascript}
if(ctx.getUser().equals("some name")) ctx.result = false; 
{code}
*Problems encountered:*
 - It is unclear to me whether the functions/syntax I am using are correct (ctx 
vs _ctx, which functions/macros are allowed?)
 - it is unclear what is the preferred way of indication true/false: ctx.result 
vs an overall boolean statment
 - It is unclear how to debug this in a live system
 - It is unclear whether mask policy tags policy conditions are functioning 
correctly with Starburst/Trino
 - It is unclear from the code which part of macros en scripting is applicable 
to this specific case, making it difficult to understand what is allowed as 
script

*Proposed solutions:*
 - a clear indication in the documentation on the syntax of the policy 
conditions
 - a clear indication in the documentation on whether there are limits in mask 
policy tags
 - a clear indication in the documentation on whether there are limitations 
with mask policy tags in combination with e.g. Starburst/Trino
 - a working example of policy conditions, preferably several common scenarios

I might have overlooked parts of the documentation/code. If that is the case, 
any pointers in the right direction are much appreciated!

 

!image-2024-04-19-12-22-50-127.png|width=1458,height=750!

 



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


[jira] [Updated] (RANGER-4779) Policy Conditions don't work on mask policy tags

2024-04-19 Thread Jonny Daenen (Jira)


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

Jonny Daenen updated RANGER-4779:
-
Description: 
When I try to add *policy conditions* to a {*}mask policy tag{*}, I cannot use 
built-in properties.

Context: I want to manage access in Starburst based on tags 

Example 1: only activate a mask whenever the user is part of a role/group:
{code:javascript}
IS_IN_GROUP('demo_masking')
{code}
{code:javascript}
_ctx.request.userGroups.indexOf('demo_masking') != -1
{code}
*Example 2: *deactivate the mask for a specific user, so that they can write to 
a Starburst table:
{code:javascript}
GET_USER_ATTR('name')=='some name' || GET_USER_ATTR('user name')=='some name' 
|| GET_USER_ATTR('User Name')=='some name' 
{code}
{code:javascript}
if(ctx.getUser().equals("some name")) ctx.result = false; 
{code}
*Problems encountered:*
 - It is unclear to me whether the functions/syntax I am using are correct (ctx 
vs _ctx, which functions/macros are allowed?)
 - it is unclear what is the preferred way of indication true/false: ctx.result 
vs an overall boolean statment
 - It is unclear how to debug this in a live system
 - It is unclear whether mask policy tags policy conditions are functioning 
correctly with Starburst/Trino
 - It is unclear from the code which part of macros en scripting is applicable 
to this specific case, making it difficult to understand what is allowed as 
script

*Proposed solutions:*
 - a clear indication in the documentation on the syntax of the policy 
conditions
 - a clear indication in the documentation on whether there are limits in mask 
policy tags
 - a clear indication in the documentation on whether there are limitations 
with mask policy tags in combination with e.g. Starburst/Trino
 - a working example of policy conditions, preferably several common scenarios

I might have overlooked parts of the documentation/code. If that is the case, 
any pointers in the right direction are much appreciated!

 

!image-2024-04-19-12-25-04-879.png!

 

  was:
When I try to add *policy conditions* to a {*}mask policy tag{*}, I cannot use 
built-in properties.

Example 1: only activate a mask whenever the user is part of a role/group:
{code:javascript}
IS_IN_GROUP('demo_masking')
{code}
{code:javascript}
_ctx.request.userGroups.indexOf('demo_masking') != -1
{code}
*Example 2: *deactivate the mask for a specific user, so that they can write to 
a Starburst table:
{code:javascript}
GET_USER_ATTR('name')=='some name' || GET_USER_ATTR('user name')=='some name' 
|| GET_USER_ATTR('User Name')=='some name' 
{code}
{code:javascript}
if(ctx.getUser().equals("some name")) ctx.result = false; 
{code}
*Problems encountered:*
 - It is unclear to me whether the functions/syntax I am using are correct (ctx 
vs _ctx, which functions/macros are allowed?)
 - it is unclear what is the preferred way of indication true/false: ctx.result 
vs an overall boolean statment
 - It is unclear how to debug this in a live system
 - It is unclear whether mask policy tags policy conditions are functioning 
correctly with Starburst/Trino
 - It is unclear from the code which part of macros en scripting is applicable 
to this specific case, making it difficult to understand what is allowed as 
script

*Proposed solutions:*
 - a clear indication in the documentation on the syntax of the policy 
conditions
 - a clear indication in the documentation on whether there are limits in mask 
policy tags
 - a clear indication in the documentation on whether there are limitations 
with mask policy tags in combination with e.g. Starburst/Trino
 - a working example of policy conditions, preferably several common scenarios

I might have overlooked parts of the documentation/code. If that is the case, 
any pointers in the right direction are much appreciated!

 

!image-2024-04-19-12-22-50-127.png|width=1458,height=750!

 


> Policy Conditions don't work on mask policy tags
> 
>
> Key: RANGER-4779
> URL: https://issues.apache.org/jira/browse/RANGER-4779
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Affects Versions: 2.3.0
>Reporter: Jonny Daenen
>Priority: Major
> Attachments: ranger_issue.png
>
>
> When I try to add *policy conditions* to a {*}mask policy tag{*}, I cannot 
> use built-in properties.
> Context: I want to manage access in Starburst based on tags 
> Example 1: only activate a mask whenever the user is part of a role/group:
> {code:javascript}
> IS_IN_GROUP('demo_masking')
> {code}
> {code:javascript}
> _ctx.request.userGroups.indexOf('demo_masking') != -1
> {code}
> *Example 2: *deactivate the mask for a specific user, so that they can write 
> to a Starburst table:
> {code:javascript}
> GET_USER_ATTR('name')=='some name' || GET_USER_ATTR('user name')=='some name' 
> || G

[jira] [Updated] (RANGER-4779) Policy Conditions don't work on mask policy tags

2024-04-19 Thread Jonny Daenen (Jira)


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

Jonny Daenen updated RANGER-4779:
-
Attachment: ranger_issue.png

> Policy Conditions don't work on mask policy tags
> 
>
> Key: RANGER-4779
> URL: https://issues.apache.org/jira/browse/RANGER-4779
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Affects Versions: 2.3.0
>Reporter: Jonny Daenen
>Priority: Major
> Attachments: ranger_issue.png
>
>
> When I try to add *policy conditions* to a {*}mask policy tag{*}, I cannot 
> use built-in properties.
> Context: I want to manage access in Starburst based on tags 
> Example 1: only activate a mask whenever the user is part of a role/group:
> {code:javascript}
> IS_IN_GROUP('demo_masking')
> {code}
> {code:javascript}
> _ctx.request.userGroups.indexOf('demo_masking') != -1
> {code}
> *Example 2: *deactivate the mask for a specific user, so that they can write 
> to a Starburst table:
> {code:javascript}
> GET_USER_ATTR('name')=='some name' || GET_USER_ATTR('user name')=='some name' 
> || GET_USER_ATTR('User Name')=='some name' 
> {code}
> {code:javascript}
> if(ctx.getUser().equals("some name")) ctx.result = false; 
> {code}
> *Problems encountered:*
>  - It is unclear to me whether the functions/syntax I am using are correct 
> (ctx vs _ctx, which functions/macros are allowed?)
>  - it is unclear what is the preferred way of indication true/false: 
> ctx.result vs an overall boolean statment
>  - It is unclear how to debug this in a live system
>  - It is unclear whether mask policy tags policy conditions are functioning 
> correctly with Starburst/Trino
>  - It is unclear from the code which part of macros en scripting is 
> applicable to this specific case, making it difficult to understand what is 
> allowed as script
> *Proposed solutions:*
>  - a clear indication in the documentation on the syntax of the policy 
> conditions
>  - a clear indication in the documentation on whether there are limits in 
> mask policy tags
>  - a clear indication in the documentation on whether there are limitations 
> with mask policy tags in combination with e.g. Starburst/Trino
>  - a working example of policy conditions, preferably several common scenarios
> I might have overlooked parts of the documentation/code. If that is the case, 
> any pointers in the right direction are much appreciated!
>  
> !image-2024-04-19-12-25-04-879.png!
>  



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


[jira] [Updated] (RANGER-4779) Policy Conditions don't work on mask policy tags

2024-04-19 Thread Jonny Daenen (Jira)


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

Jonny Daenen updated RANGER-4779:
-
Description: 
When I try to add *policy conditions* to a {*}mask policy tag{*}, I cannot use 
built-in properties.

Context: I want to manage access in Starburst based on tags 

Example 1: only activate a mask whenever the user is part of a role/group:
{code:javascript}
IS_IN_GROUP('demo_masking')
{code}
{code:javascript}
_ctx.request.userGroups.indexOf('demo_masking') != -1
{code}
*Example 2: *deactivate the mask for a specific user, so that they can write to 
a Starburst table:
{code:javascript}
GET_USER_ATTR('name')=='some name' || GET_USER_ATTR('user name')=='some name' 
|| GET_USER_ATTR('User Name')=='some name' 
{code}
{code:javascript}
if(ctx.getUser().equals("some name")) ctx.result = false; 
{code}
*Problems encountered:*
 - It is unclear to me whether the functions/syntax I am using are correct (ctx 
vs _ctx, which functions/macros are allowed?)
 - it is unclear what is the preferred way of indication true/false: ctx.result 
vs an overall boolean statment
 - It is unclear how to debug this in a live system
 - It is unclear whether mask policy tags policy conditions are functioning 
correctly with Starburst/Trino
 - It is unclear from the code which part of macros en scripting is applicable 
to this specific case, making it difficult to understand what is allowed as 
script

*Proposed solutions:*
 - a clear indication in the documentation on the syntax of the policy 
conditions
 - a clear indication in the documentation on whether there are limits in mask 
policy tags
 - a clear indication in the documentation on whether there are limitations 
with mask policy tags in combination with e.g. Starburst/Trino
 - a working example of policy conditions, preferably several common scenarios

I might have overlooked parts of the documentation/code. If that is the case, 
any pointers in the right direction are much appreciated!

 

  was:
When I try to add *policy conditions* to a {*}mask policy tag{*}, I cannot use 
built-in properties.

Context: I want to manage access in Starburst based on tags 

Example 1: only activate a mask whenever the user is part of a role/group:
{code:javascript}
IS_IN_GROUP('demo_masking')
{code}
{code:javascript}
_ctx.request.userGroups.indexOf('demo_masking') != -1
{code}
*Example 2: *deactivate the mask for a specific user, so that they can write to 
a Starburst table:
{code:javascript}
GET_USER_ATTR('name')=='some name' || GET_USER_ATTR('user name')=='some name' 
|| GET_USER_ATTR('User Name')=='some name' 
{code}
{code:javascript}
if(ctx.getUser().equals("some name")) ctx.result = false; 
{code}
*Problems encountered:*
 - It is unclear to me whether the functions/syntax I am using are correct (ctx 
vs _ctx, which functions/macros are allowed?)
 - it is unclear what is the preferred way of indication true/false: ctx.result 
vs an overall boolean statment
 - It is unclear how to debug this in a live system
 - It is unclear whether mask policy tags policy conditions are functioning 
correctly with Starburst/Trino
 - It is unclear from the code which part of macros en scripting is applicable 
to this specific case, making it difficult to understand what is allowed as 
script

*Proposed solutions:*
 - a clear indication in the documentation on the syntax of the policy 
conditions
 - a clear indication in the documentation on whether there are limits in mask 
policy tags
 - a clear indication in the documentation on whether there are limitations 
with mask policy tags in combination with e.g. Starburst/Trino
 - a working example of policy conditions, preferably several common scenarios

I might have overlooked parts of the documentation/code. If that is the case, 
any pointers in the right direction are much appreciated!

 

!image-2024-04-19-12-25-04-879.png!

 


> Policy Conditions don't work on mask policy tags
> 
>
> Key: RANGER-4779
> URL: https://issues.apache.org/jira/browse/RANGER-4779
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Affects Versions: 2.3.0
>Reporter: Jonny Daenen
>Priority: Major
> Attachments: ranger_issue.png
>
>
> When I try to add *policy conditions* to a {*}mask policy tag{*}, I cannot 
> use built-in properties.
> Context: I want to manage access in Starburst based on tags 
> Example 1: only activate a mask whenever the user is part of a role/group:
> {code:javascript}
> IS_IN_GROUP('demo_masking')
> {code}
> {code:javascript}
> _ctx.request.userGroups.indexOf('demo_masking') != -1
> {code}
> *Example 2: *deactivate the mask for a specific user, so that they can write 
> to a Starburst table:
> {code:javascript}
> GET_USER_ATTR('name')=='some name' || GET_USER_ATTR('user name')=='some name' 
> || G

Re: Review Request 74940: RANGER-4744: Ranger Admin startup using JDK17 gives ERROR in catalina.out due to missing jaxb dependencies

2024-04-19 Thread Rakesh Gupta

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

(Updated April 19, 2024, 12:05 p.m.)


Review request for ranger, bhavik patel, Dineshkumar Yadav, Kishor 
Gollapalliwar, Mehul Parikh, Pradeep Agrawal, Ramesh Mani, sanket shelar, 
Sailaja Polavarapu, and Velmurugan Periasamy.


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


Repository: ranger


Description
---

When we try to start Ranger Admin using JDK17, the Ranger Admin startup gives 
ERROR "javax.xml.bind.JAXBException Implementation of JAXB-API has not been 
found on module path or classpath" in catalina.out due to missing jaxb 
dependencies.
The jaxb classes were part of rt.jar in jdk8, but were removed in later 
versions of JDK.


Diffs (updated)
-

  kms/pom.xml 0b37ce52d 
  security-admin/pom.xml fc59287d0 


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

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


Testing
---

Build Ranger using the command below and set up a local cluster by executing 
'mvn clean compile package install', followed by starting the Ranger Admin.

Verified that no errors are seen in the catalina.out file upon Ranger Admin 
startup.


Thanks,

Rakesh Gupta



[jira] [Commented] (RANGER-4743) [JDK 11]: Fix ranger admin logging

2024-04-19 Thread Rakesh Gupta (Jira)


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

Rakesh Gupta commented on RANGER-4743:
--

Hi [~abhi_2110],

I just wanted to confirm whether you had the chance to try out the patch?

> [JDK 11]: Fix ranger admin logging 
> ---
>
> Key: RANGER-4743
> URL: https://issues.apache.org/jira/browse/RANGER-4743
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Affects Versions: 2.4.0
>Reporter: Abhishek Kumar
>Assignee: Abhishek Kumar
>Priority: Major
> Attachments: 0001-RANGER-4743.patch
>
>
> Currently, the ranger-admin logs do not appear when built and run with jdk 11.
> Logback and slf4j versions need to be upgraded to fix the above issue.
> More info: [https://logback.qos.ch/download.html] 
> CC: [~rmani]



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


Re: Review Request 74926: RANGER-4076: Support Java 17 for build and runtime

2024-04-19 Thread Rakesh Gupta


> On March 6, 2024, 6:28 a.m., Kishor Gollapalliwar wrote:
> > plugin-nestedstructure/src/test/java/org/apache/ranger/authorization/nestedstructure/authorizer/TestRecordFilterJavaScript.java
> > Line 59 (original), 62 (patched)
> > 
> >
> > Will this break backword compatibility. If a older setup is using 
> > Scripts (compatible with Nashorm), will they need to update ?

No, backward compatibility won't be affected


- Rakesh


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


On March 5, 2024, 7:10 a.m., Rakesh Gupta wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/74926/
> ---
> 
> (Updated March 5, 2024, 7:10 a.m.)
> 
> 
> Review request for ranger, Dineshkumar Yadav, Kishor Gollapalliwar, Abhay 
> Kulkarni, Madhan Neethiraj, Mehul Parikh, Pradeep Agrawal, Ramesh Mani, 
> sanket shelar, Sailaja Polavarapu, and Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-4076
> https://issues.apache.org/jira/browse/RANGER-4076
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> Currently only Java 8 and 11 are supported.  Java 17 is a major LTS version 
> of Java and adding support would modernize our Java version support.
> 
> This patch enables manual and Docker-based build of Apache Ranger. It ensures 
> compatibility with Java 8, Java 11, and Java 17 for both build and runtime 
> environments.
> (I encountered a TestCase Failure in the KnoxRangerTest class, so currently I 
> had excluded that class from jdk17 build)
> 
> 
> Diffs
> -
> 
>   agents-common/pom.xml 12e093f78 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/util/GraalScriptEngineCreator.java
>  512d8d3ca 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/util/NashornScriptEngineCreator.java
>  db620df92 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/util/ScriptEngineUtil.java
>  8d76c1d81 
>   dev-support/ranger-docker/.env 60bc4a9f2 
>   dev-support/ranger-docker/Dockerfile.ranger-build 9a192f152 
>   dev-support/ranger-docker/docker-compose.ranger-build.yml 3dd4a4a06 
>   distro/src/main/assembly/admin-web.xml 245d9ca09 
>   docs/src/site/resources/index.js bb876f28d 
>   hdfs-agent/pom.xml dece8f46f 
>   kms/pom.xml 2739bb81a 
>   kms/src/main/java/org/apache/hadoop/crypto/key/RangerKeyStore.java 
> 7188b19b2 
>   kms/src/main/java/org/apache/hadoop/crypto/key/RangerMasterKey.java 
> b6fc32950 
>   plugin-nestedstructure/pom.xml 0e208f99c 
>   
> plugin-nestedstructure/src/main/java/org/apache/ranger/authorization/nestedstructure/authorizer/RecordFilterJavaScript.java
>  77767767c 
>   
> plugin-nestedstructure/src/test/java/org/apache/ranger/authorization/nestedstructure/authorizer/TestRecordFilterJavaScript.java
>  9cb161b8d 
>   pom.xml cec2390f2 
>   ranger-tools/pom.xml cac8d7ba3 
>   
> ranger-tools/src/test/java/org/apache/ranger/policyengine/RangerPolicyEnginePerformanceTest.java
>  187d20227 
>   security-admin/pom.xml fc59287d0 
> 
> 
> Diff: https://reviews.apache.org/r/74926/diff/1/
> 
> 
> Testing
> ---
> 
> This patch has been successfully tested and verified with Java versions 8, 
> 11, and 17. The verification process included both manual and Docker setup. 
> Now we are able to build and run on same jdk.
> 
> 
> Thanks,
> 
> Rakesh Gupta
> 
>



Re: Review Request 74926: RANGER-4076: Support Java 17 for build and runtime

2024-04-19 Thread Rakesh Gupta

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

(Updated April 19, 2024, 3:19 p.m.)


Review request for ranger, Dineshkumar Yadav, Kishor Gollapalliwar, Abhay 
Kulkarni, Madhan Neethiraj, Mehul Parikh, Pradeep Agrawal, Ramesh Mani, sanket 
shelar, Sailaja Polavarapu, and Velmurugan Periasamy.


Changes
---

Review comment handle


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


Repository: ranger


Description (updated)
---

Currently only Java 8 and 11 are supported.  Java 17 is a major LTS version of 
Java and adding support would modernize our Java version support.

This patch enables manual and Docker-based build of Apache Ranger. It ensures 
compatibility with Java 8, Java 11, and Java 17 for both build and runtime 
environments.


Diffs (updated)
-

  agents-common/pom.xml 12e093f78 
  
agents-common/src/main/java/org/apache/ranger/plugin/util/GraalScriptEngineCreator.java
 512d8d3ca 
  
agents-common/src/main/java/org/apache/ranger/plugin/util/JavaScriptEngineCreator.java
 4a0081579 
  
agents-common/src/main/java/org/apache/ranger/plugin/util/NashornScriptEngineCreator.java
 db620df92 
  
agents-common/src/main/java/org/apache/ranger/plugin/util/ScriptEngineUtil.java 
8d76c1d81 
  
agents-common/src/test/java/org/apache/ranger/plugin/conditionevaluator/RangerRequestScriptEvaluatorTest.java
 0059bef88 
  dev-support/ranger-docker/.env 91613e5ec 
  dev-support/ranger-docker/Dockerfile.ranger-build 9a192f152 
  dev-support/ranger-docker/docker-compose.ranger-build.yml c8760aab5 
  distro/src/main/assembly/admin-web.xml 245d9ca09 
  distro/src/main/assembly/hbase-agent.xml ffb1de0c5 
  distro/src/main/assembly/hdfs-agent.xml 349badfd2 
  distro/src/main/assembly/hive-agent.xml 5bae92ac5 
  distro/src/main/assembly/knox-agent.xml 3fa867150 
  distro/src/main/assembly/plugin-atlas.xml c389282fc 
  distro/src/main/assembly/plugin-kafka.xml 4ffbdd611 
  distro/src/main/assembly/plugin-kms.xml 7c6a16330 
  distro/src/main/assembly/plugin-kylin.xml 9aefa49d4 
  distro/src/main/assembly/plugin-ozone.xml 294e5b9ef 
  distro/src/main/assembly/plugin-presto.xml d50edf2d9 
  distro/src/main/assembly/plugin-solr.xml bcb24c0fc 
  distro/src/main/assembly/plugin-sqoop.xml adc2a9c26 
  distro/src/main/assembly/plugin-yarn.xml 5db884710 
  distro/src/main/assembly/storm-agent.xml a334e247c 
  docs/src/site/resources/index.js bb876f28d 
  hdfs-agent/pom.xml dece8f46f 
  kms/pom.xml 0b37ce52d 
  kms/src/main/java/org/apache/hadoop/crypto/key/RangerMasterKey.java b6fc32950 
  knox-agent/pom.xml 4387efb5c 
  plugin-nestedstructure/pom.xml 0e208f99c 
  
plugin-nestedstructure/src/main/java/org/apache/ranger/authorization/nestedstructure/authorizer/RecordFilterJavaScript.java
 77767767c 
  
plugin-nestedstructure/src/test/java/org/apache/ranger/authorization/nestedstructure/authorizer/TestRecordFilterJavaScript.java
 9cb161b8d 
  pom.xml efd152040 
  security-admin/pom.xml fc59287d0 


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

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


Testing (updated)
---

This patch has been successfully tested and verified with Java versions 8, 11, 
and 17. The verification process included both manual and Docker setup. Now we 
are able to build and run on same jdk.

### JDK 8 build successfully
mvn clean compile package install

### JDK 11 build successfully
mvn clean compile package install

### JDK 17 build successfully
mvn clean compile package install -Pranger-all-modules-jdk17


Thanks,

Rakesh Gupta



Re: Review Request 74953: RANGER-4769: removed code duplication in generation of admin audit logs

2024-04-19 Thread Madhan Neethiraj

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



Rangers - please review this update. A subsequent patch to improve admin audit 
query response time will depend on this one. Thanks!

- Madhan Neethiraj


On April 5, 2024, 10:56 p.m., Madhan Neethiraj wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/74953/
> ---
> 
> (Updated April 5, 2024, 10:56 p.m.)
> 
> 
> Review request for ranger, Anand Nadar, Asit Vadhavkar, Abhay Kulkarni, Mehul 
> Parikh, Ramesh Mani, Siddhesh Phatak, Sailaja Polavarapu, Subhrat Chaudhary, 
> and Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-4769
> https://issues.apache.org/jira/browse/RANGER-4769
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> - replaced getTransactionLog() implementation in 13 classes with 
> implementations in following base classes
> -- AbstractAuditedResourceService.createTransactionLog()
> -- RangerAuditedModelService.createTransactionLog()
> 
> 
> Diffs
> -
> 
>   security-admin/src/main/java/org/apache/ranger/biz/PolicyRefUpdater.java 
> 40d4c4043 
>   security-admin/src/main/java/org/apache/ranger/biz/RoleDBStore.java 
> 0aa03e7c2 
>   security-admin/src/main/java/org/apache/ranger/biz/RoleRefUpdater.java 
> 9e2f28716 
>   security-admin/src/main/java/org/apache/ranger/biz/SecurityZoneDBStore.java 
> 42943946c 
>   
> security-admin/src/main/java/org/apache/ranger/biz/SecurityZoneRefUpdater.java
>  10bbfcd32 
>   security-admin/src/main/java/org/apache/ranger/biz/ServiceDBStore.java 
> 47fbe 
>   security-admin/src/main/java/org/apache/ranger/biz/UserMgr.java d5393603e 
>   security-admin/src/main/java/org/apache/ranger/biz/XUserMgr.java d202b2184 
>   security-admin/src/main/java/org/apache/ranger/common/view/VTrxLogAttr.java 
> 8c86a92c6 
>   security-admin/src/main/java/org/apache/ranger/entity/XXTrxLog.java 
> c308fba7b 
>   security-admin/src/main/java/org/apache/ranger/rest/RoleREST.java 4bfaa862c 
>   security-admin/src/main/java/org/apache/ranger/rest/ServiceREST.java 
> a6c759234 
>   
> security-admin/src/main/java/org/apache/ranger/service/AbstractAuditedResourceService.java
>  PRE-CREATION 
>   
> security-admin/src/main/java/org/apache/ranger/service/AbstractBaseResourceService.java
>  1f2659d4b 
>   
> security-admin/src/main/java/org/apache/ranger/service/RangerAuditedModelService.java
>  PRE-CREATION 
>   
> security-admin/src/main/java/org/apache/ranger/service/RangerGdsBaseModelService.java
>  421646d86 
>   
> security-admin/src/main/java/org/apache/ranger/service/RangerGdsDataShareInDatasetService.java
>  a76cb2a99 
>   
> security-admin/src/main/java/org/apache/ranger/service/RangerGdsDataShareService.java
>  55c4b3633 
>   
> security-admin/src/main/java/org/apache/ranger/service/RangerGdsDatasetInProjectService.java
>  62074cfd7 
>   
> security-admin/src/main/java/org/apache/ranger/service/RangerGdsDatasetService.java
>  a82672a37 
>   
> security-admin/src/main/java/org/apache/ranger/service/RangerGdsProjectService.java
>  d70da154e 
>   
> security-admin/src/main/java/org/apache/ranger/service/RangerGdsSharedResourceService.java
>  b1b5a841a 
>   
> security-admin/src/main/java/org/apache/ranger/service/RangerPolicyService.java
>  b59b94f43 
>   
> security-admin/src/main/java/org/apache/ranger/service/RangerPolicyServiceBase.java
>  a2929f3c1 
>   
> security-admin/src/main/java/org/apache/ranger/service/RangerRoleService.java 
> 7e0b29c89 
>   
> security-admin/src/main/java/org/apache/ranger/service/RangerRoleServiceBase.java
>  39755da1d 
>   
> security-admin/src/main/java/org/apache/ranger/service/RangerSecurityZoneServiceBase.java
>  586a6b705 
>   
> security-admin/src/main/java/org/apache/ranger/service/RangerSecurityZoneServiceService.java
>  a6cb2ae74 
>   
> security-admin/src/main/java/org/apache/ranger/service/RangerServiceService.java
>  3acbfd55d 
>   
> security-admin/src/main/java/org/apache/ranger/service/RangerServiceServiceBase.java
>  fa23b96d7 
>   security-admin/src/main/java/org/apache/ranger/service/XAssetService.java 
> b937cff04 
>   
> security-admin/src/main/java/org/apache/ranger/service/XAssetServiceBase.java 
> 6855a0b63 
>   
> security-admin/src/main/java/org/apache/ranger/service/XAuditMapService.java 
> 3fe0832e2 
>   
> security-admin/src/main/java/org/apache/ranger/service/XAuditMapServiceBase.java
>  0eb7d9bc7 
>   security-admin/src/main/java/org/apache/ranger/service/XGroupService.java 
> 1f033b33d 
>   
> security-admin/src/main/java/org/apache/ranger/service/XGroupServiceBase.java 
> 3b50ed5fe 
>   
> security-admin/src/main/java/org/apache/ranger/service/XGroupUserService.java 
> 5cfcb785c 
>   
> security-admin/sr