[jira] [Assigned] (RANGER-4820) Support authorization of multiple accesses grouped by access groups in one policy engine call

2024-06-12 Thread Abhay Kulkarni (Jira)


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

Abhay Kulkarni reassigned RANGER-4820:
--

Assignee: Abhay Kulkarni

> Support authorization of multiple accesses grouped by access groups in one 
> policy engine call
> -
>
> Key: RANGER-4820
> URL: https://issues.apache.org/jira/browse/RANGER-4820
> Project: Ranger
>  Issue Type: Improvement
>  Components: Ranger
>Reporter: Abhay Kulkarni
>Assignee: Abhay Kulkarni
>Priority: Major
>
> Currently, Ranger policy engine supports authorization of multiple accesses 
> for a given resource in a single call to the Ranger plugin's 
> isAccessAllowed() API. However, it has some limitations which are addressed 
> by this JIRA.
> Limitation: If multiple accesses are to be authorized, then the current 
> authorization logic in Ranger policy engine is designed to allow the request 
> to succeed (that is, grant access) only if all requested accesses are granted.
> This Jira supports organizing  accesses in groups where each group is granted 
> access if any access in the group is allowed, and the request is successful 
> (that is, user is allowed access) only if all groups are granted access.



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


[jira] [Created] (RANGER-4820) Support authorization of multiple accesses grouped by access groups in one policy engine call

2024-06-12 Thread Abhay Kulkarni (Jira)
Abhay Kulkarni created RANGER-4820:
--

 Summary: Support authorization of multiple accesses grouped by 
access groups in one policy engine call
 Key: RANGER-4820
 URL: https://issues.apache.org/jira/browse/RANGER-4820
 Project: Ranger
  Issue Type: Improvement
  Components: Ranger
Reporter: Abhay Kulkarni


Currently, Ranger policy engine supports authorization of multiple accesses for 
a given resource in a single call to the Ranger plugin's isAccessAllowed() API. 
However, it has some limitations which are addressed by this JIRA.

Limitation: If multiple accesses are to be authorized, then the current 
authorization logic in Ranger policy engine is designed to allow the request to 
succeed (that is, grant access) only if all requested accesses are granted.

This Jira supports organizing  accesses in groups where each group is granted 
access if any access in the group is allowed, and the request is successful 
(that is, user is allowed access) only if all groups are granted access.



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


[jira] [Updated] (RANGER-4816) build Trino Ranger plugin in Trino project

2024-06-12 Thread Madhan Neethiraj (Jira)


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

Madhan Neethiraj updated RANGER-4816:
-
Attachment: (was: RANGER-4810.patch)

> build Trino Ranger plugin in Trino project
> --
>
> Key: RANGER-4816
> URL: https://issues.apache.org/jira/browse/RANGER-4816
> Project: Ranger
>  Issue Type: Sub-task
>  Components: plugins
>Reporter: Madhan Neethiraj
>Assignee: Madhan Neethiraj
>Priority: Major
> Attachments: RANGER-4810-trino-repo.patch
>
>




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


[jira] [Updated] (RANGER-4816) build Trino Ranger plugin in Trino project

2024-06-12 Thread Madhan Neethiraj (Jira)


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

Madhan Neethiraj updated RANGER-4816:
-
Attachment: RANGER-4810-trino-repo.patch

> build Trino Ranger plugin in Trino project
> --
>
> Key: RANGER-4816
> URL: https://issues.apache.org/jira/browse/RANGER-4816
> Project: Ranger
>  Issue Type: Sub-task
>  Components: plugins
>Reporter: Madhan Neethiraj
>Assignee: Madhan Neethiraj
>Priority: Major
> Attachments: RANGER-4810-trino-repo.patch, RANGER-4810.patch
>
>




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


[jira] [Assigned] (RANGER-4777) Improve API /public/v2/api/service-headers to filter services depending on user role

2024-06-12 Thread Dineshkumar Yadav (Jira)


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

Dineshkumar Yadav reassigned RANGER-4777:
-

Assignee: Rakesh Gupta  (was: Madhan Neethiraj)

> Improve API /public/v2/api/service-headers to filter services depending on 
> user role
> 
>
> Key: RANGER-4777
> URL: https://issues.apache.org/jira/browse/RANGER-4777
> Project: Ranger
>  Issue Type: Bug
>  Components: admin, Ranger
>Reporter: Mugdha Varadkar
>Assignee: Rakesh Gupta
>Priority: Major
>
> Need to update the API - "/public/v2/api/service-headers" introduce in 
> RANGER-4533  with below :
> # The API should be accessible for non-admin users as well. @PreAuthrize 
> annotation can be removed.
> # Filtering of services depending on user role like done for existing API - 
> "/plugins/services"
> cc [~dineshkumar-yadav] / [~Dhaval.Rajpara]



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


[jira] [Assigned] (RANGER-4711) Show grant on table command is not audited by ranger

2024-06-12 Thread Guru Thejus (Jira)


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

Guru Thejus reassigned RANGER-4711:
---

Assignee: Guru Thejus

> Show grant on table command is not audited by ranger
> 
>
> Key: RANGER-4711
> URL: https://issues.apache.org/jira/browse/RANGER-4711
> Project: Ranger
>  Issue Type: Bug
>  Components: audit
>Reporter: suja s
>Assignee: Guru Thejus
>Priority: Major
>




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


[jira] [Created] (RANGER-4819) Proposal to Upgrade All React.js Dependent Libraries

2024-06-12 Thread Dhaval Rajpara (Jira)
Dhaval Rajpara created RANGER-4819:
--

 Summary:  Proposal to Upgrade All React.js Dependent Libraries
 Key: RANGER-4819
 URL: https://issues.apache.org/jira/browse/RANGER-4819
 Project: Ranger
  Issue Type: Bug
  Components: Ranger
Reporter: Dhaval Rajpara
Assignee: Dhaval Rajpara


Upgrading all dependent libraries for React.js in our project. This will ensure 
we are using the latest versions, improving security, performance, and 
compatibility with new features.
# babel/traverse
# axios
# braces
# follow-redirects
# json5
# loader-utils
# minimist
# moment
# terser
# webpack
# webpack-dev-middleware



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


[jira] [Updated] (RANGER-4818) [usersync] Users undergoing role reset to ROLE_USER from ROLE_SYS_ADMIN

2024-06-11 Thread Abhishek Kumar (Jira)


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

Abhishek Kumar updated RANGER-4818:
---
Description: updateUserRoleAssignments function in XUserMgr (ranger-admin) 
resets the role of the user from admin to user role for users which are part of 
the request but are not part of the same page when paged requests are sent to 
ranger-admin from ranger-usersync.  (was: updateRoleAssignments on ranger-admin 
resets the role of the user from admin to user role for users which are part of 
the request but are not part of the same page when paged requests are sent to 
ranger-admin from ranger-usersync.)

> [usersync] Users undergoing role reset to ROLE_USER from ROLE_SYS_ADMIN
> ---
>
> Key: RANGER-4818
> URL: https://issues.apache.org/jira/browse/RANGER-4818
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Affects Versions: 2.4.0
>Reporter: Abhishek Kumar
>Assignee: Abhishek Kumar
>Priority: Major
>
> updateUserRoleAssignments function in XUserMgr (ranger-admin) resets the role 
> of the user from admin to user role for users which are part of the request 
> but are not part of the same page when paged requests are sent to 
> ranger-admin from ranger-usersync.



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


[jira] [Created] (RANGER-4818) [usersync] Users undergoing role reset to ROLE_USER from ROLE_SYS_ADMIN

2024-06-11 Thread Abhishek Kumar (Jira)
Abhishek Kumar created RANGER-4818:
--

 Summary: [usersync] Users undergoing role reset to ROLE_USER from 
ROLE_SYS_ADMIN
 Key: RANGER-4818
 URL: https://issues.apache.org/jira/browse/RANGER-4818
 Project: Ranger
  Issue Type: Bug
  Components: Ranger
Affects Versions: 2.4.0
Reporter: Abhishek Kumar
Assignee: Abhishek Kumar


updateRoleAssignments on ranger-admin resets the role of the user from admin to 
user role for users which are part of the request but are not part of the same 
page when paged requests are sent to ranger-admin from ranger-usersync.



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


[jira] [Assigned] (RANGER-4817) Optimize Ranger HDFS Authorization by combining multiple authorization calls

2024-06-11 Thread Abhay Kulkarni (Jira)


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

Abhay Kulkarni reassigned RANGER-4817:
--

Assignee: Abhay Kulkarni

> Optimize Ranger HDFS Authorization by combining multiple authorization calls
> 
>
> Key: RANGER-4817
> URL: https://issues.apache.org/jira/browse/RANGER-4817
> Project: Ranger
>  Issue Type: Improvement
>  Components: Ranger
>Reporter: Abhay Kulkarni
>Assignee: Abhay Kulkarni
>Priority: Major
>
> The focus of optimizations described below is to minimize the number of times 
> the Ranger policy-engine is called to authorize a NameNode RPC without 
> modifying the Namenode authorization interface or authorization call sequence.
> This optimization is possible as the Namenode calls the authorizer more than 
> once to authorize some RPCs, as observed during the testing. To ensure that 
> the authorizer is provided a consistent context to represent a RPC, some 
> improvements are needed in the Namenode. Related Namenode JIRAs are
> {*}HDFS-17478{*}: Avoid creation of AccessControlEnforcer object for every 
> call to the authorizer, and
> {*}HDFS-17500{*}: Provide operation name consistently in the caller-context 
> provided to checkPermissionWithContext() API.
> Ranger authorizer is updated to leverage this context to optimize 
> authorization calls for the RPC. In particular, the following RPC operations' 
> authorization logic is updated.
>  
> List of operations with optimized authorization checks.
>  # Create file: operation name “create” 
>  # Rename file: operation name “rename”
>  # Delete file: operation name “delete”
>  # Create directory: operation name “mkdirs”
>  # List directory contents: operation name “listStatus”
>  # Rename directory: operation name “rename”
>  # Delete directory: operation name “delete”
>  # Get Encryption Zone for a directory: operation name “getEZForPath”



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


[jira] [Created] (RANGER-4817) Optimize Ranger HDFS Authorization by combining multiple authorization calls

2024-06-11 Thread Abhay Kulkarni (Jira)
Abhay Kulkarni created RANGER-4817:
--

 Summary: Optimize Ranger HDFS Authorization by combining multiple 
authorization calls
 Key: RANGER-4817
 URL: https://issues.apache.org/jira/browse/RANGER-4817
 Project: Ranger
  Issue Type: Improvement
  Components: Ranger
Reporter: Abhay Kulkarni


The focus of optimizations described below is to minimize the number of times 
the Ranger policy-engine is called to authorize a NameNode RPC without 
modifying the Namenode authorization interface or authorization call sequence.

This optimization is possible as the Namenode calls the authorizer more than 
once to authorize some RPCs, as observed during the testing. To ensure that the 
authorizer is provided a consistent context to represent a RPC, some 
improvements are needed in the Namenode. Related Namenode JIRAs are

{*}HDFS-17478{*}: Avoid creation of AccessControlEnforcer object for every call 
to the authorizer, and

{*}HDFS-17500{*}: Provide operation name consistently in the caller-context 
provided to checkPermissionWithContext() API.

Ranger authorizer is updated to leverage this context to optimize authorization 
calls for the RPC. In particular, the following RPC operations' authorization 
logic is updated.

 

List of operations with optimized authorization checks.
 # Create file: operation name “create” 
 # Rename file: operation name “rename”
 # Delete file: operation name “delete”
 # Create directory: operation name “mkdirs”
 # List directory contents: operation name “listStatus”
 # Rename directory: operation name “rename”
 # Delete directory: operation name “delete”
 # Get Encryption Zone for a directory: operation name “getEZForPath”



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


[jira] [Updated] (RANGER-4816) build Trino Ranger plugin in Trino project

2024-06-10 Thread Madhan Neethiraj (Jira)


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

Madhan Neethiraj updated RANGER-4816:
-
Attachment: RANGER-4810.patch

> build Trino Ranger plugin in Trino project
> --
>
> Key: RANGER-4816
> URL: https://issues.apache.org/jira/browse/RANGER-4816
> Project: Ranger
>  Issue Type: Sub-task
>  Components: plugins
>Reporter: Madhan Neethiraj
>Assignee: Madhan Neethiraj
>Priority: Major
> Attachments: RANGER-4810.patch
>
>




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


[jira] [Created] (RANGER-4816) build Trino Ranger plugin in Trino project

2024-06-10 Thread Madhan Neethiraj (Jira)
Madhan Neethiraj created RANGER-4816:


 Summary: build Trino Ranger plugin in Trino project
 Key: RANGER-4816
 URL: https://issues.apache.org/jira/browse/RANGER-4816
 Project: Ranger
  Issue Type: Sub-task
  Components: plugins
Reporter: Madhan Neethiraj
Assignee: Madhan Neethiraj






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


[jira] [Updated] (RANGER-4815) remove unnecessary shim layer for Trino Ranger authorizer

2024-06-07 Thread Madhan Neethiraj (Jira)


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

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

> remove unnecessary shim layer for Trino Ranger authorizer
> -
>
> Key: RANGER-4815
> URL: https://issues.apache.org/jira/browse/RANGER-4815
> Project: Ranger
>  Issue Type: Sub-task
>  Components: plugins
>Reporter: Madhan Neethiraj
>Assignee: Madhan Neethiraj
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: RANGER-4815.patch
>
>
> Ranger authorization plugins use a shim layer to isolate its dependencies 
> from the host service. However, this is not necessary for Trino authorizer 
> plugin as Trino already uses classloader isolation for its plugins. Here is 
> from Trino documentation at  
> [https://trino.io/docs/current/develop/spi-overview.html:]
> {noformat}
> Plugins are loaded in a separate class loader to provide isolation and to 
> allow plugins to use a different version of a library that Trino uses 
> internally. {noformat}
> Hence ranger-trino-plugin-shim project can be removed.



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


[jira] [Created] (RANGER-4815) remove unnecessary shim layer for Trino Ranger authorizer

2024-06-07 Thread Madhan Neethiraj (Jira)
Madhan Neethiraj created RANGER-4815:


 Summary: remove unnecessary shim layer for Trino Ranger authorizer
 Key: RANGER-4815
 URL: https://issues.apache.org/jira/browse/RANGER-4815
 Project: Ranger
  Issue Type: Sub-task
  Components: plugins
Reporter: Madhan Neethiraj


Ranger authorization plugins use a shim layer to isolate its dependencies from 
the host service. However, this is not necessary for Trino authorizer plugin as 
Trino already uses classloader isolation for its plugins. Here is from Trino 
documentation at  [https://trino.io/docs/current/develop/spi-overview.html:]


{noformat}
Plugins are loaded in a separate class loader to provide isolation and to allow 
plugins to use a different version of a library that Trino uses internally. 
{noformat}

Hence ranger-trino-plugin-shim project can be removed.



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


[jira] [Assigned] (RANGER-4815) remove unnecessary shim layer for Trino Ranger authorizer

2024-06-07 Thread Madhan Neethiraj (Jira)


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

Madhan Neethiraj reassigned RANGER-4815:


Assignee: Madhan Neethiraj

> remove unnecessary shim layer for Trino Ranger authorizer
> -
>
> Key: RANGER-4815
> URL: https://issues.apache.org/jira/browse/RANGER-4815
> Project: Ranger
>  Issue Type: Sub-task
>  Components: plugins
>Reporter: Madhan Neethiraj
>Assignee: Madhan Neethiraj
>Priority: Major
>
> Ranger authorization plugins use a shim layer to isolate its dependencies 
> from the host service. However, this is not necessary for Trino authorizer 
> plugin as Trino already uses classloader isolation for its plugins. Here is 
> from Trino documentation at  
> [https://trino.io/docs/current/develop/spi-overview.html:]
> {noformat}
> Plugins are loaded in a separate class loader to provide isolation and to 
> allow plugins to use a different version of a library that Trino uses 
> internally. {noformat}
> Hence ranger-trino-plugin-shim project can be removed.



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


[jira] [Created] (RANGER-4814) Ranger - Upgrade Aircompressor to 0.27

2024-06-06 Thread Dineshkumar Yadav (Jira)
Dineshkumar Yadav created RANGER-4814:
-

 Summary: Ranger - Upgrade Aircompressor to 0.27
 Key: RANGER-4814
 URL: https://issues.apache.org/jira/browse/RANGER-4814
 Project: Ranger
  Issue Type: Task
  Components: Ranger
Reporter: Dineshkumar Yadav
Assignee: Dineshkumar Yadav


Ranger - Upgrade Aircompressor to 0.27



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


[jira] [Assigned] (RANGER-4813) update audit UI to retrieve V2 trx log record

2024-06-06 Thread Abhishek (Jira)


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

Abhishek reassigned RANGER-4813:


Assignee: Abhishek

> update audit UI to retrieve V2 trx log record
> -
>
> Key: RANGER-4813
> URL: https://issues.apache.org/jira/browse/RANGER-4813
> Project: Ranger
>  Issue Type: Sub-task
>  Components: admin
>Reporter: Madhan Neethiraj
>Assignee: Abhishek
>Priority: Major
>
> Currently admin audit UI retrieves multiple V1 trx logs to gather details of 
> an update (REST API: service/assets//report/\{transactionId}). This should be 
> optimized to retrieve a single V2 trx log record (introduced in RANGER-4803) 
> to render in UI. A new API should be added to retrieve V2 trx log record.



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


[jira] [Assigned] (RANGER-4812) database schema patch to create x_trx_log_v2 table

2024-06-06 Thread Abhishek (Jira)


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

Abhishek reassigned RANGER-4812:


Assignee: Abhishek

> database schema patch to create x_trx_log_v2 table
> --
>
> Key: RANGER-4812
> URL: https://issues.apache.org/jira/browse/RANGER-4812
> Project: Ranger
>  Issue Type: Sub-task
>  Components: admin
>Reporter: Madhan Neethiraj
>Assignee: Abhishek
>Priority: Major
>
> RANGER-4803 introduced new table named x_trx_log_v2. A database schema patch 
> will be needed to create x_trx_log_v2 table in existing Ranger deployments.



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


[jira] [Created] (RANGER-4813) update audit UI to retrieve V2 trx log record

2024-06-06 Thread Madhan Neethiraj (Jira)
Madhan Neethiraj created RANGER-4813:


 Summary: update audit UI to retrieve V2 trx log record
 Key: RANGER-4813
 URL: https://issues.apache.org/jira/browse/RANGER-4813
 Project: Ranger
  Issue Type: Sub-task
  Components: admin
Reporter: Madhan Neethiraj


Currently admin audit UI retrieves multiple V1 trx logs to gather details of an 
update (REST API: service/assets//report/\{transactionId}). This should be 
optimized to retrieve a single V2 trx log record (introduced in RANGER-4803) to 
render in UI. A new API should be added to retrieve V2 trx log record.



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


[jira] [Created] (RANGER-4812) database schema patch to create x_trx_log_v2 table

2024-06-06 Thread Madhan Neethiraj (Jira)
Madhan Neethiraj created RANGER-4812:


 Summary: database schema patch to create x_trx_log_v2 table
 Key: RANGER-4812
 URL: https://issues.apache.org/jira/browse/RANGER-4812
 Project: Ranger
  Issue Type: Sub-task
  Components: admin
Reporter: Madhan Neethiraj


RANGER-4803 introduced new table named x_trx_log_v2. A database schema patch 
will be needed to create x_trx_log_v2 table in existing Ranger deployments.



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


[jira] [Updated] (RANGER-4811) update Trino plugin code to be compliant with coding standards of Trino project

2024-06-06 Thread Madhan Neethiraj (Jira)


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

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

> update Trino plugin code to be compliant with coding standards of Trino 
> project
> ---
>
> Key: RANGER-4811
> URL: https://issues.apache.org/jira/browse/RANGER-4811
> Project: Ranger
>  Issue Type: Sub-task
>  Components: plugins
>Reporter: Madhan Neethiraj
>Assignee: Madhan Neethiraj
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: RANGER-4811.patch
>
>
> Trino project has several requirements for the code in Trino repo, including 
> placement of '{' in different contexts, ordering of items in pom.xml, use of 
> white spaces, and more. This Jira tracks preparing the Trino plugin 
> implementation to be compliant with coding standards of Trino project.



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


[jira] [Updated] (RANGER-4811) update Trino plugin code to be compliant with coding standards of Trino project

2024-06-06 Thread Madhan Neethiraj (Jira)


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

Madhan Neethiraj updated RANGER-4811:
-
Summary: update Trino plugin code to be compliant with coding standards of 
Trino project  (was: updated Trino plugin code to be compliant with coding 
standards for Trino project)

> update Trino plugin code to be compliant with coding standards of Trino 
> project
> ---
>
> Key: RANGER-4811
> URL: https://issues.apache.org/jira/browse/RANGER-4811
> Project: Ranger
>  Issue Type: Sub-task
>  Components: plugins
>Reporter: Madhan Neethiraj
>Assignee: Madhan Neethiraj
>Priority: Major
>
> Trino project has several requirements for the code in Trino repo, including 
> placement of '{' in different contexts, ordering of items in pom.xml, use of 
> white spaces, and more. This Jira tracks preparing the Trino plugin 
> implementation to be compliant with coding standards of Trino project.



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


[jira] [Created] (RANGER-4811) updated Trino plugin code to be compliant with coding standards for Trino project

2024-06-06 Thread Madhan Neethiraj (Jira)
Madhan Neethiraj created RANGER-4811:


 Summary: updated Trino plugin code to be compliant with coding 
standards for Trino project
 Key: RANGER-4811
 URL: https://issues.apache.org/jira/browse/RANGER-4811
 Project: Ranger
  Issue Type: Sub-task
  Components: plugins
Reporter: Madhan Neethiraj
Assignee: Madhan Neethiraj


Trino project has several requirements for the code in Trino repo, including 
placement of '{' in different contexts, ordering of items in pom.xml, use of 
white spaces, and more. This Jira tracks preparing the Trino plugin 
implementation to be compliant with coding standards of Trino project.



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


[jira] [Updated] (RANGER-4810) Move Trino authorizer implementation from Ranger git repo to Trino repo

2024-06-06 Thread Madhan Neethiraj (Jira)


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

Madhan Neethiraj updated RANGER-4810:
-
Description: 
Moving Trino authorizer implementation from Ranger git repo to Trino repo has 
several advantages, including:
 # Keeping the authorizer in sync with the updates in SystemAccessControl 
interface. For example, following changes in the latest Trino repo are not 
compatible with the Trino authorizer in Ranger repo:
 ## SystemAccessControl.checkCanAccessCatalog(): removed
 ## SystemAccessControl.getRowFilter(): replaced with getRowFilters()
 ## SystemAccessControl.getColumnMasks(): replaced with getColumnMask()
 ## SystemAccessControl.checkCanSetSystemSessionProperty(): removed
 ## SystemAccessControl.checkCanImpersonateUser(): signature changed
 ## SystemAccessControl.checkCanAccessCatalog(): removed
 ## SystemAccessControl.checkCanCreateSchema(): signature changed
 ## SystemAccessControl.checkCanExecuteQuery(): removed
 ## SystemAccessControl.checkCanViewQueryOwnedBy(): removed
 ## SystemAccessControl.filterViewQueryOwnedBy(): signature changed
 ## SystemAccessControl.checkCanKillQueryOwnedBy(): removed
 ## SystemAccessControl.checkCanGrantExecuteFunctionPrivilege(): 
removed/replaced
 ## SystemAccessControl.checkCanExecuteFunction(): signature changed
 ## ViewExpression(): constructor changed
 ## AccessDeniedException.denyGrantExecuteFunctionPrivilege(): removed
 # Trino requires more recent JDK versions (currently JDK 22) than Ranger repo 
(which still supports JDK 8). Trino authorizer is built separately, as a second 
phase, in Ranger repo using higher JDK versions. Moving the authorizer to Trino 
repo will avoid this additional step.

 

Trino seems to have a class loader isolation in place for its plugins, which 
can eliminate the need for the shim layer used in Ranger plugin. This needs to 
be considered along with this move.

Though the authorizer implementation would move to Trino repp, Ranger repo will 
continue to have modules used in Ranger admin server for resource look up and 
default policy creation (class RangerServiceTrino).

  was:
Moving Trino authorizer implementation from Ranger git repo to Trino repo has 
several advantages, including:
 # Keeping the authorizer in sync with the updates in SystemAccessControl 
interface. For example, following changes in the latest Trino repo are not 
compatible with the Trino authorizer in Ranger repo:
 ## SystemAccessControl.checkCanAccessCatalog(): removed
 ## 
SystemAccessControl.getRowFilter(): replaced with getRowFilters()
 ## 
 SystemAccessControl.getColumnMasks(): replaced with getColumnMask()
 ## 
SystemAccessControl.checkCanSetSystemSessionProperty(): removed
 ## 
SystemAccessControl.checkCanImpersonateUser(): signature changed
 ## 
SystemAccessControl.checkCanAccessCatalog(): removed
 ## SystemAccessControl.checkCanCreateSchema(): signature changed
 ## 
SystemAccessControl.checkCanExecuteQuery(): removed
 ## 
SystemAccessControl.checkCanViewQueryOwnedBy(): removed
 ## 
SystemAccessControl.filterViewQueryOwnedBy(): signature changed
 ## 
SystemAccessControl.checkCanKillQueryOwnedBy(): removed
 ## 
SystemAccessControl.checkCanGrantExecuteFunctionPrivilege(): removed/replaced
 ## 
SystemAccessControl.checkCanExecuteFunction(): signature changed
 ## 
ViewExpression(): constructor changed
 ## 
AccessDeniedException.denyGrantExecuteFunctionPrivilege(): removed
 # Trino requires more recent JDK versions (currently JDK 22) than Ranger repo 
(which still supports JDK 8). Trino authorizer is built separately, as a second 
phase, in Ranger repo using higher JDK versions. Moving the authorizer to Trino 
repo will avoid this additional step.

 

Trino seems to have a class loader isolation in place for its plugins, which 
can eliminate the need for the shim layer used in Ranger plugin. This needs to 
be considered along with this move.

Though the authorizer implementation would move to Trino repp, Ranger repo will 
continue to have modules used in Ranger admin server for resource look up and 
default policy creation (class RangerServiceTrino).


> Move Trino authorizer implementation from Ranger git repo to Trino repo
> ---
>
> Key: RANGER-4810
> URL: https://issues.apache.org/jira/browse/RANGER-4810
> Project: Ranger
>  Issue Type: Improvement
>  Components: plugins
>Reporter: Madhan Neethiraj
>Assignee: Madhan Neethiraj
>Priority: Major
>
> Moving Trino authorizer implementation from Ranger git repo to Trino repo has 
> several advantages, including:
>  # Keeping the authorizer in sync with the updates in SystemAccessControl 
> interface. For example, following changes in the latest Trino repo are not 
> 

[jira] [Created] (RANGER-4810) Move Trino authorizer implementation from Ranger git repo to Trino repo

2024-06-06 Thread Madhan Neethiraj (Jira)
Madhan Neethiraj created RANGER-4810:


 Summary: Move Trino authorizer implementation from Ranger git repo 
to Trino repo
 Key: RANGER-4810
 URL: https://issues.apache.org/jira/browse/RANGER-4810
 Project: Ranger
  Issue Type: Improvement
  Components: plugins
Reporter: Madhan Neethiraj
Assignee: Madhan Neethiraj


Moving Trino authorizer implementation from Ranger git repo to Trino repo has 
several advantages, including:
 # Keeping the authorizer in sync with the updates in SystemAccessControl 
interface. For example, following changes in the latest Trino repo are not 
compatible with the Trino authorizer in Ranger repo:
 ## SystemAccessControl.checkCanAccessCatalog(): removed
 ## 
SystemAccessControl.getRowFilter(): replaced with getRowFilters()
 ## 
 SystemAccessControl.getColumnMasks(): replaced with getColumnMask()
 ## 
SystemAccessControl.checkCanSetSystemSessionProperty(): removed
 ## 
SystemAccessControl.checkCanImpersonateUser(): signature changed
 ## 
SystemAccessControl.checkCanAccessCatalog(): removed
 ## SystemAccessControl.checkCanCreateSchema(): signature changed
 ## 
SystemAccessControl.checkCanExecuteQuery(): removed
 ## 
SystemAccessControl.checkCanViewQueryOwnedBy(): removed
 ## 
SystemAccessControl.filterViewQueryOwnedBy(): signature changed
 ## 
SystemAccessControl.checkCanKillQueryOwnedBy(): removed
 ## 
SystemAccessControl.checkCanGrantExecuteFunctionPrivilege(): removed/replaced
 ## 
SystemAccessControl.checkCanExecuteFunction(): signature changed
 ## 
ViewExpression(): constructor changed
 ## 
AccessDeniedException.denyGrantExecuteFunctionPrivilege(): removed
 # Trino requires more recent JDK versions (currently JDK 22) than Ranger repo 
(which still supports JDK 8). Trino authorizer is built separately, as a second 
phase, in Ranger repo using higher JDK versions. Moving the authorizer to Trino 
repo will avoid this additional step.

 

Trino seems to have a class loader isolation in place for its plugins, which 
can eliminate the need for the shim layer used in Ranger plugin. This needs to 
be considered along with this move.

Though the authorizer implementation would move to Trino repp, Ranger repo will 
continue to have modules used in Ranger admin server for resource look up and 
default policy creation (class RangerServiceTrino).



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


[jira] [Commented] (RANGER-4774) Ranger react UI some modules shown hardcoded time zone string "Indian Standard Time"

2024-06-06 Thread Dhaval Rajpara (Jira)


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

Dhaval Rajpara commented on RANGER-4774:


Patch committed to [Apache 
master|https://github.com/apache/ranger/commit/65fad025d908b280440dbca4c7a61de3fa8ef943]
 branch.

> Ranger react UI some modules shown hardcoded  time zone string "Indian 
> Standard Time"
> -
>
> Key: RANGER-4774
> URL: https://issues.apache.org/jira/browse/RANGER-4774
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Reporter: Dhaval Rajpara
>Assignee: Dhaval Rajpara
>Priority: Major
> Attachments: 0001-RANGER-4774.patch
>
>
> 1) UI popup showing details of an admin audit log seems to have hardcoded 
> string “Indian Standard Time” 
> 2)Some logs table header also have hardcoded string “Indian Standard Time” 



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


[jira] [Updated] (RANGER-4774) Ranger react UI some modules shown hardcoded time zone string "Indian Standard Time"

2024-06-06 Thread Dhaval Rajpara (Jira)


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

Dhaval Rajpara updated RANGER-4774:
---
Fix Version/s: 3.0.0

> Ranger react UI some modules shown hardcoded  time zone string "Indian 
> Standard Time"
> -
>
> Key: RANGER-4774
> URL: https://issues.apache.org/jira/browse/RANGER-4774
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Reporter: Dhaval Rajpara
>Assignee: Dhaval Rajpara
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: 0001-RANGER-4774.patch
>
>
> 1) UI popup showing details of an admin audit log seems to have hardcoded 
> string “Indian Standard Time” 
> 2)Some logs table header also have hardcoded string “Indian Standard Time” 



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


[jira] [Resolved] (RANGER-4744) Ranger Admin startup using JDK17 gives ERROR in catalina.out due to missing jaxb dependencies

2024-06-06 Thread Rakesh Gupta (Jira)


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

Rakesh Gupta resolved RANGER-4744.
--
Resolution: Duplicate

> Ranger Admin startup using JDK17 gives ERROR in catalina.out due to missing 
> jaxb dependencies
> -
>
> Key: RANGER-4744
> URL: https://issues.apache.org/jira/browse/RANGER-4744
> Project: Ranger
>  Issue Type: Task
>  Components: Ranger
>Reporter: Rakesh Gupta
>Assignee: Rakesh Gupta
>Priority: Major
>
> 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.



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


[jira] [Commented] (RANGER-3409) Update Jackson and remove Codehaus version

2024-06-04 Thread Nikita Blagodarnyi (Jira)


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

Nikita Blagodarnyi commented on RANGER-3409:


[~bpatel] [~sercan.tekin] Regarding to your questions about how it works for 
me. Please refer to the provided video 
[https://disk.yandex.ru/i/9W5byQJLIgwFbQ]  , password is _rangerR0cks!_
I've recorded full build process from scratch and tried to reproduce users and 
policy issues described above. Video can be downloaded if quality is poor 
directly in browser. 

P.S. [~sercan.tekin] sorry, I'm new to oss-world. My github username is 
nblagodarnyi and primary e-mail is nb...@mail.ru

> Update Jackson and remove Codehaus version
> --
>
> Key: RANGER-3409
> URL: https://issues.apache.org/jira/browse/RANGER-3409
> Project: Ranger
>  Issue Type: Improvement
>  Components: Ranger
>Affects Versions: 3.0.0
>Reporter: Andrew Charneski
>Priority: Blocker
> Attachments: ranger-modify-policy.png
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> An old version of Jackson (Codehaus Jackson 1.9.13) is still being used. 
> Jackson has since moved namespaces with a reorganized library structure. 
> Update all references to the older version to use the newer version (which is 
> currently used in some modules).



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


[jira] [Updated] (RANGER-4804) Encountering a '404 Not Found' page when assigning two or more groups to a user during editing

2024-05-31 Thread kiran chormare (Jira)


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

kiran chormare updated RANGER-4804:
---
Attachment: react_ui.png
backbon_ui.png

> Encountering a '404 Not Found' page when assigning two or more groups to a 
> user during editing
> --
>
> Key: RANGER-4804
> URL: https://issues.apache.org/jira/browse/RANGER-4804
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Reporter: kiran chormare
>Assignee: Rakesh Gupta
>Priority: Major
> Attachments: backbon_ui.png, react_ui.png
>
>
> We are encountering an issue where a '404 Not Found' page is displayed when 
> attempting to assign two or more groups to a user during the editing process.
> Steps to Reproduce:
> 1. Navigate to Settings > Users.
> 2. Click on a USER to edit.
> 3. In the Groups dropdown, select two or more groups.
> 4. Click the Save button.
> Expected Result:
> The user should be updated with the selected groups
> Actual Result:
> '404 Not Found' page is displayed
> Error log:
> {code:java}
> com.sun.jersey.spi.container.ContainerResponse mapMappableContainerException
> SEVERE: The RuntimeException could not be mapped to a response, re-throwing 
> to the HTTP container
> java.lang.NullPointerException
>   at java.util.ArrayList.addAll(ArrayList.java:583)
>   at 
> org.apache.ranger.biz.XUserMgr.createOrDelGrpUserWithUpdatedGrpId(XUserMgr.java:553)
>   at org.apache.ranger.biz.XUserMgr.updateXUser(XUserMgr.java:511)
>   at 
> org.apache.ranger.biz.XUserMgr$$FastClassBySpringCGLIB$$57c6d473.invoke()
>   at 
> org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:218)
>   at 
> org.springframework.aop.framework.CglibAopProxy.invokeMethod(CglibAopProxy.java:386)
>   at 
> org.springframework.aop.framework.CglibAopProxy.access$000(CglibAopProxy.java:85)
>   at 
> org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:703)
>   at 
> org.apache.ranger.biz.XUserMgr$$EnhancerBySpringCGLIB$$41afd89a.updateXUser()
>   at 
> org.apache.ranger.rest.XUserREST.secureUpdateXUser(XUserREST.java:359)
>   at 
> org.apache.ranger.rest.XUserREST$$FastClassBySpringCGLIB$$b2a65360.invoke()
>   at 
> org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:218)
>   at 
> org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:792)
>   at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:163)
>   at 
> org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.proceed(CglibAopProxy.java:762)
>   at 
> org.springframework.transaction.interceptor.TransactionInterceptor$1.proceedWithInvocation(TransactionInterceptor.java:123)
>   at 
> org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:388)
>   at 
> org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:119)
>   at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186)
>   at 
> org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.proceed(CglibAopProxy.java:762)
>   at 
> org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:707)
>   at 
> org.apache.ranger.rest.XUserREST$$EnhancerBySpringCGLIB$$71c3ea38.secureUpdateXUser()
>   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 
> com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
>   at 
> com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$TypeOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:185)
>   at 
> com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
>   at 
> com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:302)
>   at 
> com.sun.jersey.server.i

[jira] [Commented] (RANGER-4804) Encountering a '404 Not Found' page when assigning two or more groups to a user during editing

2024-05-31 Thread kiran chormare (Jira)


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

kiran chormare commented on RANGER-4804:


While testing this patch, I Found some bugs. Here are the steps to reproduce 
them:

Steps
1. Navigate to Settings > Users.
2. Add a new user named "test1" with one group "group1".
3. Update the user "test1" by adding another group "group2".
4. Navigate to Audits > Admin
5. Click on the log entry for the operation "User updated test1".
6. Observe the displayed data.

Observations:
1. The transaction log only shows the update for group2. It doesn't show any 
log for group1 because the previousValue and newValue for group1 are the same.
2. In previousValue and newValue the values are populated based on group_id 
however it should be show group name. 

Note - On Ranger UI:
   - For React UI, it shows the group_id.
   - For Backbone UI, it shows the group_name.

> Encountering a '404 Not Found' page when assigning two or more groups to a 
> user during editing
> --
>
> Key: RANGER-4804
> URL: https://issues.apache.org/jira/browse/RANGER-4804
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Reporter: kiran chormare
>Assignee: Rakesh Gupta
>Priority: Major
>
> We are encountering an issue where a '404 Not Found' page is displayed when 
> attempting to assign two or more groups to a user during the editing process.
> Steps to Reproduce:
> 1. Navigate to Settings > Users.
> 2. Click on a USER to edit.
> 3. In the Groups dropdown, select two or more groups.
> 4. Click the Save button.
> Expected Result:
> The user should be updated with the selected groups
> Actual Result:
> '404 Not Found' page is displayed
> Error log:
> {code:java}
> com.sun.jersey.spi.container.ContainerResponse mapMappableContainerException
> SEVERE: The RuntimeException could not be mapped to a response, re-throwing 
> to the HTTP container
> java.lang.NullPointerException
>   at java.util.ArrayList.addAll(ArrayList.java:583)
>   at 
> org.apache.ranger.biz.XUserMgr.createOrDelGrpUserWithUpdatedGrpId(XUserMgr.java:553)
>   at org.apache.ranger.biz.XUserMgr.updateXUser(XUserMgr.java:511)
>   at 
> org.apache.ranger.biz.XUserMgr$$FastClassBySpringCGLIB$$57c6d473.invoke()
>   at 
> org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:218)
>   at 
> org.springframework.aop.framework.CglibAopProxy.invokeMethod(CglibAopProxy.java:386)
>   at 
> org.springframework.aop.framework.CglibAopProxy.access$000(CglibAopProxy.java:85)
>   at 
> org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:703)
>   at 
> org.apache.ranger.biz.XUserMgr$$EnhancerBySpringCGLIB$$41afd89a.updateXUser()
>   at 
> org.apache.ranger.rest.XUserREST.secureUpdateXUser(XUserREST.java:359)
>   at 
> org.apache.ranger.rest.XUserREST$$FastClassBySpringCGLIB$$b2a65360.invoke()
>   at 
> org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:218)
>   at 
> org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:792)
>   at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:163)
>   at 
> org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.proceed(CglibAopProxy.java:762)
>   at 
> org.springframework.transaction.interceptor.TransactionInterceptor$1.proceedWithInvocation(TransactionInterceptor.java:123)
>   at 
> org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:388)
>   at 
> org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:119)
>   at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186)
>   at 
> org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.proceed(CglibAopProxy.java:762)
>   at 
> org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:707)
>   at 
> org.apache.ranger.rest.XUserREST$$EnhancerBySpringCGLIB$$71c3ea38.secureUpdateXUser()
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccesso

[jira] [Created] (RANGER-4809) Utility to migrate admin audit logs in x_trx_log table x_trx_log_v2 table

2024-05-30 Thread Madhan Neethiraj (Jira)
Madhan Neethiraj created RANGER-4809:


 Summary: Utility to migrate admin audit logs in x_trx_log table 
x_trx_log_v2 table
 Key: RANGER-4809
 URL: https://issues.apache.org/jira/browse/RANGER-4809
 Project: Ranger
  Issue Type: Sub-task
  Components: admin
Reporter: Madhan Neethiraj


With updates in RANGER-4803, Ranger will store admin audit records in 
{{x_trx_log_v2}} table. Prior to this, {{x_trx_log}} table was used to store 
these records. To make earlier admin audits available to updated Ranger, 
existing entries in {{x_trx_log}} should be migrated to {{x_trx_log_v2}} table. 
Here are few notes to take into account:
 # For a given admin action, like create/update/delete of a policy, multiple 
rows are created in {{x_trx_log}} table - one row for each updated attribute.
 # For a given admin action, a single row is created in {{x_trx_log_v2}}
 table. This row captures details of all updated attributes in json format.
 # Migration utility should merge all rows for a given admin action, identified 
by column {{x_trx_log.trx_id}}, into a single record in {{x_trx_log_v2}} table. 
{{x_trx_log_v2.change_info}} column should be populated with contents of 
following columns in multiple {{x_trx_log}} rows: {{attr_name}}, {{prev_val}}, 
{{new_val}}.
# The utility should provide an option to migrate only a subset of entries in 
{{x_trx_log}} table - for example, for a given time period (last 3 months, last 
1 year). This will help avoid migrating older records that are of no interest 
to the customer.



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


[jira] [Updated] (RANGER-4804) Encountering a '404 Not Found' page when assigning two or more groups to a user during editing

2024-05-30 Thread Rakesh Gupta (Jira)


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

Rakesh Gupta updated RANGER-4804:
-
Description: 
We are encountering an issue where a '404 Not Found' page is displayed when 
attempting to assign two or more groups to a user during the editing process.

Steps to Reproduce:
1. Navigate to Settings > Users.
2. Click on a USER to edit.
3. In the Groups dropdown, select two or more groups.
4. Click the Save button.

Expected Result:
The user should be updated with the selected groups

Actual Result:
'404 Not Found' page is displayed

Error log:
{code:java}
com.sun.jersey.spi.container.ContainerResponse mapMappableContainerException
SEVERE: The RuntimeException could not be mapped to a response, re-throwing to 
the HTTP container
java.lang.NullPointerException
at java.util.ArrayList.addAll(ArrayList.java:583)
at 
org.apache.ranger.biz.XUserMgr.createOrDelGrpUserWithUpdatedGrpId(XUserMgr.java:553)
at org.apache.ranger.biz.XUserMgr.updateXUser(XUserMgr.java:511)
at 
org.apache.ranger.biz.XUserMgr$$FastClassBySpringCGLIB$$57c6d473.invoke()
at 
org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:218)
at 
org.springframework.aop.framework.CglibAopProxy.invokeMethod(CglibAopProxy.java:386)
at 
org.springframework.aop.framework.CglibAopProxy.access$000(CglibAopProxy.java:85)
at 
org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:703)
at 
org.apache.ranger.biz.XUserMgr$$EnhancerBySpringCGLIB$$41afd89a.updateXUser()
at 
org.apache.ranger.rest.XUserREST.secureUpdateXUser(XUserREST.java:359)
at 
org.apache.ranger.rest.XUserREST$$FastClassBySpringCGLIB$$b2a65360.invoke()
at 
org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:218)
at 
org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:792)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:163)
at 
org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.proceed(CglibAopProxy.java:762)
at 
org.springframework.transaction.interceptor.TransactionInterceptor$1.proceedWithInvocation(TransactionInterceptor.java:123)
at 
org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:388)
at 
org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:119)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186)
at 
org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.proceed(CglibAopProxy.java:762)
at 
org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:707)
at 
org.apache.ranger.rest.XUserREST$$EnhancerBySpringCGLIB$$71c3ea38.secureUpdateXUser()
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 
com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
at 
com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$TypeOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:185)
at 
com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
at 
com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:302)
at 
com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
at 
com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:108)
at 
com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
at 
com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
at 
com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1542)
at 
com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1473)
at 
com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1419)
at 
com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1409)
at 
com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:

[jira] [Updated] (RANGER-4804) Encountering a '404 Not Found' page when assigning two or more groups to a user during editing

2024-05-30 Thread Rakesh Gupta (Jira)


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

Rakesh Gupta updated RANGER-4804:
-
Description: 
We are encountering an issue where a '404 Not Found' page is displayed when 
attempting to assign two or more groups to a user during the editing process.

Steps to Reproduce:
1. Navigate to Settings > Users.
2. Click on a USER to edit.
3. In the Groups dropdown, select two or more groups.
4. Click the Save button.

Expected Result:
The user should be updated with the selected groups

Actual Result:
'404 Not Found' page is displayed

Error log:
{code:java}



{code}

  was:
We are encountering an issue where a '404 Not Found' page is displayed when 
attempting to assign two or more groups to a user during the editing process.

Steps to Reproduce:
1. Navigate to Settings > Users.
2. Click on a USER to edit.
3. In the Groups dropdown, select two or more groups.
4. Click the Save button.

Expected Result:
The user should be updated with the selected groups

Actual Result:
'404 Not Found' page is displayed


> Encountering a '404 Not Found' page when assigning two or more groups to a 
> user during editing
> --
>
> Key: RANGER-4804
> URL: https://issues.apache.org/jira/browse/RANGER-4804
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Reporter: kiran chormare
>Assignee: Rakesh Gupta
>Priority: Major
>
> We are encountering an issue where a '404 Not Found' page is displayed when 
> attempting to assign two or more groups to a user during the editing process.
> Steps to Reproduce:
> 1. Navigate to Settings > Users.
> 2. Click on a USER to edit.
> 3. In the Groups dropdown, select two or more groups.
> 4. Click the Save button.
> Expected Result:
> The user should be updated with the selected groups
> Actual Result:
> '404 Not Found' page is displayed
> Error log:
> {code:java}
> {code}



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


[jira] [Assigned] (RANGER-4804) Encountering a '404 Not Found' page when assigning two or more groups to a user during editing

2024-05-29 Thread Rakesh Gupta (Jira)


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

Rakesh Gupta reassigned RANGER-4804:


Assignee: Rakesh Gupta

> Encountering a '404 Not Found' page when assigning two or more groups to a 
> user during editing
> --
>
> Key: RANGER-4804
> URL: https://issues.apache.org/jira/browse/RANGER-4804
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Reporter: kiran chormare
>Assignee: Rakesh Gupta
>Priority: Major
>
> We are encountering an issue where a '404 Not Found' page is displayed when 
> attempting to assign two or more groups to a user during the editing process.
> Steps to Reproduce:
> 1. Navigate to Settings > Users.
> 2. Click on a USER to edit.
> 3. In the Groups dropdown, select two or more groups.
> 4. Click the Save button.
> Expected Result:
> The user should be updated with the selected groups
> Actual Result:
> '404 Not Found' page is displayed



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


[jira] [Commented] (RANGER-4804) Encountering a '404 Not Found' page when assigning two or more groups to a user during editing

2024-05-29 Thread Madhan Neethiraj (Jira)


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

Madhan Neethiraj commented on RANGER-4804:
--

[~kiranchormare]  - can you please add corresponding error logs from Ranger 
admin server log file?

> Encountering a '404 Not Found' page when assigning two or more groups to a 
> user during editing
> --
>
> Key: RANGER-4804
> URL: https://issues.apache.org/jira/browse/RANGER-4804
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Reporter: kiran chormare
>Priority: Major
>
> We are encountering an issue where a '404 Not Found' page is displayed when 
> attempting to assign two or more groups to a user during the editing process.
> Steps to Reproduce:
> 1. Navigate to Settings > Users.
> 2. Click on a USER to edit.
> 3. In the Groups dropdown, select two or more groups.
> 4. Click the Save button.
> Expected Result:
> The user should be updated with the selected groups
> Actual Result:
> '404 Not Found' page is displayed



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


[jira] [Created] (RANGER-4808) Enhance KafkaAuditProvider for Audit V3

2024-05-29 Thread woosuk.ro (Jira)
woosuk.ro created RANGER-4808:
-

 Summary: Enhance KafkaAuditProvider for Audit V3
 Key: RANGER-4808
 URL: https://issues.apache.org/jira/browse/RANGER-4808
 Project: Ranger
  Issue Type: Improvement
  Components: audit
Reporter: woosuk.ro
 Fix For: 2.4.0, 2.3.0


In the current implementation of Audit V3 in Impala, the KafkaAuditProvider was 
not properly initialized due to the absence of the init(Properties props, 
String basePropertyName) function. Additionally, the existing implementation 
relied on Kafka Client version 0.8.0, which made it difficult to use

This issue proposes the following enhancements to the KafkaAuditProvider for 
better integration and functionality:

1. Implement the init(Properties props, String basePropertyName) method to 
properly initialize the KafkaAuditProvider when using Audit V3.

2. Dynamic Configuration: Modify the KafkaAuditProvider to dynamically set the 
configuration values for the Kafka Producer during its creation. 

This enhancement allows for more flexible and customizable configurations based 
on the properties provided. These improvements ensure that the 
KafkaAuditProvider works seamlessly with the latest Kafka clients and supports 
dynamic configuration, enhancing the overall audit logging capability in Impala.



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


[jira] [Commented] (RANGER-4807) Upgrade Hadoop to 3.3.3

2024-05-29 Thread wangzhongwei (Jira)


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

wangzhongwei commented on RANGER-4807:
--

review board:https://reviews.apache.org/r/75017/

> Upgrade Hadoop to 3.3.3
> ---
>
> Key: RANGER-4807
> URL: https://issues.apache.org/jira/browse/RANGER-4807
> Project: Ranger
>  Issue Type: Bug
>  Components: admin, plugins, usersync
>Affects Versions: 2.2.0, 2.3.0, 2.4.0
>Reporter: wangzhongwei
>Assignee: wangzhongwei
>Priority: Major
> Attachments: RANGER-4807.patch
>
>
>  Upgrade Hadoop3.3.0 to 3.3.3 to fix 
> https://nvd.nist.gov/vuln/detail/CVE-2022-25168 



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


[jira] [Updated] (RANGER-4807) Upgrade Hadoop to 3.3.3

2024-05-29 Thread wangzhongwei (Jira)


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

wangzhongwei updated RANGER-4807:
-
Attachment: RANGER-4807.patch

> Upgrade Hadoop to 3.3.3
> ---
>
> Key: RANGER-4807
> URL: https://issues.apache.org/jira/browse/RANGER-4807
> Project: Ranger
>  Issue Type: Bug
>  Components: admin, plugins, usersync
>Affects Versions: 2.2.0, 2.3.0, 2.4.0
>Reporter: wangzhongwei
>Assignee: wangzhongwei
>Priority: Major
> Attachments: RANGER-4807.patch
>
>
>  Upgrade Hadoop3.3.0 to 3.3.3 to fix 
> https://nvd.nist.gov/vuln/detail/CVE-2022-25168 



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


[jira] [Created] (RANGER-4807) Upgrade Hadoop to 3.3.3

2024-05-29 Thread wangzhongwei (Jira)
wangzhongwei created RANGER-4807:


 Summary: Upgrade Hadoop to 3.3.3
 Key: RANGER-4807
 URL: https://issues.apache.org/jira/browse/RANGER-4807
 Project: Ranger
  Issue Type: Bug
  Components: admin, plugins, usersync
Affects Versions: 2.4.0, 2.3.0, 2.2.0
Reporter: wangzhongwei
Assignee: wangzhongwei


 Upgrade Hadoop3.3.0 to 3.3.3 to fix 
https://nvd.nist.gov/vuln/detail/CVE-2022-25168 



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


[jira] [Comment Edited] (RANGER-4795) Add validation in API to check emptyness on policyitem while creating policy.

2024-05-28 Thread Vishal Bhavsar (Jira)


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

Vishal Bhavsar edited comment on RANGER-4795 at 5/29/24 5:14 AM:
-

We are able to create Mask & Row level policy with empty value i.e "" for 
user/group/role in policy item.

Steps to reproduce:
 # From Postman hit Post api : 
[http://localhost:6080/service/plugins/policies|http://10.140.31.0:6080/service/plugins/policies]
 ; use below json as payload for creating row policy.

{code:java}
{ "allowExceptions": [], "policyItems": [], "denyPolicyItems": [], 
"denyExceptions": [], "dataMaskPolicyItems": [], "rowFilterPolicyItems": [ { 
"accesses": [ { "type": "select", "isAllowed": true } ], "users": [ "" ], 
"groups": [ "" ], "roles": [ "" ], "rowFilterInfo": { "filterExpr": "a=b" } } 
], "description": "", "isAuditEnabled": true, "isDenyAllElse": false, 
"isEnabled": true, "name": "hvr p2", "policyLabels": [], "policyPriority": "0", 
"policyType": "2", "service": "hive1", "resources": { "database": { "values": [ 
"db2" ] }, "table": { "values": [ "tbl1" ] } }, "additionalResources": [], 
"conditions": [] }{code}


was (Author: JIRAUSER298660):
We are able to create Mask & Row level policy with empty value i.e "" for 
user/group/role in policy item.

Steps to reproduce:
 # From Postman hit Post api : 
[http://10.140.31.0:6080/service/plugins/policies] ; use below json as payload 
for creating row policy.

{code:java}
{ "allowExceptions": [], "policyItems": [], "denyPolicyItems": [], 
"denyExceptions": [], "dataMaskPolicyItems": [], "rowFilterPolicyItems": [ { 
"accesses": [ { "type": "select", "isAllowed": true } ], "users": [ "" ], 
"groups": [ "" ], "roles": [ "" ], "rowFilterInfo": { "filterExpr": "a=b" } } 
], "description": "", "isAuditEnabled": true, "isDenyAllElse": false, 
"isEnabled": true, "name": "hvr p2", "policyLabels": [], "policyPriority": "0", 
"policyType": "2", "service": "hive1", "resources": { "database": { "values": [ 
"db2" ] }, "table": { "values": [ "tbl1" ] } }, "additionalResources": [], 
"conditions": [] }{code}

> Add validation in API to check emptyness on policyitem while creating policy.
> -
>
> Key: RANGER-4795
> URL: https://issues.apache.org/jira/browse/RANGER-4795
> Project: Ranger
>  Issue Type: Task
>  Components: Ranger
>Reporter: Rakesh Gupta
>Assignee: Rakesh Gupta
>Priority: Major
>
> There is an inconsistency between Ranger API and UI not doing the same 
> validation for Policy creation. 
> Policy creation API should fail when a policy with all empty values and along 
> with  [""]  or  ["null"] in policyItem --> users, groups and roles.



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


[jira] [Comment Edited] (RANGER-4795) Add validation in API to check emptyness on policyitem while creating policy.

2024-05-28 Thread Vishal Bhavsar (Jira)


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

Vishal Bhavsar edited comment on RANGER-4795 at 5/28/24 12:28 PM:
--

We are able to create Mask & Row level policy with empty value i.e "" for 
user/group/role in policy item.

Steps to reproduce:
 # From Postman hit Post api : 
[http://10.140.31.0:6080/service/plugins/policies] ; use below json as payload 
for creating row policy.

{code:java}
{ "allowExceptions": [], "policyItems": [], "denyPolicyItems": [], 
"denyExceptions": [], "dataMaskPolicyItems": [], "rowFilterPolicyItems": [ { 
"accesses": [ { "type": "select", "isAllowed": true } ], "users": [ "" ], 
"groups": [ "" ], "roles": [ "" ], "rowFilterInfo": { "filterExpr": "a=b" } } 
], "description": "", "isAuditEnabled": true, "isDenyAllElse": false, 
"isEnabled": true, "name": "hvr p2", "policyLabels": [], "policyPriority": "0", 
"policyType": "2", "service": "hive1", "resources": { "database": { "values": [ 
"db2" ] }, "table": { "values": [ "tbl1" ] } }, "additionalResources": [], 
"conditions": [] }{code}


was (Author: JIRAUSER298660):
We are able to create Mask & Row level policy with empty value i.e "" for 
user/group/role.

 

Steps to reproduce:
 # From Postman hit Post api : 
[http://10.140.31.0:6080/service/plugins/policies] ; use below json as payload

> Add validation in API to check emptyness on policyitem while creating policy.
> -
>
> Key: RANGER-4795
> URL: https://issues.apache.org/jira/browse/RANGER-4795
> Project: Ranger
>  Issue Type: Task
>  Components: Ranger
>Reporter: Rakesh Gupta
>Assignee: Rakesh Gupta
>Priority: Major
>
> There is an inconsistency between Ranger API and UI not doing the same 
> validation for Policy creation. 
> Policy creation API should fail when a policy with all empty values and along 
> with  [""]  or  ["null"] in policyItem --> users, groups and roles.



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


[jira] [Commented] (RANGER-4795) Add validation in API to check emptyness on policyitem while creating policy.

2024-05-28 Thread Vishal Bhavsar (Jira)


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

Vishal Bhavsar commented on RANGER-4795:


We are able to create Mask & Row level policy with empty value i.e "" for 
user/group/role.

 

Steps to reproduce:
 # From Postman hit Post api : 
[http://10.140.31.0:6080/service/plugins/policies] ; use below json as payload

> Add validation in API to check emptyness on policyitem while creating policy.
> -
>
> Key: RANGER-4795
> URL: https://issues.apache.org/jira/browse/RANGER-4795
> Project: Ranger
>  Issue Type: Task
>  Components: Ranger
>Reporter: Rakesh Gupta
>Assignee: Rakesh Gupta
>Priority: Major
>
> There is an inconsistency between Ranger API and UI not doing the same 
> validation for Policy creation. 
> Policy creation API should fail when a policy with all empty values and along 
> with  [""]  or  ["null"] in policyItem --> users, groups and roles.



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


[jira] [Updated] (RANGER-4806) With java 17 the audit spool exception is seen if solr is not reachable.

2024-05-28 Thread Monika kachhadiya (Jira)


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

Monika kachhadiya updated RANGER-4806:
--
Description: 
With java 17 the audit spool exception is seen if solr is not reachable. 
 
{code:java}
 
 ERROR AuditFileSpool: Error writing to file. event=AuthzAuditEvent
com.google.gson.JsonIOException: Failed making field 
'java.nio.charset.Charset#name' accessible; either increase its visibility or 
write a custom TypeAdapter for its declaring type.
at 
com.google.gson.internal.reflect.ReflectionHelper.makeAccessible(ReflectionHelper.java:38)
 ~[gson-2.10.1.jar:?]
at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.getBoundFields(ReflectiveTypeAdapterFactory.java:286)
 ~[gson-2.10.1.jar:?]
at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.create(ReflectiveTypeAdapterFactory.java:130)
 ~[gson-2.10.1.jar:?]
at com.google.gson.Gson.getAdapter(Gson.java:556) ~[gson-2.10.1.jar:?]
at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.createBoundField(ReflectiveTypeAdapterFactory.java:160)
 ~[gson-2.10.1.jar:?]
at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.getBoundFields(ReflectiveTypeAdapterFactory.java:294)
 ~[gson-2.10.1.jar:?]
at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.create(ReflectiveTypeAdapterFactory.java:130)
 ~[gson-2.10.1.jar:?]
at com.google.gson.Gson.getAdapter(Gson.java:556) ~[gson-2.10.1.jar:?]
at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.createBoundField(ReflectiveTypeAdapterFactory.java:160)
 ~[gson-2.10.1.jar:?]
at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.getBoundFields(ReflectiveTypeAdapterFactory.java:294)
 ~[gson-2.10.1.jar:?]
at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.create(ReflectiveTypeAdapterFactory.java:130)
 ~[gson-2.10.1.jar:?]
at com.google.gson.Gson.getAdapter(Gson.java:556) ~[gson-2.10.1.jar:?]
at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.createBoundField(ReflectiveTypeAdapterFactory.java:160)
 ~[gson-2.10.1.jar:?]
at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.getBoundFields(ReflectiveTypeAdapterFactory.java:294)
 ~[gson-2.10.1.jar:?]
at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.create(ReflectiveTypeAdapterFactory.java:130)
 ~[gson-2.10.1.jar:?]
at com.google.gson.Gson.getAdapter(Gson.java:556) ~[gson-2.10.1.jar:?]
at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.createBoundField(ReflectiveTypeAdapterFactory.java:160)
 ~[gson-2.10.1.jar:?]
at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.getBoundFields(ReflectiveTypeAdapterFactory.java:294)
 ~[gson-2.10.1.jar:?]
at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.create(ReflectiveTypeAdapterFactory.java:130)
 ~[gson-2.10.1.jar:?]
at com.google.gson.Gson.getAdapter(Gson.java:556) ~[gson-2.10.1.jar:?]
at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.createBoundField(ReflectiveTypeAdapterFactory.java:160)
 ~[gson-2.10.1.jar:?]
at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.getBoundFields(ReflectiveTypeAdapterFactory.java:294)
 ~[gson-2.10.1.jar:?]
at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.create(ReflectiveTypeAdapterFactory.java:130)
 ~[gson-2.10.1.jar:?]
at com.google.gson.Gson.getAdapter(Gson.java:556) ~[gson-2.10.1.jar:?]
at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.createBoundField(ReflectiveTypeAdapterFactory.java:160)
 ~[gson-2.10.1.jar:?]
at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.getBoundFields(ReflectiveTypeAdapterFactory.java:294)
 ~[gson-2.10.1.jar:?]
at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.create(ReflectiveTypeAdapterFactory.java:130)
 ~[gson-2.10.1.jar:?]
at com.google.gson.Gson.getAdapter(Gson.java:556) ~[gson-2.10.1.jar:?]
at com.google.gson.Gson.toJson(Gson.java:834) ~[gson-2.10.1.jar:?]
at com.google.gson.Gson.toJson(Gson.java:812) ~[gson-2.10.1.jar:?]
at com.google.gson.Gson.toJson(Gson.java:759) ~[gson-2.10.1.jar:?]
at com.google.gson.Gson.toJson(Gson.java:736) ~[gson-2.10.1.jar:?]
at 
org.apache.ranger.audit.queue.AuditFileSpool.saveIndexFile(AuditFileSpool.java) 
~[ranger-plugins-audit-10.22.0.2.jar:10.22.0.2]
at 
org.apache.ranger.audit.queue.AuditFileSpool.getLogFileStream(AuditFileSpool.java)
 ~[ranger-plugins-audit-10.22.0.2.jar:10.22.0.2]
at org.apache.ranger.audit.queue.AuditFileSpool.stashLogs(AuditFileSpool.java) 
[ranger-plugins-audit-10.22.0.2.jar:10.22.0.2]
at org.apache.ranger.audit.queue.AuditFileSpool.stashLogs(AuditFileSpool.java) 
[ranger-plugins-audit-10.22.0.2.jar:10.22.0.2]
at 
org.apache.ranger.audit.queue.AuditBatchQueue.runLogAudit(AuditBatchQueue.java) 
[ranger-plugins-audit-10.22.0.2.jar:10.22.0.2]
at org.apache.ranger.audit.queue.AuditBatchQueue.run(AuditBatchQueue.java) 
[ranger-plugins-audit-10.22.0.2.jar:10.22.0.2]
at java.lang.Thread.run

[jira] [Updated] (RANGER-4806) With java 17 the audit spool exception is seen if solr is not reachable.

2024-05-28 Thread Monika kachhadiya (Jira)


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

Monika kachhadiya updated RANGER-4806:
--
Summary:  With java 17 the audit spool exception is seen if solr is not 
reachable.  (was:  with java 17 the audit spool exception is seen if solr is 
not reachable.)

>  With java 17 the audit spool exception is seen if solr is not reachable.
> -
>
> Key: RANGER-4806
> URL: https://issues.apache.org/jira/browse/RANGER-4806
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Reporter: Monika kachhadiya
>Assignee: Monika kachhadiya
>Priority: Major
>
> In EMR.6.15 environment with java 17 the audit spool exception is seen if 
> solr is not reachable. 
>  
> {code:java}
>  
>  ERROR AuditFileSpool: Error writing to file. event=AuthzAuditEvent
> com.google.gson.JsonIOException: Failed making field 
> 'java.nio.charset.Charset#name' accessible; either increase its visibility or 
> write a custom TypeAdapter for its declaring type.
> at 
> com.google.gson.internal.reflect.ReflectionHelper.makeAccessible(ReflectionHelper.java:38)
>  ~[gson-2.10.1.jar:?]
> at 
> com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.getBoundFields(ReflectiveTypeAdapterFactory.java:286)
>  ~[gson-2.10.1.jar:?]
> at 
> com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.create(ReflectiveTypeAdapterFactory.java:130)
>  ~[gson-2.10.1.jar:?]
> at com.google.gson.Gson.getAdapter(Gson.java:556) ~[gson-2.10.1.jar:?]
> at 
> com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.createBoundField(ReflectiveTypeAdapterFactory.java:160)
>  ~[gson-2.10.1.jar:?]
> at 
> com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.getBoundFields(ReflectiveTypeAdapterFactory.java:294)
>  ~[gson-2.10.1.jar:?]
> at 
> com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.create(ReflectiveTypeAdapterFactory.java:130)
>  ~[gson-2.10.1.jar:?]
> at com.google.gson.Gson.getAdapter(Gson.java:556) ~[gson-2.10.1.jar:?]
> at 
> com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.createBoundField(ReflectiveTypeAdapterFactory.java:160)
>  ~[gson-2.10.1.jar:?]
> at 
> com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.getBoundFields(ReflectiveTypeAdapterFactory.java:294)
>  ~[gson-2.10.1.jar:?]
> at 
> com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.create(ReflectiveTypeAdapterFactory.java:130)
>  ~[gson-2.10.1.jar:?]
> at com.google.gson.Gson.getAdapter(Gson.java:556) ~[gson-2.10.1.jar:?]
> at 
> com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.createBoundField(ReflectiveTypeAdapterFactory.java:160)
>  ~[gson-2.10.1.jar:?]
> at 
> com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.getBoundFields(ReflectiveTypeAdapterFactory.java:294)
>  ~[gson-2.10.1.jar:?]
> at 
> com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.create(ReflectiveTypeAdapterFactory.java:130)
>  ~[gson-2.10.1.jar:?]
> at com.google.gson.Gson.getAdapter(Gson.java:556) ~[gson-2.10.1.jar:?]
> at 
> com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.createBoundField(ReflectiveTypeAdapterFactory.java:160)
>  ~[gson-2.10.1.jar:?]
> at 
> com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.getBoundFields(ReflectiveTypeAdapterFactory.java:294)
>  ~[gson-2.10.1.jar:?]
> at 
> com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.create(ReflectiveTypeAdapterFactory.java:130)
>  ~[gson-2.10.1.jar:?]
> at com.google.gson.Gson.getAdapter(Gson.java:556) ~[gson-2.10.1.jar:?]
> at 
> com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.createBoundField(ReflectiveTypeAdapterFactory.java:160)
>  ~[gson-2.10.1.jar:?]
> at 
> com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.getBoundFields(ReflectiveTypeAdapterFactory.java:294)
>  ~[gson-2.10.1.jar:?]
> at 
> com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.create(ReflectiveTypeAdapterFactory.java:130)
>  ~[gson-2.10.1.jar:?]
> at com.google.gson.Gson.getAdapter(Gson.java:556) ~[gson-2.10.1.jar:?]
> at 
> com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.createBoundField(ReflectiveTypeAdapterFactory.java:160)
>  ~[gson-2.10.1.jar:?]
> at 
> com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.getBoundFields(ReflectiveTypeAdapterFactory.java:294)
>  ~[gson-2.10.1.jar:?]
> at 
> com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.create(ReflectiveTypeAdapterFactory.java:130)
>  ~[gson-2.10.1.jar:?]
> at com.google.gson.Gson.getAdapter(Gson.java:556) ~[gson-2.10.1.jar:?]

[jira] [Updated] (RANGER-4806) With java 17 the audit spool exception is seen if solr is not reachable.

2024-05-28 Thread Monika kachhadiya (Jira)


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

Monika kachhadiya updated RANGER-4806:
--
Description: 
With java 17 the audit spool exception is seen if solr is not reachable. 
 
{code:java}
 
 ERROR AuditFileSpool: Error writing to file. event=AuthzAuditEvent
com.google.gson.JsonIOException: Failed making field 
'java.nio.charset.Charset#name' accessible; either increase its visibility or 
write a custom TypeAdapter for its declaring type.
at 
com.google.gson.internal.reflect.ReflectionHelper.makeAccessible(ReflectionHelper.java:38)
 ~[gson-2.10.1.jar:?]
at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.getBoundFields(ReflectiveTypeAdapterFactory.java:286)
 ~[gson-2.10.1.jar:?]
at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.create(ReflectiveTypeAdapterFactory.java:130)
 ~[gson-2.10.1.jar:?]
at com.google.gson.Gson.getAdapter(Gson.java:556) ~[gson-2.10.1.jar:?]
at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.createBoundField(ReflectiveTypeAdapterFactory.java:160)
 ~[gson-2.10.1.jar:?]
at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.getBoundFields(ReflectiveTypeAdapterFactory.java:294)
 ~[gson-2.10.1.jar:?]
at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.create(ReflectiveTypeAdapterFactory.java:130)
 ~[gson-2.10.1.jar:?]
at com.google.gson.Gson.getAdapter(Gson.java:556) ~[gson-2.10.1.jar:?]
at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.createBoundField(ReflectiveTypeAdapterFactory.java:160)
 ~[gson-2.10.1.jar:?]
at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.getBoundFields(ReflectiveTypeAdapterFactory.java:294)
 ~[gson-2.10.1.jar:?]
at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.create(ReflectiveTypeAdapterFactory.java:130)
 ~[gson-2.10.1.jar:?]
at com.google.gson.Gson.getAdapter(Gson.java:556) ~[gson-2.10.1.jar:?]
at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.createBoundField(ReflectiveTypeAdapterFactory.java:160)
 ~[gson-2.10.1.jar:?]
at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.getBoundFields(ReflectiveTypeAdapterFactory.java:294)
 ~[gson-2.10.1.jar:?]
at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.create(ReflectiveTypeAdapterFactory.java:130)
 ~[gson-2.10.1.jar:?]
at com.google.gson.Gson.getAdapter(Gson.java:556) ~[gson-2.10.1.jar:?]
at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.createBoundField(ReflectiveTypeAdapterFactory.java:160)
 ~[gson-2.10.1.jar:?]
at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.getBoundFields(ReflectiveTypeAdapterFactory.java:294)
 ~[gson-2.10.1.jar:?]
at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.create(ReflectiveTypeAdapterFactory.java:130)
 ~[gson-2.10.1.jar:?]
at com.google.gson.Gson.getAdapter(Gson.java:556) ~[gson-2.10.1.jar:?]
at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.createBoundField(ReflectiveTypeAdapterFactory.java:160)
 ~[gson-2.10.1.jar:?]
at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.getBoundFields(ReflectiveTypeAdapterFactory.java:294)
 ~[gson-2.10.1.jar:?]
at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.create(ReflectiveTypeAdapterFactory.java:130)
 ~[gson-2.10.1.jar:?]
at com.google.gson.Gson.getAdapter(Gson.java:556) ~[gson-2.10.1.jar:?]
at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.createBoundField(ReflectiveTypeAdapterFactory.java:160)
 ~[gson-2.10.1.jar:?]
at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.getBoundFields(ReflectiveTypeAdapterFactory.java:294)
 ~[gson-2.10.1.jar:?]
at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.create(ReflectiveTypeAdapterFactory.java:130)
 ~[gson-2.10.1.jar:?]
at com.google.gson.Gson.getAdapter(Gson.java:556) ~[gson-2.10.1.jar:?]
at com.google.gson.Gson.toJson(Gson.java:834) ~[gson-2.10.1.jar:?]
at com.google.gson.Gson.toJson(Gson.java:812) ~[gson-2.10.1.jar:?]
at com.google.gson.Gson.toJson(Gson.java:759) ~[gson-2.10.1.jar:?]
at com.google.gson.Gson.toJson(Gson.java:736) ~[gson-2.10.1.jar:?]
at 
org.apache.ranger.audit.queue.AuditFileSpool.saveIndexFile(AuditFileSpool.java) 
~[ranger-plugins-audit-10.22.0.2.jar:10.22.0.2]
at 
org.apache.ranger.audit.queue.AuditFileSpool.getLogFileStream(AuditFileSpool.java)
 ~[ranger-plugins-audit-10.22.0.2.jar:10.22.0.2]
at org.apache.ranger.audit.queue.AuditFileSpool.stashLogs(AuditFileSpool.java) 
[ranger-plugins-audit-10.22.0.2.jar:10.22.0.2]
at org.apache.ranger.audit.queue.AuditFileSpool.stashLogs(AuditFileSpool.java) 
[ranger-plugins-audit-10.22.0.2.jar:10.22.0.2]
at 
org.apache.ranger.audit.queue.AuditBatchQueue.runLogAudit(AuditBatchQueue.java) 
[ranger-plugins-audit-10.22.0.2.jar:10.22.0.2]
at org.apache.ranger.audit.queue.AuditBatchQueue.run(AuditBatchQueue.java) 
[ranger-plugins-audit-10.22.0.2.jar:10.22.0.2]
at java.lang.Thread.run

[jira] [Updated] (RANGER-4806) with java 17 the audit spool exception is seen if solr is not reachable.

2024-05-28 Thread Monika kachhadiya (Jira)


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

Monika kachhadiya updated RANGER-4806:
--
Summary:  with java 17 the audit spool exception is seen if solr is not 
reachable.  (was: In EMR.6.15 environment with java 17 the audit spool 
exception is seen if solr is not reachable.)

>  with java 17 the audit spool exception is seen if solr is not reachable.
> -
>
> Key: RANGER-4806
> URL: https://issues.apache.org/jira/browse/RANGER-4806
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Reporter: Monika kachhadiya
>Assignee: Monika kachhadiya
>Priority: Major
>
> In EMR.6.15 environment with java 17 the audit spool exception is seen if 
> solr is not reachable. 
>  
> {code:java}
>  
>  ERROR AuditFileSpool: Error writing to file. event=AuthzAuditEvent
> com.google.gson.JsonIOException: Failed making field 
> 'java.nio.charset.Charset#name' accessible; either increase its visibility or 
> write a custom TypeAdapter for its declaring type.
> at 
> com.google.gson.internal.reflect.ReflectionHelper.makeAccessible(ReflectionHelper.java:38)
>  ~[gson-2.10.1.jar:?]
> at 
> com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.getBoundFields(ReflectiveTypeAdapterFactory.java:286)
>  ~[gson-2.10.1.jar:?]
> at 
> com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.create(ReflectiveTypeAdapterFactory.java:130)
>  ~[gson-2.10.1.jar:?]
> at com.google.gson.Gson.getAdapter(Gson.java:556) ~[gson-2.10.1.jar:?]
> at 
> com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.createBoundField(ReflectiveTypeAdapterFactory.java:160)
>  ~[gson-2.10.1.jar:?]
> at 
> com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.getBoundFields(ReflectiveTypeAdapterFactory.java:294)
>  ~[gson-2.10.1.jar:?]
> at 
> com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.create(ReflectiveTypeAdapterFactory.java:130)
>  ~[gson-2.10.1.jar:?]
> at com.google.gson.Gson.getAdapter(Gson.java:556) ~[gson-2.10.1.jar:?]
> at 
> com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.createBoundField(ReflectiveTypeAdapterFactory.java:160)
>  ~[gson-2.10.1.jar:?]
> at 
> com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.getBoundFields(ReflectiveTypeAdapterFactory.java:294)
>  ~[gson-2.10.1.jar:?]
> at 
> com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.create(ReflectiveTypeAdapterFactory.java:130)
>  ~[gson-2.10.1.jar:?]
> at com.google.gson.Gson.getAdapter(Gson.java:556) ~[gson-2.10.1.jar:?]
> at 
> com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.createBoundField(ReflectiveTypeAdapterFactory.java:160)
>  ~[gson-2.10.1.jar:?]
> at 
> com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.getBoundFields(ReflectiveTypeAdapterFactory.java:294)
>  ~[gson-2.10.1.jar:?]
> at 
> com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.create(ReflectiveTypeAdapterFactory.java:130)
>  ~[gson-2.10.1.jar:?]
> at com.google.gson.Gson.getAdapter(Gson.java:556) ~[gson-2.10.1.jar:?]
> at 
> com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.createBoundField(ReflectiveTypeAdapterFactory.java:160)
>  ~[gson-2.10.1.jar:?]
> at 
> com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.getBoundFields(ReflectiveTypeAdapterFactory.java:294)
>  ~[gson-2.10.1.jar:?]
> at 
> com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.create(ReflectiveTypeAdapterFactory.java:130)
>  ~[gson-2.10.1.jar:?]
> at com.google.gson.Gson.getAdapter(Gson.java:556) ~[gson-2.10.1.jar:?]
> at 
> com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.createBoundField(ReflectiveTypeAdapterFactory.java:160)
>  ~[gson-2.10.1.jar:?]
> at 
> com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.getBoundFields(ReflectiveTypeAdapterFactory.java:294)
>  ~[gson-2.10.1.jar:?]
> at 
> com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.create(ReflectiveTypeAdapterFactory.java:130)
>  ~[gson-2.10.1.jar:?]
> at com.google.gson.Gson.getAdapter(Gson.java:556) ~[gson-2.10.1.jar:?]
> at 
> com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.createBoundField(ReflectiveTypeAdapterFactory.java:160)
>  ~[gson-2.10.1.jar:?]
> at 
> com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.getBoundFields(ReflectiveTypeAdapterFactory.java:294)
>  ~[gson-2.10.1.jar:?]
> at 
> com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.create(ReflectiveTypeAdapterFactory.java:130)
>  ~[gson-2.10.1.jar:?]
> at com.google.gson.Gson.getAdapter(Gson.java:556) ~

[jira] [Created] (RANGER-4806) In EMR.6.15 environment with java 17 the audit spool exception is seen if solr is not reachable.

2024-05-28 Thread Monika kachhadiya (Jira)
Monika kachhadiya created RANGER-4806:
-

 Summary: In EMR.6.15 environment with java 17 the audit spool 
exception is seen if solr is not reachable.
 Key: RANGER-4806
 URL: https://issues.apache.org/jira/browse/RANGER-4806
 Project: Ranger
  Issue Type: Bug
  Components: Ranger
Reporter: Monika kachhadiya
Assignee: Monika kachhadiya


In EMR.6.15 environment with java 17 the audit spool exception is seen if solr 
is not reachable. 
 
{code:java}
 
 ERROR AuditFileSpool: Error writing to file. event=AuthzAuditEvent
com.google.gson.JsonIOException: Failed making field 
'java.nio.charset.Charset#name' accessible; either increase its visibility or 
write a custom TypeAdapter for its declaring type.
at 
com.google.gson.internal.reflect.ReflectionHelper.makeAccessible(ReflectionHelper.java:38)
 ~[gson-2.10.1.jar:?]
at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.getBoundFields(ReflectiveTypeAdapterFactory.java:286)
 ~[gson-2.10.1.jar:?]
at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.create(ReflectiveTypeAdapterFactory.java:130)
 ~[gson-2.10.1.jar:?]
at com.google.gson.Gson.getAdapter(Gson.java:556) ~[gson-2.10.1.jar:?]
at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.createBoundField(ReflectiveTypeAdapterFactory.java:160)
 ~[gson-2.10.1.jar:?]
at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.getBoundFields(ReflectiveTypeAdapterFactory.java:294)
 ~[gson-2.10.1.jar:?]
at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.create(ReflectiveTypeAdapterFactory.java:130)
 ~[gson-2.10.1.jar:?]
at com.google.gson.Gson.getAdapter(Gson.java:556) ~[gson-2.10.1.jar:?]
at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.createBoundField(ReflectiveTypeAdapterFactory.java:160)
 ~[gson-2.10.1.jar:?]
at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.getBoundFields(ReflectiveTypeAdapterFactory.java:294)
 ~[gson-2.10.1.jar:?]
at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.create(ReflectiveTypeAdapterFactory.java:130)
 ~[gson-2.10.1.jar:?]
at com.google.gson.Gson.getAdapter(Gson.java:556) ~[gson-2.10.1.jar:?]
at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.createBoundField(ReflectiveTypeAdapterFactory.java:160)
 ~[gson-2.10.1.jar:?]
at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.getBoundFields(ReflectiveTypeAdapterFactory.java:294)
 ~[gson-2.10.1.jar:?]
at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.create(ReflectiveTypeAdapterFactory.java:130)
 ~[gson-2.10.1.jar:?]
at com.google.gson.Gson.getAdapter(Gson.java:556) ~[gson-2.10.1.jar:?]
at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.createBoundField(ReflectiveTypeAdapterFactory.java:160)
 ~[gson-2.10.1.jar:?]
at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.getBoundFields(ReflectiveTypeAdapterFactory.java:294)
 ~[gson-2.10.1.jar:?]
at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.create(ReflectiveTypeAdapterFactory.java:130)
 ~[gson-2.10.1.jar:?]
at com.google.gson.Gson.getAdapter(Gson.java:556) ~[gson-2.10.1.jar:?]
at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.createBoundField(ReflectiveTypeAdapterFactory.java:160)
 ~[gson-2.10.1.jar:?]
at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.getBoundFields(ReflectiveTypeAdapterFactory.java:294)
 ~[gson-2.10.1.jar:?]
at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.create(ReflectiveTypeAdapterFactory.java:130)
 ~[gson-2.10.1.jar:?]
at com.google.gson.Gson.getAdapter(Gson.java:556) ~[gson-2.10.1.jar:?]
at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.createBoundField(ReflectiveTypeAdapterFactory.java:160)
 ~[gson-2.10.1.jar:?]
at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.getBoundFields(ReflectiveTypeAdapterFactory.java:294)
 ~[gson-2.10.1.jar:?]
at 
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.create(ReflectiveTypeAdapterFactory.java:130)
 ~[gson-2.10.1.jar:?]
at com.google.gson.Gson.getAdapter(Gson.java:556) ~[gson-2.10.1.jar:?]
at com.google.gson.Gson.toJson(Gson.java:834) ~[gson-2.10.1.jar:?]
at com.google.gson.Gson.toJson(Gson.java:812) ~[gson-2.10.1.jar:?]
at com.google.gson.Gson.toJson(Gson.java:759) ~[gson-2.10.1.jar:?]
at com.google.gson.Gson.toJson(Gson.java:736) ~[gson-2.10.1.jar:?]
at 
org.apache.ranger.audit.queue.AuditFileSpool.saveIndexFile(AuditFileSpool.java) 
~[ranger-plugins-audit-10.22.0.2.jar:10.22.0.2]
at 
org.apache.ranger.audit.queue.AuditFileSpool.getLogFileStream(AuditFileSpool.java)
 ~[ranger-plugins-audit-10.22.0.2.jar:10.22.0.2]
at org.apache.ranger.audit.queue.AuditFileSpool.stashLogs(AuditFileSpool.java) 
[ranger-plugins-audit-10.22.0.2.jar:10.22.0.2]
at org.apache.ranger.audit.queue.AuditFileSpool.stashLogs(AuditFileSpool.java) 
[ranger-plugins-audit-10.22.0.2.jar:10.22.0.2

[jira] [Created] (RANGER-4805) Disable Atlas service under the policy permission of Tag-based policy

2024-05-28 Thread Rakesh Gupta (Jira)
Rakesh Gupta created RANGER-4805:


 Summary: Disable Atlas service under the policy permission of 
Tag-based policy
 Key: RANGER-4805
 URL: https://issues.apache.org/jira/browse/RANGER-4805
 Project: Ranger
  Issue Type: Task
  Components: Ranger
Reporter: Rakesh Gupta
Assignee: Rakesh Gupta


Steps to reproduce:
 - Created a tag policy for a `test` classification 
 - Added deny permission for user `tuser`
 - Access entity tagged with `test` classification through `tuser` through 
Atlas UI



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


[jira] [Created] (RANGER-4804) Encountering a '404 Not Found' page when assigning two or more groups to a user during editing

2024-05-27 Thread kiran chormare (Jira)
kiran chormare created RANGER-4804:
--

 Summary: Encountering a '404 Not Found' page when assigning two or 
more groups to a user during editing
 Key: RANGER-4804
 URL: https://issues.apache.org/jira/browse/RANGER-4804
 Project: Ranger
  Issue Type: Bug
  Components: Ranger
Reporter: kiran chormare


We are encountering an issue where a '404 Not Found' page is displayed when 
attempting to assign two or more groups to a user during the editing process.

Steps to Reproduce:
1. Navigate to Settings > Users.
2. Click on a USER to edit.
3. In the Groups dropdown, select two or more groups.
4. Click the Save button.

Expected Result:
The user should be updated with the selected groups

Actual Result:
'404 Not Found' page is displayed



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


[jira] [Updated] (RANGER-4774) Ranger react UI some modules shown hardcoded time zone string "Indian Standard Time"

2024-05-27 Thread Dhaval Rajpara (Jira)


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

Dhaval Rajpara updated RANGER-4774:
---
Attachment: 0001-RANGER-4774.patch

> Ranger react UI some modules shown hardcoded  time zone string "Indian 
> Standard Time"
> -
>
> Key: RANGER-4774
> URL: https://issues.apache.org/jira/browse/RANGER-4774
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Reporter: Dhaval Rajpara
>Assignee: Dhaval Rajpara
>Priority: Major
> Attachments: 0001-RANGER-4774.patch
>
>
> 1) UI popup showing details of an admin audit log seems to have hardcoded 
> string “Indian Standard Time” 
> 2)Some logs table header also have hardcoded string “Indian Standard Time” 



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


[jira] [Updated] (RANGER-4803) create a single admin audit record per object change instead of one for each attribute

2024-05-26 Thread Madhan Neethiraj (Jira)


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

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

> create a single admin audit record per object change instead of one for each 
> attribute
> --
>
> Key: RANGER-4803
> URL: https://issues.apache.org/jira/browse/RANGER-4803
> Project: Ranger
>  Issue Type: Sub-task
>  Components: Ranger
>Reporter: Madhan Neethiraj
>Assignee: Madhan Neethiraj
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: RANGER-4803.patch
>
>
> Currently one admin audit log entry is generated for each attribute of the 
> changed object. This should be updated to create a single entry for the 
> entire object, which will make querying admin audits more efficient.



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


[jira] [Created] (RANGER-4803) create a single admin audit record per object change instead of one for each attribute

2024-05-26 Thread Madhan Neethiraj (Jira)
Madhan Neethiraj created RANGER-4803:


 Summary: create a single admin audit record per object change 
instead of one for each attribute
 Key: RANGER-4803
 URL: https://issues.apache.org/jira/browse/RANGER-4803
 Project: Ranger
  Issue Type: Sub-task
  Components: Ranger
Reporter: Madhan Neethiraj
Assignee: Madhan Neethiraj


Currently one admin audit log entry is generated for each attribute of the 
changed object. This should be updated to create a single entry for the entire 
object, which will make querying admin audits more efficient.



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


[jira] [Created] (RANGER-4802) [Ranger Trino] Alter materialized view command is not working when Ranger plugin is enabled

2024-05-23 Thread Abhishek (Jira)
Abhishek created RANGER-4802:


 Summary: [Ranger Trino] Alter materialized view command is not 
working when Ranger plugin is enabled
 Key: RANGER-4802
 URL: https://issues.apache.org/jira/browse/RANGER-4802
 Project: Ranger
  Issue Type: Bug
  Components: Ranger
Reporter: Abhishek
Assignee: Pradeep Agrawal


When Ranger plugin is enabled for Trino server, and when Iceberg catalog is 
used (Materialized views are supported only for Iceberg catalog in Trino),
"Alter materialized view \{view_name}" command is not working, and it says that 
the access is denied.
If the ranger trino plugin is disabled, then the command works fine.

Steps to reproduce :
1. Use Iceberg catalog in Trino
2. Create a materialised view m_view_1
3. Run the command - Alter materialized view m_view_1 rename to m_view_2;
The command will not work and it will say that the access is denied



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


[jira] [Created] (RANGER-4801) [Ranger Trino] Refresh materialized view command is not working when Ranger plugin is enabled

2024-05-23 Thread Abhishek (Jira)
Abhishek created RANGER-4801:


 Summary: [Ranger Trino] Refresh materialized view command is not 
working when Ranger plugin is enabled
 Key: RANGER-4801
 URL: https://issues.apache.org/jira/browse/RANGER-4801
 Project: Ranger
  Issue Type: Bug
  Components: Ranger
Reporter: Abhishek
Assignee: Pradeep Agrawal


When Ranger plugin is enabled for Trino server, and when Iceberg catalog is 
used (Materialized views are supported only for Iceberg catalog in Trino),
"Refresh materialized view \{view_name}" command is not working, and it says 
that the access is denied.
If the ranger trino plugin is disabled, then the command works fine.

Steps to reproduce :
1. Use Iceberg catalog in Trino
2. Create a materialised view m_view_1
3. Run the command - Refresh materialised view m_view_1;
The command will not work and it will say that the access is denied



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


[jira] [Updated] (RANGER-4800) Ranger Tagsync service start failed when ranger admin is SSL enabled

2024-05-23 Thread Bhavik Patel (Jira)


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

Bhavik Patel updated RANGER-4800:
-
Attachment: 0001-RANGER-4800-Ranger-Tagsync-service-start-failed-when.patch

> Ranger Tagsync service start failed when ranger admin is SSL enabled
> 
>
> Key: RANGER-4800
> URL: https://issues.apache.org/jira/browse/RANGER-4800
> Project: Ranger
>  Issue Type: Bug
>  Components: tagsync
>Affects Versions: 2.4.0
>Reporter: Bhavik Patel
>Assignee: Bhavik Patel
>Priority: Major
> Attachments: 
> 0001-RANGER-4800-Ranger-Tagsync-service-start-failed-when.patch
>
>
> Ranger Tagsync service start failed when ranger admin is SSL enabled with 
> below error:
> {code:java}
> ERROR o.a.r.t.p.TagSynchronizer [main] - 230 Failed to initialize TAG sink. 
> Error details:
> java.lang.NoClassDefFoundError: 
> org/apache/ranger/authorization/hadoop/utils/RangerCredentialProvider
> at 
> org.apache.ranger.plugin.util.RangerRESTClient.getCredential(RangerRESTClient.java:433)
> at 
> org.apache.ranger.plugin.util.RangerRESTClient.getKeyManagers(RangerRESTClient.java:291)
> at 
> org.apache.ranger.plugin.util.RangerRESTClient.buildClient(RangerRESTClient.java:205)
> at 
> org.apache.ranger.plugin.util.RangerRESTClient.getClient(RangerRESTClient.java:193)
> at 
> org.apache.ranger.tagsync.sink.tagadmin.TagAdminRESTSink.initialize(TagAdminRESTSink.java:106)
> at 
> org.apache.ranger.tagsync.process.TagSynchronizer.initializeTagSink(TagSynchronizer.java:225)
> at 
> org.apache.ranger.tagsync.process.TagSynchronizer.initialize(TagSynchronizer.java:110)
> at 
> org.apache.ranger.tagsync.process.TagSynchronizer.main(TagSynchronizer.java:65)
> Caused by: java.lang.ClassNotFoundException: 
> org.apache.ranger.authorization.hadoop.utils.RangerCredentialProvider
> at 
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
> at 
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:525)
> ... 8 common frames omitted
> {code}



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


[jira] [Created] (RANGER-4800) Ranger Tagsync service start failed when ranger admin is SSL enabled

2024-05-23 Thread Bhavik Patel (Jira)
Bhavik Patel created RANGER-4800:


 Summary: Ranger Tagsync service start failed when ranger admin is 
SSL enabled
 Key: RANGER-4800
 URL: https://issues.apache.org/jira/browse/RANGER-4800
 Project: Ranger
  Issue Type: Bug
  Components: tagsync
Affects Versions: 2.4.0
Reporter: Bhavik Patel
Assignee: Bhavik Patel


Ranger Tagsync service start failed when ranger admin is SSL enabled with below 
error:


{code:java}
ERROR o.a.r.t.p.TagSynchronizer [main] - 230 Failed to initialize TAG sink. 
Error details:
java.lang.NoClassDefFoundError: 
org/apache/ranger/authorization/hadoop/utils/RangerCredentialProvider
at 
org.apache.ranger.plugin.util.RangerRESTClient.getCredential(RangerRESTClient.java:433)
at 
org.apache.ranger.plugin.util.RangerRESTClient.getKeyManagers(RangerRESTClient.java:291)
at 
org.apache.ranger.plugin.util.RangerRESTClient.buildClient(RangerRESTClient.java:205)
at 
org.apache.ranger.plugin.util.RangerRESTClient.getClient(RangerRESTClient.java:193)
at 
org.apache.ranger.tagsync.sink.tagadmin.TagAdminRESTSink.initialize(TagAdminRESTSink.java:106)
at 
org.apache.ranger.tagsync.process.TagSynchronizer.initializeTagSink(TagSynchronizer.java:225)
at 
org.apache.ranger.tagsync.process.TagSynchronizer.initialize(TagSynchronizer.java:110)
at 
org.apache.ranger.tagsync.process.TagSynchronizer.main(TagSynchronizer.java:65)
Caused by: java.lang.ClassNotFoundException: 
org.apache.ranger.authorization.hadoop.utils.RangerCredentialProvider
at 
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
at 
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:525)
... 8 common frames omitted
{code}




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


[jira] [Created] (RANGER-4799) [Ranger Trino] Audits are not logged for schema/table creation

2024-05-22 Thread Abhishek (Jira)
Abhishek created RANGER-4799:


 Summary: [Ranger Trino] Audits are not logged for schema/table 
creation
 Key: RANGER-4799
 URL: https://issues.apache.org/jira/browse/RANGER-4799
 Project: Ranger
  Issue Type: Bug
  Components: Ranger
Reporter: Abhishek


On a cluster where trino server is setup and ranger trino plugin is enabled,
audits are not generated for schema/table creation.

Steps to reproduce :-
1. As a user with all privileges, run the schema create command : "create 
schema schema_name;"
The access audit will only be generated for the catalog resource and not the 
schema resource

2. As a user with all privileges, run the table create command,
"Create table table_name(column_name column_type);".
The access audits are generated for the catalog and schema resources, and not 
for the table resource



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


[jira] [Created] (RANGER-4798) Default policies created for cm_trino for policies without select access type cannot be edited without adding permission for rangerlookup user

2024-05-22 Thread Abhishek (Jira)
Abhishek created RANGER-4798:


 Summary: Default policies created for cm_trino for policies 
without select access type cannot be edited without adding permission for 
rangerlookup user
 Key: RANGER-4798
 URL: https://issues.apache.org/jira/browse/RANGER-4798
 Project: Ranger
  Issue Type: Bug
  Components: Ranger
Reporter: Abhishek
Assignee: Pradeep Agrawal


In few of the default policies created for cm_trino, the policies do not 
contain the select access type (based on the resource in the policies).
But during default policy creation, the rangerlookup user is being added to 
each policy with "select" access type, and for policies without select access 
type, the access type in the policy item is empty.
If a user tries to edit the policy and save, then the policy save will not be 
successful as the user is prompted to add an access type for the rangerlookup 
user.
Ideally, for policies where select access type is not supported, rangerlookup 
user should be either removed from the default policies, or a proper access 
type has to be configured for the user.

Steps to reproduce :-
Try to edit the "all-function" policy in cm_trino repo and try saving the 
policy without any change, the save will fail.



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


[jira] [Created] (RANGER-4797) Impersonate access type may not be required for trino policies other than trinouser resource type

2024-05-22 Thread Abhishek (Jira)
Abhishek created RANGER-4797:


 Summary: Impersonate access type may not be required for trino 
policies other than trinouser resource type
 Key: RANGER-4797
 URL: https://issues.apache.org/jira/browse/RANGER-4797
 Project: Ranger
  Issue Type: Bug
  Components: Ranger
Reporter: Abhishek
Assignee: Pradeep Agrawal


In the Trino policies containing "trinouser" as the resource type, the usecase 
is whatever users are specified in the "trinouser" resource type can be 
impersonated by users listed in the allow policy items.

For e.g, consider a policy
resource : trinouser : hrt_qa
allow policy items : user - trino, access - impersonate

In the above policy, the trino user can run the command "SET SESSION 
AUTHORIZATION hrt_qa;", and the query should work.

The impersonate access type is also being used to view the query owned by other 
users and kill queries triggered by other users, in such cases, the 
authorisation is only checked against the"trinouser" resource.

However, the "Impersonate" access type is also being listed in other trino 
resource based policies like "catalog", "schema", "table", etc.
This access type may not be required in such policies



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


[jira] [Created] (RANGER-4796) Create function and Drop function commands are not supported when Ranger plugin is enabled

2024-05-22 Thread Abhishek (Jira)
Abhishek created RANGER-4796:


 Summary: Create function and Drop function commands are not 
supported when Ranger plugin is enabled
 Key: RANGER-4796
 URL: https://issues.apache.org/jira/browse/RANGER-4796
 Project: Ranger
  Issue Type: Bug
  Components: Ranger
Reporter: Abhishek
Assignee: Pradeep Agrawal


In Trino, Hive connector supports Create function and Drop function commands.
But when the ranger trino plugin is enabled, the Create function and Drop 
function commands are not supported (they are supported when ranger plugin is 
disabled), and the following error message is displayed in the output.
{code:java|bgColor=#f4f5f7}
trino> drop function hive.default.meaning_of_life();
Query 20240415_185213_1_64nwa failed: Access Denied: Cannot drop function 
hive.default.meaning_of_life {code}
This is because in the policy for allowing access to functions, only two access 
types are present, Grant and execute.
If the function is created when Ranger plugin is disabled, and then the user 
executes the function, the function execution is authorised by ranger plugin as 
the policy contains an "Execute" access type.
In order to support the Create and drop function commands in Ranger Trino 
plugin, the policy definition for the resource type "Function" must be enhanced 
to include "Create" and "Drop" access types



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


[jira] [Assigned] (RANGER-4748) Admin audits UI is slow when x_trx_log table has large numer of rows

2024-05-21 Thread Madhan Neethiraj (Jira)


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

Madhan Neethiraj reassigned RANGER-4748:


Assignee: Madhan Neethiraj

> Admin audits UI is slow when x_trx_log table has large numer of rows 
> -
>
> Key: RANGER-4748
> URL: https://issues.apache.org/jira/browse/RANGER-4748
> Project: Ranger
>  Issue Type: Improvement
>  Components: Ranger
>Reporter: Madhan Neethiraj
>Assignee: Madhan Neethiraj
>Priority: Major
>
> Admin tab in Ranger audit UI lists changes performed on 
> policies/users/groups/security-zones/service - one row for each object. 
> Details of changes to an object (like old and new value of attributes) are 
> available in a dialog box that pops up on clicking the row.
> API to retrieve list of admin audit log can take a long time when large 
> number of rows exists in that database table that stores change details i.e. 
> table named x_trx_log. This is due to the use of database view, vx_trx_log, 
> on top of table x_trx_log, which performs a group-by operation that would 
> require a full-table scan. This view is necessary since x_trx_log can have 
> multiple rows for one change to an object - one row for each changed 
> attribute.
> To avoid this issue, one option to consider is store changes to all 
> attributes of an object in a single row (instead of one row per changed 
> attribute). This will eliminate the need for a view that performs group by.
>  
> CC: [~siddheshphatak] 



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


[jira] [Comment Edited] (RANGER-3409) Update Jackson and remove Codehaus version

2024-05-21 Thread Sercan Tekin (Jira)


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

Sercan Tekin edited comment on RANGER-3409 at 5/21/24 2:32 PM:
---

[~bpatel], you're correct. My intention was only to address the camel-case 
conflict in the first place.

But now, I've incorporated [~n.blagodarny]'s solution (crediting as the 
author), and then cherry-picked the solution for the conflict on top of it in 
my PR.

Could you folks please review and test this now? -> 
https://github.com/apache/ranger/pull/252

PS: [~n.blagodarny], have you changed your user name or email address in your 
git account> None of the below options link you as an author to your github 
account:
{code:java}
git commit --amend --author="Nikita Blagodarnyi "
git commit --amend --author="nblagodarnyi "
git commit --amend --author="n.blagodarny "
{code}
Even in your own PR, in the commit details, your name is not linked to your 
account.




was (Author: JIRAUSER283532):
[~bpatel], you're correct. My intention was only to address the camel-case 
conflict in the first place.

But now, I've incorporated [~n.blagodarny]'s solution (crediting as the 
author), and then cherry-picked the solution for the conflict on top of it in 
my PR.

Could you folks please review and test this now? -> 
https://github.com/apache/ranger/pull/252

> Update Jackson and remove Codehaus version
> --
>
> Key: RANGER-3409
> URL: https://issues.apache.org/jira/browse/RANGER-3409
> Project: Ranger
>  Issue Type: Improvement
>  Components: Ranger
>Affects Versions: 3.0.0
>Reporter: Andrew Charneski
>Priority: Blocker
> Attachments: ranger-modify-policy.png
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> An old version of Jackson (Codehaus Jackson 1.9.13) is still being used. 
> Jackson has since moved namespaces with a reorganized library structure. 
> Update all references to the older version to use the newer version (which is 
> currently used in some modules).



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


[jira] [Comment Edited] (RANGER-3409) Update Jackson and remove Codehaus version

2024-05-21 Thread Sercan Tekin (Jira)


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

Sercan Tekin edited comment on RANGER-3409 at 5/21/24 2:26 PM:
---

[~bpatel], you're correct. My intention was only to address the camel-case 
conflict in the first place.

But now, I've incorporated [~n.blagodarny]'s solution (crediting as the 
author), and then cherry-picked the solution for the conflict on top of it in 
my PR.

Could you folks please review and test this now? -> 
https://github.com/apache/ranger/pull/252


was (Author: JIRAUSER283532):
[~bpatel], you're correct. My intention was only to address the camel-case 
conflict in the first place.

But now, I've incorporated [~n.blagodarny]'s solution (crediting as the 
author), and then cherry-picked the solution for the conflict on top of it in 
my PR.

Could you folks review and test this now? -> 
https://github.com/apache/ranger/pull/252

> Update Jackson and remove Codehaus version
> --
>
> Key: RANGER-3409
> URL: https://issues.apache.org/jira/browse/RANGER-3409
> Project: Ranger
>  Issue Type: Improvement
>  Components: Ranger
>Affects Versions: 3.0.0
>Reporter: Andrew Charneski
>Priority: Blocker
> Attachments: ranger-modify-policy.png
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> An old version of Jackson (Codehaus Jackson 1.9.13) is still being used. 
> Jackson has since moved namespaces with a reorganized library structure. 
> Update all references to the older version to use the newer version (which is 
> currently used in some modules).



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


[jira] [Commented] (RANGER-3409) Update Jackson and remove Codehaus version

2024-05-21 Thread Sercan Tekin (Jira)


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

Sercan Tekin commented on RANGER-3409:
--

[~bpatel], you're correct. My intention was only to address the camel-case 
conflict in the first place.

But now, I've incorporated [~n.blagodarny]'s solution (crediting as the 
author), and then cherry-picked the solution for the conflict on top of it in 
my PR.

Could you folks review and test this now? -> 
https://github.com/apache/ranger/pull/252

> Update Jackson and remove Codehaus version
> --
>
> Key: RANGER-3409
> URL: https://issues.apache.org/jira/browse/RANGER-3409
> Project: Ranger
>  Issue Type: Improvement
>  Components: Ranger
>Affects Versions: 3.0.0
>Reporter: Andrew Charneski
>Priority: Blocker
> Attachments: ranger-modify-policy.png
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> An old version of Jackson (Codehaus Jackson 1.9.13) is still being used. 
> Jackson has since moved namespaces with a reorganized library structure. 
> Update all references to the older version to use the newer version (which is 
> currently used in some modules).



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


[jira] [Created] (RANGER-4795) Add validation in API to check emptyness on policyitem while creating policy.

2024-05-21 Thread Rakesh Gupta (Jira)
Rakesh Gupta created RANGER-4795:


 Summary: Add validation in API to check emptyness on policyitem 
while creating policy.
 Key: RANGER-4795
 URL: https://issues.apache.org/jira/browse/RANGER-4795
 Project: Ranger
  Issue Type: Task
  Components: Ranger
Reporter: Rakesh Gupta
Assignee: Rakesh Gupta


There is an inconsistency between Ranger API and UI not doing the same 
validation for Policy creation. 

Policy creation API should fail when a policy with all empty values and along 
with  [""]  or  ["null"] in policyItem --> users, groups and roles.



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


[jira] [Commented] (RANGER-3409) Update Jackson and remove Codehaus version

2024-05-21 Thread Bhavik Patel (Jira)


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

Bhavik Patel commented on RANGER-3409:
--

[~sercan.tekin]  I have reviewed your PR but i can see still the usage of 
"codehaus" package. 

> Update Jackson and remove Codehaus version
> --
>
> Key: RANGER-3409
> URL: https://issues.apache.org/jira/browse/RANGER-3409
> Project: Ranger
>  Issue Type: Improvement
>  Components: Ranger
>Affects Versions: 3.0.0
>Reporter: Andrew Charneski
>Priority: Blocker
> Attachments: ranger-modify-policy.png
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> An old version of Jackson (Codehaus Jackson 1.9.13) is still being used. 
> Jackson has since moved namespaces with a reorganized library structure. 
> Update all references to the older version to use the newer version (which is 
> currently used in some modules).



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


[jira] [Commented] (RANGER-4793) Make HADOOPSQL Masking and Row Level Filter policies support wildcards by default

2024-05-20 Thread wangzhongwei (Jira)


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

wangzhongwei commented on RANGER-4793:
--

[~madhan] thanks for your detailed explanation .maybe we can give a hint of 
using mask types string  and filter columns existing  where there is input box 
with table and column  when masking and row-filter policies supporting wildcard 

> Make HADOOPSQL Masking and Row Level Filter policies support wildcards by 
> default
> -
>
> Key: RANGER-4793
> URL: https://issues.apache.org/jira/browse/RANGER-4793
> Project: Ranger
>  Issue Type: Improvement
>  Components: plugins
>Affects Versions: 2.2.0, 2.3.0, 2.4.0
>Reporter: wangzhongwei
>Assignee: wangzhongwei
>Priority: Major
> Attachments: RANGER-4793.patch
>
>
>  Now ,in Access Policies ,input of database,table,and column support 
> wildcards,while  Masking and Row Level Filter do not work when using 
> wildcards. 



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


[jira] [Commented] (RANGER-4793) Make HADOOPSQL Masking and Row Level Filter policies support wildcards by default

2024-05-20 Thread Madhan Neethiraj (Jira)


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

Madhan Neethiraj commented on RANGER-4793:
--

[~zhongwei11] - wildcard is currently not enabled for masking and row-filter 
policies to reduce the chances of setting up incompatible policies. For example:
 - mask type HASH is only applicable for columns having string values. With use 
of wildcard, it is easily possible for this mask type to be setup for columns 
having other datatypes. Similarly for other mask types that are valid only for 
specific datatypes
 - row-filter expressions typically refer to columns in the table on which the 
filter is applied. With use of wildcard, it is easily possible to setup a 
filter on a table that doesn't include the referenced column

Over the years, there have been many asks to enable wildcards for masking and 
row-filter policies - to reduce number of policies hence making it easier to 
manage. This certainly requires the policy author to setup policies to avoid 
incompatible masking and filtering.

{colType\} macro introduced in RANGER-4650 
([https://reviews.apache.org/r/74834/]) can help setup datatype specific mask 
type.

Perhaps introducing a new policy condition like COLUMNS_EXIST('state') can help 
with row-filter as well. This should be explored further.

About the changes in this patch, in addition to supporting wildcards, it will 
help to enable multiple columns/tables to be listed in policies. I suggest to 
remove attributes other than "name" in #353 - #378 and #443 - #462 - as shown 
below, which would result in values defined earlier for these resources to be 
used in dataMaskDef and rowFilterDef:

{noformat}
"dataMaskDef": {
  ...
  "resources": [
{ "name": "database" },
{ "name": "table" },
{ "name": "column" }
  ],
},
"rowFilterDef": {
  ...
  "resources": [
{ "name": "database" },
{ "name": "table" }
  ]
}
{noformat}


> Make HADOOPSQL Masking and Row Level Filter policies support wildcards by 
> default
> -
>
> Key: RANGER-4793
> URL: https://issues.apache.org/jira/browse/RANGER-4793
> Project: Ranger
>  Issue Type: Improvement
>  Components: plugins
>Affects Versions: 2.2.0, 2.3.0, 2.4.0
>Reporter: wangzhongwei
>Assignee: wangzhongwei
>Priority: Major
> Attachments: RANGER-4793.patch
>
>
>  Now ,in Access Policies ,input of database,table,and column support 
> wildcards,while  Masking and Row Level Filter do not work when using 
> wildcards. 



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


[jira] [Updated] (RANGER-4446) Need an API to return dataset summary

2024-05-20 Thread Madhan Neethiraj (Jira)


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

Madhan Neethiraj updated RANGER-4446:
-
Fix Version/s: 3.0.0

> Need an API to return dataset summary
> -
>
> Key: RANGER-4446
> URL: https://issues.apache.org/jira/browse/RANGER-4446
> Project: Ranger
>  Issue Type: Sub-task
>  Components: admin
>Reporter: Subhrat Chaudhary
>Assignee: Subhrat Chaudhary
>Priority: Major
> Fix For: 3.0.0
>
>
> In https://issues.apache.org/jira/browse/RANGER-4323 we added API to support 
> DatasetHeaderInfo to return dataset details. We need additional details in 
> the response:
> {code:java}
> {
>     "startIndex": 0,
>     "pageSize": 200,
>     "totalCount": 1,
>     "resultSize": 1,
>     "sortType": "createTime",
>     "sortBy": "desc",
>     "queryTimeMS": 1695969636652,
>     "list": [
>         {
>             "id": 1,
>             "guid": "30b50d94-dfde-4e16-8ef5-722cb8e7442b",
>             "isEnabled": true,
>             "createdBy": "Admin",
>             "updatedBy": "Admin",
>             "createTime": 1695969001000,
>             "updateTime": 1695969001000,
>             "version": 1,
>             "name": "Test_GDS_Dataset",
>             "principalsCountByType": {
>                 "ROLE": 0,
>                 "USER": 1,
>                 "GROUP": 1
>             },
>             "permissionForCaller": "VIEW"
>             "projectsCount": 1,
>             "totalResourceCount": 4,
>             "dataSharesCountByStatus": {
>                 "REQUESTED": 2,
>                 "GRANTED": 3,
>                 "ACTIVE": 1
>             }
>             "dataShares"[
>                 {
>                     "id": 1,
>                     "guid": "30b50d94-dfde-4e16-8ef5-722cb8e7442b",
>                     "isEnabled": true,
>                     "createdBy": "Admin",
>                     "updatedBy": "Admin",
>                     "createTime": 1695969001000,
>                     "updateTime": 1695969001000,
>                     "version": 1,
>                     "name": "dataShare1",
>                     "dshInDsId":1,
>                     "sharedStatus":"ACTIVE",
>                     "resourceCount": 4,
>                     "serviceId": 3,
>                     "serviceName": "Resource_policy_Performance_test_50K",
>                     "zoneId": 3,
>                     "zoneName": "Gds_Security_Zone",
>                     "approver": "admin"
>                 }
>             ]
>         }
>     ],
>     "listSize": 1
> } {code}



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


[jira] [Resolved] (RANGER-4444) When security-zone is deleted with force, trigger cascade delete of datashare

2024-05-20 Thread Madhan Neethiraj (Jira)


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

Madhan Neethiraj resolved RANGER-.
--
Fix Version/s: 3.0.0
   Resolution: Fixed

> When security-zone is deleted with force, trigger cascade delete of datashare
> -
>
> Key: RANGER-
> URL: https://issues.apache.org/jira/browse/RANGER-
> Project: Ranger
>  Issue Type: Sub-task
>  Components: admin
>Reporter: Subhrat Chaudhary
>Assignee: Madhan Neethiraj
>Priority: Major
> Fix For: 3.0.0
>
>
> When security-zone is deleted with force, trigger cascade delete of datashare 
> also.



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


[jira] [Created] (RANGER-4794) update GDS Python client to support forceDelete flag

2024-05-20 Thread Madhan Neethiraj (Jira)
Madhan Neethiraj created RANGER-4794:


 Summary: update GDS Python client to support forceDelete flag
 Key: RANGER-4794
 URL: https://issues.apache.org/jira/browse/RANGER-4794
 Project: Ranger
  Issue Type: Sub-task
  Components: intg
Reporter: Madhan Neethiraj
Assignee: Madhan Neethiraj


GDS Python client needs to be update to support forceDelete flag in following 
REST APIs:
 # DELETE /service/gds/project/\{id}
 # DELETE /service/gds/dataset/\{id}
 # DELETE /service/gds/datashare/\{id}



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


[jira] [Commented] (RANGER-4793) Make HADOOPSQL Masking and Row Level Filter policies support wildcards by default

2024-05-20 Thread wangzhongwei (Jira)


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

wangzhongwei commented on RANGER-4793:
--

review board:https://reviews.apache.org/r/74999/

> Make HADOOPSQL Masking and Row Level Filter policies support wildcards by 
> default
> -
>
> Key: RANGER-4793
> URL: https://issues.apache.org/jira/browse/RANGER-4793
> Project: Ranger
>  Issue Type: Improvement
>  Components: plugins
>Affects Versions: 2.2.0, 2.3.0, 2.4.0
>Reporter: wangzhongwei
>Assignee: wangzhongwei
>Priority: Major
> Attachments: RANGER-4793.patch
>
>
>  Now ,in Access Policies ,input of database,table,and column support 
> wildcards,while  Masking and Row Level Filter do not work when using 
> wildcards. 



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


[jira] [Updated] (RANGER-4793) Make HADOOPSQL Masking and Row Level Filter policies support wildcards by default

2024-05-20 Thread wangzhongwei (Jira)


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

wangzhongwei updated RANGER-4793:
-
Attachment: RANGER-4793.patch

> Make HADOOPSQL Masking and Row Level Filter policies support wildcards by 
> default
> -
>
> Key: RANGER-4793
> URL: https://issues.apache.org/jira/browse/RANGER-4793
> Project: Ranger
>  Issue Type: Improvement
>  Components: plugins
>Affects Versions: 2.2.0, 2.3.0, 2.4.0
>Reporter: wangzhongwei
>Assignee: wangzhongwei
>Priority: Major
> Attachments: RANGER-4793.patch
>
>
>  Now ,in Access Policies ,input of database,table,and column support 
> wildcards,while  Masking and Row Level Filter do not work when using 
> wildcards. 



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


[jira] [Created] (RANGER-4793) Make HADOOPSQL Masking and Row Level Filter policies support wildcards by default

2024-05-20 Thread wangzhongwei (Jira)
wangzhongwei created RANGER-4793:


 Summary: Make HADOOPSQL Masking and Row Level Filter policies 
support wildcards by default
 Key: RANGER-4793
 URL: https://issues.apache.org/jira/browse/RANGER-4793
 Project: Ranger
  Issue Type: Improvement
  Components: plugins
Affects Versions: 2.4.0, 2.3.0, 2.2.0
Reporter: wangzhongwei
Assignee: wangzhongwei


 Now ,in Access Policies ,input of database,table,and column support 
wildcards,while  Masking and Row Level Filter do not work when using wildcards. 



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


[jira] [Resolved] (RANGER-4783) Prevent duplicate users/groups/roles in policy items while creating/updating policies via REST

2024-05-17 Thread Fateh Singh (Jira)


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

Fateh Singh resolved RANGER-4783.
-
Resolution: Fixed

[https://github.com/apache/ranger/commit/e6b83f34f527313dbfa80ab43fafd444203a0ab1]
 

> Prevent duplicate users/groups/roles in policy items while creating/updating 
> policies via REST
> --
>
> Key: RANGER-4783
> URL: https://issues.apache.org/jira/browse/RANGER-4783
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Reporter: Fateh Singh
>Assignee: Fateh Singh
>Priority: Major
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Policy items such as below should be prevented when created via REST as they 
> are prevented when created using UI
> {code:java}
>  
> "policyItems": [ { "accesses": [ { "type": "read", "isAllowed": true }, { 
> "type": "select", "isAllowed": true } ], "users": [], "groups": [ "group1", 
> "group1", "group1" ], "roles": [ "role1", "role2", "role1" ], "conditions": 
> [], "delegateAdmin": false } ]
>  
> {code}
>  



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


[jira] [Created] (RANGER-4792) Fix issue with creating index and import data in ElasticSearch as Audit database

2024-05-16 Thread ognjenit (Jira)
ognjenit created RANGER-4792:


 Summary: Fix issue with creating index and import data in 
ElasticSearch as Audit database
 Key: RANGER-4792
 URL: https://issues.apache.org/jira/browse/RANGER-4792
 Project: Ranger
  Issue Type: Bug
  Components: admin, audit
Affects Versions: 2.4.0
 Environment: Container:
- Linux: Debian buster
- Java: openjdk- 11
- Tested on kubernetes and openshift on AWS/Azure and on-prem
Reporter: ognjenit


Hi all,

I apologize in advance if I haven't adjusted this issue properly.

Short description:

I have deployed Trino with ranger-trino-plugin and I wanted to use 
ElasticSearch (7.10.2) as a place where I want to store the audit. When I 
configured ranger-admin to use elasticsearch (audit_store=elasticsearch and all 
other parameters audit_elasticsearch_*) I started getting errors in the 
catalina.out: java.lang.NoSuchFieldError: LUCENE_8_5_1. As I increased the 
version of Lucena, it was written in the logs that an even higher version was 
needed. So in the end, I moved it to 8.11.3 and 8.4.0 for lucene-spatial since 
it is the latest. 

After it was fixed, I tried to use https for elasticsearch protocol 
(audit_elasticsearch_protocol) however, it always showed that ranger-admin use 
http instead of https. I show in code that audit_elasticsearch_protocol is not 
configured well.

As soon as it done, ranger admin successfully created ES index. However, I need 
to move from MiscUtil.toDate to MiscUtil.toLocalDate for evtTime "column" since 
I was getting error: Error converting value to date. Value = 
2024-05-13T13:08:47.905Z

As soon as I fixed it, I found an error in Trino that the plugin couldn't 
insert data into elasticsearch. After I upgraded httpcomponents bug-fix 
version, it's started inserting data.

I opened PR with the fix 2.4.0 version, do I need to do the same on the master 
branch?

PR: https://github.com/apache/ranger/pull/314/files
h4. 1. Lucene version - fixed problem with writing data to ElasticSearch

{*}Error{*}: java.lang.NoSuchFieldError: LUCENE_8_5_1

I tried to change minor version one by one, but only latest version fit for me.

Changes:
 * agents-audit/pom.xml: 311
 * pom.xml: 241

h4. 2. Elastic search protocol - fixed problem with changing protocol

Even though I changed ranger.audit.elasticsearch.protocol from http to https, 
audit plugin still using http protocol.

Changes:
 * security-admin/scripts/ranger-admin-site-template.xml: 167-170
 * security-admin/scripts/setup.sh: 79, 794-797
 * security-admin/scripts/upgrade_admin.py: 116
 * security-admin/src/main/resources/conf.dist/ranger-admin-site.xml: 53-57
 * 
security-admin/src/test/java/org/apache/ranger/elasticsearch/ElasticSearchAccessAuditsServiceTest.java:
 56

h4. 3. Audit plugin - cannot write audit to ES

{*}Error{*}: bootstrap method initialization exception

After changing the version of httpcomponents I started seeing audit

Changes:
 * pom.xml: 137, 138, 140

h4. 4. Ranger admin console - Audit show 1-1-1970

{*}Erro{*}: Error converting value to date. Value = 2024-05-13T13:08:47.905Z

Even though evtTime was ok in ElasticSearch, ranger couldn't show it on GUI.

Changes:
 * 
security-admin/src/main/java/org/apache/ranger/elasticsearch/ElasticSearchAccessAuditsService.java:
 260
 * 
security-admin/src/main/java/org/apache/ranger/solr/SolrAccessAuditsService.java:
 239



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


[jira] [Commented] (RANGER-3409) Update Jackson and remove Codehaus version

2024-05-16 Thread Sercan Tekin (Jira)


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

Sercan Tekin commented on RANGER-3409:
--

[~n.blagodarny], I believe checking the policy editing/creating page will be 
sufficient in this case. Could you please try adding a user to a policy? I am 
not sure how your usersync is configured, but I think you will not be able to 
see system/LDAP users in the drop-down menu.

Here is an old UI screenshot for reference. When I encountered this issue, I 
noticed that no users were available to add:
 !ranger-modify-policy.png! 

During debugging, I found that while the functionality was intact, Jackson was 
unable to detect Java Bean class properties due to a camel case naming issue.

> Update Jackson and remove Codehaus version
> --
>
> Key: RANGER-3409
> URL: https://issues.apache.org/jira/browse/RANGER-3409
> Project: Ranger
>  Issue Type: Improvement
>  Components: Ranger
>Affects Versions: 3.0.0
>Reporter: Andrew Charneski
>Priority: Blocker
> Attachments: ranger-modify-policy.png
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> An old version of Jackson (Codehaus Jackson 1.9.13) is still being used. 
> Jackson has since moved namespaces with a reorganized library structure. 
> Update all references to the older version to use the newer version (which is 
> currently used in some modules).



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


[jira] [Updated] (RANGER-3409) Update Jackson and remove Codehaus version

2024-05-16 Thread Sercan Tekin (Jira)


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

Sercan Tekin updated RANGER-3409:
-
Attachment: ranger-modify-policy.png

> Update Jackson and remove Codehaus version
> --
>
> Key: RANGER-3409
> URL: https://issues.apache.org/jira/browse/RANGER-3409
> Project: Ranger
>  Issue Type: Improvement
>  Components: Ranger
>Affects Versions: 3.0.0
>Reporter: Andrew Charneski
>Priority: Blocker
> Attachments: ranger-modify-policy.png
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> An old version of Jackson (Codehaus Jackson 1.9.13) is still being used. 
> Jackson has since moved namespaces with a reorganized library structure. 
> Update all references to the older version to use the newer version (which is 
> currently used in some modules).



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


[jira] [Commented] (RANGER-3409) Update Jackson and remove Codehaus version

2024-05-16 Thread Nikita Blagodarnyi (Jira)


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

Nikita Blagodarnyi commented on RANGER-3409:


[~bpatel] [~sercan.tekin] would you mind to provide (if possible) detailed 
steps to reproduce users-related issue in your environment and this environment 
description (OS, jvm vendor/version, browser etc)? I used this command to 
build/run docker from my branch 
{code:java}
export RANGER_REBUILD=1 && export DOCKER_MAVEN_BUILD=0 && ./ranger_in_docker 
up{code}

> Update Jackson and remove Codehaus version
> --
>
> Key: RANGER-3409
> URL: https://issues.apache.org/jira/browse/RANGER-3409
> Project: Ranger
>  Issue Type: Improvement
>  Components: Ranger
>Affects Versions: 3.0.0
>Reporter: Andrew Charneski
>Priority: Blocker
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> An old version of Jackson (Codehaus Jackson 1.9.13) is still being used. 
> Jackson has since moved namespaces with a reorganized library structure. 
> Update all references to the older version to use the newer version (which is 
> currently used in some modules).



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


[jira] [Commented] (RANGER-4681) Audit logs for Mask & Row policy does not show policy condition under policy item

2024-05-16 Thread Brijesh Bhalala (Jira)


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

Brijesh Bhalala commented on RANGER-4681:
-

commited to [Apache 
master|https://github.com/apache/ranger/commit/301c8ff4155bb06b16037a2eb2bed237be4701c4]
 branch

> Audit logs for Mask & Row policy does not show policy condition under policy 
> item
> -
>
> Key: RANGER-4681
> URL: https://issues.apache.org/jira/browse/RANGER-4681
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Reporter: Vishal Bhavsar
>Assignee: Brijesh Bhalala
>Priority: Major
>  Labels: ranger-react
> Attachments: 0001-RANGER-4681.patch, 0002-RANGER-4681.patch, 
> 0003-RANGER-4681.patch, 0004-RANGER-4681.patch
>
>
> Audit logs for Mask & Row policy does not show policy condition under policy 
> item.
>  
> Steps to repro:
> 1) Inside Hive service, navigate hive masking policy listing page.
> 2) Click on "Add New Policy", add all the details. Under policy item section 
> add policy condition. Now save the policy
> 3) Go to Audits, Admin page, click on the audit record of above newly policy. 
> One modal would be opened which show all the details for the policy
> 4) Under "Row Level Filter Policy Items" section we would not see policy 
> condition details.



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


[jira] [Commented] (RANGER-3409) Update Jackson and remove Codehaus version

2024-05-15 Thread Bhavik Patel (Jira)


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

Bhavik Patel commented on RANGER-3409:
--

Correct [~sercan.tekin]. 

Just curious to know how it is working for [~n.blagodarny] .

> Update Jackson and remove Codehaus version
> --
>
> Key: RANGER-3409
> URL: https://issues.apache.org/jira/browse/RANGER-3409
> Project: Ranger
>  Issue Type: Improvement
>  Components: Ranger
>Affects Versions: 3.0.0
>Reporter: Andrew Charneski
>Priority: Blocker
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> An old version of Jackson (Codehaus Jackson 1.9.13) is still being used. 
> Jackson has since moved namespaces with a reorganized library structure. 
> Update all references to the older version to use the newer version (which is 
> currently used in some modules).



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


[jira] [Commented] (RANGER-3409) Update Jackson and remove Codehaus version

2024-05-15 Thread Sercan Tekin (Jira)


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

Sercan Tekin commented on RANGER-3409:
--

[~bpatel], this is what I described and proposed solution in 
https://issues.apache.org/jira/browse/RANGER-4225.
Issue -> 
[https://stackoverflow.com/questions/30205006/why-does-jackson-2-not-recognize-the-first-capital-letter-if-the-leading-camel-c]
Solution -> [https://github.com/apache/ranger/pull/252]

FYI

> Update Jackson and remove Codehaus version
> --
>
> Key: RANGER-3409
> URL: https://issues.apache.org/jira/browse/RANGER-3409
> Project: Ranger
>  Issue Type: Improvement
>  Components: Ranger
>Affects Versions: 3.0.0
>Reporter: Andrew Charneski
>Priority: Blocker
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> An old version of Jackson (Codehaus Jackson 1.9.13) is still being used. 
> Jackson has since moved namespaces with a reorganized library structure. 
> Update all references to the older version to use the newer version (which is 
> currently used in some modules).



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


[jira] [Commented] (RANGER-3409) Update Jackson and remove Codehaus version

2024-05-15 Thread Bhavik Patel (Jira)


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

Bhavik Patel commented on RANGER-3409:
--

Thanks [~n.blagodarny] . While validating your changes I observed users are not 
visible in the ranger admin web ui. After debugging found that while migrating 
from Codehaus Jackson to FasterXML Jackson property naming strategy was changed 
to lowercase and on the frontend we are expecting the original object(without 
any conversion).

 

Just wondering how does this worked for you.

 

> Update Jackson and remove Codehaus version
> --
>
> Key: RANGER-3409
> URL: https://issues.apache.org/jira/browse/RANGER-3409
> Project: Ranger
>  Issue Type: Improvement
>  Components: Ranger
>Affects Versions: 3.0.0
>Reporter: Andrew Charneski
>Priority: Blocker
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> An old version of Jackson (Codehaus Jackson 1.9.13) is still being used. 
> Jackson has since moved namespaces with a reorganized library structure. 
> Update all references to the older version to use the newer version (which is 
> currently used in some modules).



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


[jira] [Commented] (RANGER-4791) Fixing build issue for Phantomjs Auto configuration failed due to OPEN_SSL

2024-05-14 Thread Mugdha Varadkar (Jira)


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

Mugdha Varadkar commented on RANGER-4791:
-

[~pushkargogte], Please help in verifying the attached patch on Docker build. 
Thanks

> Fixing build issue for Phantomjs Auto configuration failed due to OPEN_SSL
> --
>
> Key: RANGER-4791
> URL: https://issues.apache.org/jira/browse/RANGER-4791
> Project: Ranger
>  Issue Type: Bug
>  Components: admin
>Reporter: Mugdha Varadkar
>Assignee: Mugdha Varadkar
>Priority: Major
> Attachments: 0001-RANGER-4791.patch
>
>
> Ranger build for redhat9 is failing for security-admin module for phantomjs 
> auto configuration failed.
> Below is the log trace,
> {code}
> 10:53:58 2024/05/08 05:23:58 INFO: [INFO] 08 05 2024 05:23:58.533:INFO 
> [launcher]: Starting browser PhantomJS
> 10:53:58 2024/05/08 05:23:58 INFO: [INFO] 08 05 2024 05:23:58.565:ERROR 
> [phantomjs.launcher]: Auto configuration failed
> 10:53:58 2024/05/08 05:23:58 INFO: [INFO] 
> 139820265396032:error:25066067:DSO support routines:DLFCN_LOAD:could not load 
> the shared library:dso_dlfcn.c:185:filename(libproviders.so): 
> libproviders.so: cannot open shared object file: No such file or directory
> 10:53:58 2024/05/08 05:23:58 INFO: [INFO] 
> 139820265396032:error:25070067:DSO support routines:DSO_load:could not load 
> the shared library:dso_lib.c:244:
> 10:53:58 2024/05/08 05:23:58 INFO: [INFO] 
> 139820265396032:error:0E07506E:configuration file 
> routines:MODULE_LOAD_DSO:error loading dso:conf_mod.c:285:module=providers, 
> path=providers
> 10:53:58 2024/05/08 05:23:58 INFO: [INFO] 
> 139820265396032:error:0E076071:configuration file routines:MODULE_RUN:unknown 
> module name:conf_mod.c:222:module=providers
> 10:53:58 2024/05/08 05:23:58 INFO: [INFO]
> 10:53:58 2024/05/08 05:23:58 INFO: [INFO] 08 05 2024 05:23:58.571:ERROR 
> [launcher]: Cannot start PhantomJS
> 10:53:58 2024/05/08 05:23:58 INFO: [INFO] Auto configuration 
> failed
> 10:53:58 2024/05/08 05:23:58 INFO: [INFO] 
> 139820265396032:error:25066067:DSO support routines:DLFCN_LOAD:could not load 
> the shared library:dso_dlfcn.c:185:filename(libproviders.so): 
> libproviders.so: cannot open shared object file: No such file or directory
> 10:53:58 2024/05/08 05:23:58 INFO: [INFO] 
> 139820265396032:error:25070067:DSO support routines:DSO_load:could not load 
> the shared library:dso_lib.c:244:
> 10:53:58 2024/05/08 05:23:58 INFO: [INFO] 
> 139820265396032:error:0E07506E:configuration file 
> routines:MODULE_LOAD_DSO:error loading dso:conf_mod.c:285:module=providers, 
> path=providers
> 10:53:58 2024/05/08 05:23:58 INFO: [INFO] 
> 139820265396032:error:0E076071:configuration file routines:MODULE_RUN:unknown 
> module name:conf_mod.c:222:module=providers
> 10:53:58 2024/05/08 05:23:58 INFO: [INFO]
> 10:53:58 2024/05/08 05:23:58 INFO: [INFO] 08 05 2024 05:23:58.571:ERROR 
> [launcher]: PhantomJS stdout:
> 10:53:58 2024/05/08 05:23:58 INFO: [INFO] 08 05 2024 05:23:58.571:ERROR 
> [launcher]: PhantomJS stderr: Auto configuration failed
> {code}



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


[jira] [Updated] (RANGER-4791) Fixing build issue for Phantomjs Auto configuration failed due to OPEN_SSL

2024-05-14 Thread Mugdha Varadkar (Jira)


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

Mugdha Varadkar updated RANGER-4791:

Attachment: 0001-RANGER-4791.patch

> Fixing build issue for Phantomjs Auto configuration failed due to OPEN_SSL
> --
>
> Key: RANGER-4791
> URL: https://issues.apache.org/jira/browse/RANGER-4791
> Project: Ranger
>  Issue Type: Bug
>  Components: admin
>Reporter: Mugdha Varadkar
>Assignee: Mugdha Varadkar
>Priority: Major
> Attachments: 0001-RANGER-4791.patch
>
>
> Ranger build for redhat9 is failing for security-admin module for phantomjs 
> auto configuration failed.
> Below is the log trace,
> {code}
> 10:53:58 2024/05/08 05:23:58 INFO: [INFO] 08 05 2024 05:23:58.533:INFO 
> [launcher]: Starting browser PhantomJS
> 10:53:58 2024/05/08 05:23:58 INFO: [INFO] 08 05 2024 05:23:58.565:ERROR 
> [phantomjs.launcher]: Auto configuration failed
> 10:53:58 2024/05/08 05:23:58 INFO: [INFO] 
> 139820265396032:error:25066067:DSO support routines:DLFCN_LOAD:could not load 
> the shared library:dso_dlfcn.c:185:filename(libproviders.so): 
> libproviders.so: cannot open shared object file: No such file or directory
> 10:53:58 2024/05/08 05:23:58 INFO: [INFO] 
> 139820265396032:error:25070067:DSO support routines:DSO_load:could not load 
> the shared library:dso_lib.c:244:
> 10:53:58 2024/05/08 05:23:58 INFO: [INFO] 
> 139820265396032:error:0E07506E:configuration file 
> routines:MODULE_LOAD_DSO:error loading dso:conf_mod.c:285:module=providers, 
> path=providers
> 10:53:58 2024/05/08 05:23:58 INFO: [INFO] 
> 139820265396032:error:0E076071:configuration file routines:MODULE_RUN:unknown 
> module name:conf_mod.c:222:module=providers
> 10:53:58 2024/05/08 05:23:58 INFO: [INFO]
> 10:53:58 2024/05/08 05:23:58 INFO: [INFO] 08 05 2024 05:23:58.571:ERROR 
> [launcher]: Cannot start PhantomJS
> 10:53:58 2024/05/08 05:23:58 INFO: [INFO] Auto configuration 
> failed
> 10:53:58 2024/05/08 05:23:58 INFO: [INFO] 
> 139820265396032:error:25066067:DSO support routines:DLFCN_LOAD:could not load 
> the shared library:dso_dlfcn.c:185:filename(libproviders.so): 
> libproviders.so: cannot open shared object file: No such file or directory
> 10:53:58 2024/05/08 05:23:58 INFO: [INFO] 
> 139820265396032:error:25070067:DSO support routines:DSO_load:could not load 
> the shared library:dso_lib.c:244:
> 10:53:58 2024/05/08 05:23:58 INFO: [INFO] 
> 139820265396032:error:0E07506E:configuration file 
> routines:MODULE_LOAD_DSO:error loading dso:conf_mod.c:285:module=providers, 
> path=providers
> 10:53:58 2024/05/08 05:23:58 INFO: [INFO] 
> 139820265396032:error:0E076071:configuration file routines:MODULE_RUN:unknown 
> module name:conf_mod.c:222:module=providers
> 10:53:58 2024/05/08 05:23:58 INFO: [INFO]
> 10:53:58 2024/05/08 05:23:58 INFO: [INFO] 08 05 2024 05:23:58.571:ERROR 
> [launcher]: PhantomJS stdout:
> 10:53:58 2024/05/08 05:23:58 INFO: [INFO] 08 05 2024 05:23:58.571:ERROR 
> [launcher]: PhantomJS stderr: Auto configuration failed
> {code}



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


[jira] [Created] (RANGER-4791) Fixing build issue for Phantomjs Auto configuration failed due to OPEN_SSL

2024-05-14 Thread Mugdha Varadkar (Jira)
Mugdha Varadkar created RANGER-4791:
---

 Summary: Fixing build issue for Phantomjs Auto configuration 
failed due to OPEN_SSL
 Key: RANGER-4791
 URL: https://issues.apache.org/jira/browse/RANGER-4791
 Project: Ranger
  Issue Type: Bug
  Components: admin
Reporter: Mugdha Varadkar
Assignee: Mugdha Varadkar


Ranger build for redhat9 is failing for security-admin module for phantomjs 
auto configuration failed.

Below is the log trace,

{code}
10:53:58 2024/05/08 05:23:58 INFO: [INFO] 08 05 2024 05:23:58.533:INFO 
[launcher]: Starting browser PhantomJS
10:53:58 2024/05/08 05:23:58 INFO: [INFO] 08 05 2024 05:23:58.565:ERROR 
[phantomjs.launcher]: Auto configuration failed
10:53:58 2024/05/08 05:23:58 INFO: [INFO] 
139820265396032:error:25066067:DSO support routines:DLFCN_LOAD:could not load 
the shared library:dso_dlfcn.c:185:filename(libproviders.so): libproviders.so: 
cannot open shared object file: No such file or directory
10:53:58 2024/05/08 05:23:58 INFO: [INFO] 
139820265396032:error:25070067:DSO support routines:DSO_load:could not load the 
shared library:dso_lib.c:244:
10:53:58 2024/05/08 05:23:58 INFO: [INFO] 
139820265396032:error:0E07506E:configuration file 
routines:MODULE_LOAD_DSO:error loading dso:conf_mod.c:285:module=providers, 
path=providers
10:53:58 2024/05/08 05:23:58 INFO: [INFO] 
139820265396032:error:0E076071:configuration file routines:MODULE_RUN:unknown 
module name:conf_mod.c:222:module=providers
10:53:58 2024/05/08 05:23:58 INFO: [INFO]
10:53:58 2024/05/08 05:23:58 INFO: [INFO] 08 05 2024 05:23:58.571:ERROR 
[launcher]: Cannot start PhantomJS
10:53:58 2024/05/08 05:23:58 INFO: [INFO]   Auto configuration failed
10:53:58 2024/05/08 05:23:58 INFO: [INFO] 
139820265396032:error:25066067:DSO support routines:DLFCN_LOAD:could not load 
the shared library:dso_dlfcn.c:185:filename(libproviders.so): libproviders.so: 
cannot open shared object file: No such file or directory
10:53:58 2024/05/08 05:23:58 INFO: [INFO] 
139820265396032:error:25070067:DSO support routines:DSO_load:could not load the 
shared library:dso_lib.c:244:
10:53:58 2024/05/08 05:23:58 INFO: [INFO] 
139820265396032:error:0E07506E:configuration file 
routines:MODULE_LOAD_DSO:error loading dso:conf_mod.c:285:module=providers, 
path=providers
10:53:58 2024/05/08 05:23:58 INFO: [INFO] 
139820265396032:error:0E076071:configuration file routines:MODULE_RUN:unknown 
module name:conf_mod.c:222:module=providers
10:53:58 2024/05/08 05:23:58 INFO: [INFO]
10:53:58 2024/05/08 05:23:58 INFO: [INFO] 08 05 2024 05:23:58.571:ERROR 
[launcher]: PhantomJS stdout:
10:53:58 2024/05/08 05:23:58 INFO: [INFO] 08 05 2024 05:23:58.571:ERROR 
[launcher]: PhantomJS stderr: Auto configuration failed
{code}



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


[jira] [Commented] (RANGER-4643) Upgrade react-bootstrap library for GDS UI.

2024-05-13 Thread Dhaval Rajpara (Jira)


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

Dhaval Rajpara commented on RANGER-4643:


Patch committed to [Apache 
master|https://github.com/apache/ranger/commit/bf114e65529aa0399b67e56da4ef74f14def8f63]
 branch.

> Upgrade react-bootstrap library for GDS UI.
> ---
>
> Key: RANGER-4643
> URL: https://issues.apache.org/jira/browse/RANGER-4643
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Reporter: Dhaval Rajpara
>Assignee: Dhaval Rajpara
>Priority: Major
> Attachments: 
> 0001-RANGER-4643-Upgrade-react-bootstrap-library-for-GDS-.patch
>
>




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


[jira] [Updated] (RANGER-4681) Audit logs for Mask & Row policy does not show policy condition under policy item

2024-05-13 Thread Brijesh Bhalala (Jira)


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

Brijesh Bhalala updated RANGER-4681:

Attachment: 0004-RANGER-4681.patch

> Audit logs for Mask & Row policy does not show policy condition under policy 
> item
> -
>
> Key: RANGER-4681
> URL: https://issues.apache.org/jira/browse/RANGER-4681
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Reporter: Vishal Bhavsar
>Assignee: Brijesh Bhalala
>Priority: Major
>  Labels: ranger-react
> Attachments: 0001-RANGER-4681.patch, 0002-RANGER-4681.patch, 
> 0003-RANGER-4681.patch, 0004-RANGER-4681.patch
>
>
> Audit logs for Mask & Row policy does not show policy condition under policy 
> item.
>  
> Steps to repro:
> 1) Inside Hive service, navigate hive masking policy listing page.
> 2) Click on "Add New Policy", add all the details. Under policy item section 
> add policy condition. Now save the policy
> 3) Go to Audits, Admin page, click on the audit record of above newly policy. 
> One modal would be opened which show all the details for the policy
> 4) Under "Row Level Filter Policy Items" section we would not see policy 
> condition details.



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


[jira] [Updated] (RANGER-4681) Audit logs for Mask & Row policy does not show policy condition under policy item

2024-05-13 Thread Brijesh Bhalala (Jira)


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

Brijesh Bhalala updated RANGER-4681:

Attachment: (was: 0004-RANGER_4681.patch)

> Audit logs for Mask & Row policy does not show policy condition under policy 
> item
> -
>
> Key: RANGER-4681
> URL: https://issues.apache.org/jira/browse/RANGER-4681
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Reporter: Vishal Bhavsar
>Assignee: Brijesh Bhalala
>Priority: Major
>  Labels: ranger-react
> Attachments: 0001-RANGER-4681.patch, 0002-RANGER-4681.patch, 
> 0003-RANGER-4681.patch
>
>
> Audit logs for Mask & Row policy does not show policy condition under policy 
> item.
>  
> Steps to repro:
> 1) Inside Hive service, navigate hive masking policy listing page.
> 2) Click on "Add New Policy", add all the details. Under policy item section 
> add policy condition. Now save the policy
> 3) Go to Audits, Admin page, click on the audit record of above newly policy. 
> One modal would be opened which show all the details for the policy
> 4) Under "Row Level Filter Policy Items" section we would not see policy 
> condition details.



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


[jira] [Updated] (RANGER-4681) Audit logs for Mask & Row policy does not show policy condition under policy item

2024-05-13 Thread Brijesh Bhalala (Jira)


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

Brijesh Bhalala updated RANGER-4681:

Attachment: 0004-RANGER_4681.patch

> Audit logs for Mask & Row policy does not show policy condition under policy 
> item
> -
>
> Key: RANGER-4681
> URL: https://issues.apache.org/jira/browse/RANGER-4681
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Reporter: Vishal Bhavsar
>Assignee: Brijesh Bhalala
>Priority: Major
>  Labels: ranger-react
> Attachments: 0001-RANGER-4681.patch, 0002-RANGER-4681.patch, 
> 0003-RANGER-4681.patch
>
>
> Audit logs for Mask & Row policy does not show policy condition under policy 
> item.
>  
> Steps to repro:
> 1) Inside Hive service, navigate hive masking policy listing page.
> 2) Click on "Add New Policy", add all the details. Under policy item section 
> add policy condition. Now save the policy
> 3) Go to Audits, Admin page, click on the audit record of above newly policy. 
> One modal would be opened which show all the details for the policy
> 4) Under "Row Level Filter Policy Items" section we would not see policy 
> condition details.



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


[jira] [Resolved] (RANGER-4790) Request to support GDS policy import and export

2024-05-08 Thread Monika kachhadiya (Jira)


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

Monika kachhadiya resolved RANGER-4790.
---
Resolution: Invalid

> Request to support GDS policy import and export
> ---
>
> Key: RANGER-4790
> URL: https://issues.apache.org/jira/browse/RANGER-4790
> Project: Ranger
>  Issue Type: Improvement
>  Components: Ranger
>Reporter: Monika kachhadiya
>Priority: Major
>
> A feature enhancement is needed so that GDS policies can be imported and 
> exported.
> More information on the use case
>  * Incremental Backups so that any changes can be rollback
>  *  Audit existing GDS policies so we can catch any possible vulnerability. 
>  * For testing purposes, need to synchronize a lower (staging) environment 
> with a higher (prod) environment.
>  * want to periodically take backup of gds (domains and datasets)
>  * Sometimes we want to rebuild the domains and datasets using these backups. 
> this is the import use case.
>  * periodically tear down and recreate gds setups with automation
>  



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


[jira] [Commented] (RANGER-4790) Request to support GDS policy import and export

2024-05-08 Thread Monika kachhadiya (Jira)


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

Monika kachhadiya commented on RANGER-4790:
---

Marking this as invalid since this will need more than just importing/exporting 
 policies. It will also need import/export of GDS components. 

> Request to support GDS policy import and export
> ---
>
> Key: RANGER-4790
> URL: https://issues.apache.org/jira/browse/RANGER-4790
> Project: Ranger
>  Issue Type: Improvement
>  Components: Ranger
>Reporter: Monika kachhadiya
>Priority: Major
>
> A feature enhancement is needed so that GDS policies can be imported and 
> exported.
> More information on the use case
>  * Incremental Backups so that any changes can be rollback
>  *  Audit existing GDS policies so we can catch any possible vulnerability. 
>  * For testing purposes, need to synchronize a lower (staging) environment 
> with a higher (prod) environment.
>  * want to periodically take backup of gds (domains and datasets)
>  * Sometimes we want to rebuild the domains and datasets using these backups. 
> this is the import use case.
>  * periodically tear down and recreate gds setups with automation
>  



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


[jira] [Updated] (RANGER-4790) Request to support GDS policy import and export

2024-05-08 Thread Monika kachhadiya (Jira)


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

Monika kachhadiya updated RANGER-4790:
--
Description: 
A feature enhancement is needed so that GDS policies can be imported and 
exported.

More information on the use case
 * Incremental Backups so that any changes can be rollback

 *  Audit existing GDS policies so we can catch any possible vulnerability. 

 * For testing purposes, need to synchronize a lower (staging) environment with 
a higher (prod) environment.
 * want to periodically take backup of gds (domains and datasets)
 * Sometimes we want to rebuild the domains and datasets using these backups. 
this is the import use case.
 * periodically tear down and recreate gds setups with automation
 

  was:
A feature enhancement is needed so that GDS policies can be imported and 
exported.

More information on the use case
 # Incremental Backups so that any changes can be rollback

 #  Audit existing GDS policies so we can catch any possible vulnerability. 

 # For testing purposes, need to synchronize a lower (staging) environment with 
a higher (prod) environment.
        4.  want to periodically take backup of gds (domains and datasets)
         5. Sometimes we want to rebuild the domains and datasets using these 
backups. this is the import use case.
         6.  periodically tear down and recreate gds setups with automation
 


> Request to support GDS policy import and export
> ---
>
> Key: RANGER-4790
> URL: https://issues.apache.org/jira/browse/RANGER-4790
> Project: Ranger
>  Issue Type: Improvement
>  Components: Ranger
>Reporter: Monika kachhadiya
>Priority: Major
>
> A feature enhancement is needed so that GDS policies can be imported and 
> exported.
> More information on the use case
>  * Incremental Backups so that any changes can be rollback
>  *  Audit existing GDS policies so we can catch any possible vulnerability. 
>  * For testing purposes, need to synchronize a lower (staging) environment 
> with a higher (prod) environment.
>  * want to periodically take backup of gds (domains and datasets)
>  * Sometimes we want to rebuild the domains and datasets using these backups. 
> this is the import use case.
>  * periodically tear down and recreate gds setups with automation
>  



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


[jira] [Created] (RANGER-4790) Request to support GDS policy import and export

2024-05-08 Thread Monika kachhadiya (Jira)
Monika kachhadiya created RANGER-4790:
-

 Summary: Request to support GDS policy import and export
 Key: RANGER-4790
 URL: https://issues.apache.org/jira/browse/RANGER-4790
 Project: Ranger
  Issue Type: Improvement
  Components: Ranger
Reporter: Monika kachhadiya


A feature enhancement is needed so that GDS policies can be imported and 
exported.

More information on the use case
 # Incremental Backups so that any changes can be rollback

 #  Audit existing GDS policies so we can catch any possible vulnerability. 

 # For testing purposes, need to synchronize a lower (staging) environment with 
a higher (prod) environment.
        4.  want to periodically take backup of gds (domains and datasets)
         5. Sometimes we want to rebuild the domains and datasets using these 
backups. this is the import use case.
         6.  periodically tear down and recreate gds setups with automation
 



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


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

2024-05-07 Thread kirby zhou (Jira)


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

kirby zhou commented on RANGER-3998:


It gets 2 ship now.

Who can merge it ?

> Support Ranger KMS integration with AWS KMS
> ---
>
> Key: RANGER-3998
> URL: https://issues.apache.org/jira/browse/RANGER-3998
> Project: Ranger
>  Issue Type: Improvement
>  Components: kms
>Affects Versions: 3.0.0, 2.4.0
>Reporter: kirby zhou
>Assignee: kirby zhou
>Priority: Major
>
> AWS KMS is widely used by many customers.
> Therefore, RangerKMS should support hosting MasterKey to AWS KMS.
>  



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


[jira] [Assigned] (RANGER-4782) Implement best coding practices for validating service configs

2024-05-07 Thread Rakesh Gupta (Jira)


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

Rakesh Gupta reassigned RANGER-4782:


Assignee: Rakesh Gupta  (was: Sanket Shelar)

> Implement best coding practices for validating service configs
> --
>
> Key: RANGER-4782
> URL: https://issues.apache.org/jira/browse/RANGER-4782
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Reporter: Sanket Shelar
>Assignee: Rakesh Gupta
>Priority: Major
>
> Implement best coding practices for validating service configs



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


[jira] [Commented] (RANGER-3409) Update Jackson and remove Codehaus version

2024-05-06 Thread Nikita Blagodarnyi (Jira)


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

Nikita Blagodarnyi commented on RANGER-3409:


[~bpatel] please refer to [https://github.com/apache/ranger/pull/312] . This PR 
completely removes the jackson-1.x dependency from Ranger. 

> Update Jackson and remove Codehaus version
> --
>
> Key: RANGER-3409
> URL: https://issues.apache.org/jira/browse/RANGER-3409
> Project: Ranger
>  Issue Type: Improvement
>  Components: Ranger
>Affects Versions: 3.0.0
>Reporter: Andrew Charneski
>Priority: Blocker
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> An old version of Jackson (Codehaus Jackson 1.9.13) is still being used. 
> Jackson has since moved namespaces with a reorganized library structure. 
> Update all references to the older version to use the newer version (which is 
> currently used in some modules).



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


[jira] [Commented] (RANGER-4225) Possible Jackson serialization issue due to not comply with Java bean standards

2024-05-06 Thread Nikita Blagodarnyi (Jira)


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

Nikita Blagodarnyi commented on RANGER-4225:


[~bpatel] please refer to [https://github.com/apache/ranger/pull/312] . This PR 
completely removes the jackson-1.x dependency from Ranger. 

> Possible Jackson serialization issue due to not comply with Java bean 
> standards
> ---
>
> Key: RANGER-4225
> URL: https://issues.apache.org/jira/browse/RANGER-4225
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Affects Versions: 2.4.0
>Reporter: Sercan Tekin
>Assignee: Sercan Tekin
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: RANGER-4225.patch
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> +*PROBLEM:*+
> Transitive Jackson-2 dependencies are included into Ranger's classpath in my 
> env and conflicted with Jackson-1 dependencies.
> Jackson-2 uses Javabean naming conventions to figure out the Json properties 
> in a Java class, and some of the Ranger's model classes don't comply with the 
> convention.
> For example, when the leading camelcase word is only one letter in length, 
> then deserialized response is broken. The following is what I observed in 
> Ranger v2.4.0;
> On Ranger UI side, this 
> [code-block|https://github.com/apache/ranger/blob/ranger-1.2/security-admin/src/main/webapp/scripts/views/policies/PermissionList.js#L224-L229]
>  attempts to read vXStrings key in map, but the corresponding response has 
> vxstrings instead:
> {code:java}
> {
> "startIndex": 0,
> "pageSize": 200,
> "totalCount": 11,
> "resultSize": 11,
> "sortType": "asc",
> "sortBy": "id",
> "listSize": 11,
> "vxstrings": [< here! This has to be vXStrings
> {
> "value": "public",
> ... {code}
> And this difference causes below error while reading the property, therefore 
> the corresponding dropdown has no values as excepted;
> {code:java}
> PermissionList.js?ver=build.version:226 Uncaught TypeError: Cannot read 
> properties of undefined (reading 'map')
> at Object.results (PermissionList.js?ver=build.version:226:34)
> at Object.success (select2.js?ver=build.version:450:47)
> at u (jquery-3.3.1.min.js?ver=build.version:2:27457)
> at Object.fireWith [as resolveWith] 
> (jquery-3.3.1.min.js?ver=build.version:2:28202)
> at k (jquery-3.3.1.min.js?ver=build.version:2:77651)
> at XMLHttpRequest. 
> (jquery-3.3.1.min.js?ver=build.version:2:79907){code}
> +*REFERENCES:*+
> Please see this reference related to capital letters 
> [http://futuretask.blogspot.com/2005/01/java-tip-6-dont-capitalize-first-two.html]
> "Don't capitalize first two letters of a bean property name. This is in our 
> java standards. You should not create a java bean property name that begins 
> with a capital letter in the 1st two places."
> Also you can see the same issue is reported here 
> [https://stackoverflow.com/questions/30205006/why-does-jackson-2-not-recognize-the-first-capital-letter-if-the-leading-camel-c]
>  
> +*SOLUTION:*+
> {{@JsonProperty}} annotation needs to be added for mapping the properties 
> with their corresponding getter/setter methods. This will not effect Ranger's 
> functionality directly, but it will provide consistency even if Jackson-2 is 
> included into classpath.
> I have tested it locally after adding {{@JsonProperty}} and everything worked 
> well.
> The PR is attached.



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


  1   2   3   4   5   6   7   8   9   10   >