[jira] [Commented] (RANGER-4640) Ranger Support for Trino 433

[Shreyas B (Jira)]

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

Shreyas B commented on RANGER-4640:
---

PR: https://github.com/apache/ranger/pull/291

> Ranger Support for Trino 433 
> -
>
> Key: RANGER-4640
> URL: https://issues.apache.org/jira/browse/RANGER-4640
> Project: Ranger
>  Issue Type: Improvement
>  Components: plugins
>Reporter: Shreyas B
>Priority: Minor
>
> Trino has reached 4XX version whereas official ranger trino plugin support is 
> till 377 which was the trino version 2 years. Maybe it's time to update 
> ranger-trino plugin? 



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

[jira] [Created] (RANGER-4640) Ranger Support for Trino 433

[Shreyas B (Jira)]

Shreyas B created RANGER-4640:
-

 Summary: Ranger Support for Trino 433 
 Key: RANGER-4640
 URL: https://issues.apache.org/jira/browse/RANGER-4640
 Project: Ranger
  Issue Type: Improvement
  Components: plugins
Reporter: Shreyas B


Trino has reached 4XX version whereas official ranger trino plugin support is 
till 377 which was the trino version 2 years. Maybe it's time to update 
ranger-trino plugin? 



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

Review Request 74825: RANGER-4638:Multiple Columns Revoke not generating policies with correct number of columns

[Ramesh Mani]

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

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


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


Repository: ranger


Description
---

RANGER-4638:Multiple Columns Revoke not generating policies with correct number 
of columns


Diffs
-

  
agents-common/src/main/java/org/apache/ranger/plugin/policyevaluator/RangerDefaultPolicyEvaluator.java
 7fe2a2eb3 
  
agents-common/src/main/java/org/apache/ranger/plugin/policyevaluator/RangerPolicyEvaluator.java
 0a14b387a 
  
agents-common/src/main/java/org/apache/ranger/plugin/policyresourcematcher/RangerDefaultPolicyResourceMatcher.java
 f16157ce6 
  
agents-common/src/main/java/org/apache/ranger/plugin/policyresourcematcher/RangerPolicyResourceMatcher.java
 e1cd89b70 
  
agents-common/src/main/java/org/apache/ranger/plugin/resourcematcher/RangerAbstractResourceMatcher.java
 5eee8d11a 
  
agents-common/src/main/java/org/apache/ranger/plugin/resourcematcher/RangerResourceMatcher.java
 ec22e01bf 
  
agents-common/src/test/java/org/apache/ranger/plugin/resourcematcher/TestDefaultPolicyResourceisCompleteOrSomeMatchMatcher.java
 PRE-CREATION 
  
agents-common/src/test/resources/resourcematcher/test_defaultpolicyresource_isCompleteOrSomeMatch_matcher.json
 PRE-CREATION 
  security-admin/src/main/java/org/apache/ranger/biz/RangerPolicyAdmin.java 
15a1e7118 
  security-admin/src/main/java/org/apache/ranger/biz/RangerPolicyAdminImpl.java 
84ee31ba2 
  security-admin/src/main/java/org/apache/ranger/rest/ServiceREST.java 
cc9df27d6 
  security-admin/src/main/java/org/apache/ranger/rest/ServiceRESTUtil.java 
60e34c0c7 
  security-admin/src/test/java/org/apache/ranger/rest/TestServiceREST.java 
a630e575b 


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


Testing
---

Impala / Hive beeline.

1) "grant select(col1, col2, col3)  on table demo.test  to role Role1"  => 
Create a Grant Policy for the given resource in Hadoop Sql
   

2) "grant select(col1, col2, col3, col4)  on table demo.test  to role Role1"  
=> updates the policy created in #1 with new col4 resource

 if  "revoke select(col1, col2, col3, col4) on table demo.test from role 
Role1" is done => Since all the columns are revoked for Select, we delete the 
policy created in #1
 if  "revoke select(col1, col2, col3) on table demo.test from role Role1" 
is done => policy created in #1 will be updated to remove col1,col2,col3 from 
the policy to revoke the access.

HBASE shell

grant 'nifi', 'RWXCA', 'test'  => create policy with 'RWXCA' access for user 
nifi on table 'test'.


revoke 'nifi', 'test' => revoke access for user "nifi" on hbase table 'test'. 
Here policy will be removed.


Thanks,

Ramesh Mani

Branch RANGER-3923 merged into master branch

[Madhan Neethiraj]

Rangers,

Governed Data Sharing feature implementation in RANGER-3923 is now merged into 
master branch. Any further commits for this feature should land in master 
branch, instead of RANGER-3923 branch. Thank you all for your contributions for 
this significant feature in Apache Ranger.

Looking forward to Apache Ranger 3.0 release containing this feature.

Thanks,
Madhan

On 1/7/24, 8:12 PM, "Madhan Neethiraj" mailto:mad...@apache.org>> wrote:


Rangers,


FYI. I will be merging RANGER-3923 branch to master on Jan-08, Monday.


Thanks,
Madhan


On 1/3/24, 2:20 PM, "Ramesh Mani" mailto:rm...@apache.org> 
>> wrote:




+1 for merging the RANGER-3923 branch into master. Thanks Madhan for
the effort. This is a significant enhancement enabling datasets'
authorization and auditing.




Regards,
Ramesh








On Tue, Jan 2, 2024 at 3:01 PM Madhan Neethiraj mailto:mad...@apache.org> >> wrote:




> (apologies for the resend; earlier mail had HTML formatting which got
> lost, now sending in plain text format)
>
> Rangers,
>
> For more than a year now, Apache Ranger community has been adding
> significant enhancements in RANGER-3923 branch. These enhancements enable
> business managers to manage access to datasets, instead of having data
> owners to manage access to individual resources like tables, columns,
> files, directories.
>
> In addition, this approach offers several benefits including:
> - reduced time for users in getting access to data across multiple
> services, with a single policy update.
> - business managers like project managers to manage access to datasets
> instead of multiple data owners, which reduces the time taken to get access
> to data.
> - separation of responsibilities: data owners focus on building
> datasets, while business managers focus on managing access to datasets.
> - eliminate the need to update access policies for any changes in
> datasets like add/remove/change resources.
>
> Apache Ranger community has built APIs and UI to manage datasets and
> access to datasets. Apache Ranger policy engine has been updated as well to
> support datasets. I propose merging these enhancements into master branch
> this week, and work towards releasing Apache Ranger 3.0 version, by next
> month. Please share your feedback.
>
> Looking forward to Apache Ranger 3.0 release!
>
> Thanks,
> Madhan
>
>
>

Re: [PR] Update trino-plugin to be compatible with the latest Trino SPI (version 433) [ranger]

[via GitHub]

deebify commented on PR #290:
URL: https://github.com/apache/ranger/pull/290#issuecomment-1882389974

   @okayhooni  can you share your maven build command for ranger and trino 
plugin? I tried to build your fork with JDK 17 but getting errors 
   
   
   `[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-war-plugin:2.6:exploded (prepare) on project 
security-admin-web: Execution prepare of goal 
org.apache.maven.plugins:maven-war-plugin:2.6:exploded failed: Unable to load 
the mojo 'exploded' in the plugin 
'org.apache.maven.plugins:maven-war-plugin:2.6' due to an API incompatibility: 
org.codehaus.plexus.component.repository.exception.ComponentLookupException: 
null`
   
   
   I build by the following command: 
   
   `mvn -DskipTests=true clean compile package install`


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@ranger.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: Review Request 74823: RANGER-4639: Provide an option to bypass evaluation of chained plugin if the parent plugin has applicable policy

[Madhan Neethiraj]

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


Ship it!




Ship It!

- Madhan Neethiraj


On Jan. 8, 2024, 10:20 p.m., Abhay Kulkarni wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/74823/
> ---
> 
> (Updated Jan. 8, 2024, 10:20 p.m.)
> 
> 
> Review request for ranger, madhan, Madhan Neethiraj, Mahesh Bandal, Pradeep 
> Agrawal, Ramesh Mani, and Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-4639
> https://issues.apache.org/jira/browse/RANGER-4639
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> When a chained plugin is configured, for every access request processed by 
> the parent plugin is also processed by chained plugin. It may be appropriate, 
> in some cases, under a configuration option, to bypass the evaluation of 
> chained plugin when an applicable policy is found by the parent plugin.
> 
> This is controlled by a configuration parameter:
> 
> ranger.plugin..bypass.chained.plugin.evaluation.if.access.is.determined
> 
> with a default value of false. If it is set to true, then the chanined plugin 
> evaluation will be bypassed - if the base-plugin found applicable policy.
> 
> 
> Diffs
> -
> 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/service/RangerBasePlugin.java
>  5d6c3d97c 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/service/RangerChainedPlugin.java
>  b969fb687 
> 
> 
> Diff: https://reviews.apache.org/r/74823/diff/2/
> 
> 
> Testing
> ---
> 
> Compiled clean and ran unit tests. Verified that for HDFS base-plugin there 
> is no regression, and when the configuration parameter is set to true, the 
> chained-plugin evaluation is bypassed.
> 
> 
> Thanks,
> 
> Abhay Kulkarni
> 
>

Re: Review Request 74823: RANGER-4639: Provide an option to bypass evaluation of chained plugin if the parent plugin has applicable policy

[Abhay Kulkarni]

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

(Updated Jan. 8, 2024, 10:20 p.m.)


Review request for ranger, madhan, Madhan Neethiraj, Mahesh Bandal, Pradeep 
Agrawal, Ramesh Mani, and Velmurugan Periasamy.


Changes
---

Addressed review comment


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


Repository: ranger


Description
---

When a chained plugin is configured, for every access request processed by the 
parent plugin is also processed by chained plugin. It may be appropriate, in 
some cases, under a configuration option, to bypass the evaluation of chained 
plugin when an applicable policy is found by the parent plugin.

This is controlled by a configuration parameter:

ranger.plugin..bypass.chained.plugin.evaluation.if.access.is.determined

with a default value of false. If it is set to true, then the chanined plugin 
evaluation will be bypassed - if the base-plugin found applicable policy.


Diffs (updated)
-

  
agents-common/src/main/java/org/apache/ranger/plugin/service/RangerBasePlugin.java
 5d6c3d97c 
  
agents-common/src/main/java/org/apache/ranger/plugin/service/RangerChainedPlugin.java
 b969fb687 


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

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


Testing
---

Compiled clean and ran unit tests. Verified that for HDFS base-plugin there is 
no regression, and when the configuration parameter is set to true, the 
chained-plugin evaluation is bypassed.


Thanks,

Abhay Kulkarni

Re: Review Request 74823: RANGER-4639: Provide an option to bypass evaluation of chained plugin if the parent plugin has applicable policy

[Madhan Neethiraj]

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


Fix it, then Ship it!





agents-common/src/main/java/org/apache/ranger/plugin/service/RangerChainedPlugin.java
Lines 48 (patched)


isChainedPluginEvaluationBypassed => skipAccessCheckIfAlreadyDetermined


- Madhan Neethiraj


On Jan. 8, 2024, 8:27 p.m., Abhay Kulkarni wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/74823/
> ---
> 
> (Updated Jan. 8, 2024, 8:27 p.m.)
> 
> 
> Review request for ranger, madhan, Madhan Neethiraj, Mahesh Bandal, Pradeep 
> Agrawal, Ramesh Mani, and Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-4639
> https://issues.apache.org/jira/browse/RANGER-4639
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> When a chained plugin is configured, for every access request processed by 
> the parent plugin is also processed by chained plugin. It may be appropriate, 
> in some cases, under a configuration option, to bypass the evaluation of 
> chained plugin when an applicable policy is found by the parent plugin.
> 
> This is controlled by a configuration parameter:
> 
> ranger.plugin..bypass.chained.plugin.evaluation.if.access.is.determined
> 
> with a default value of false. If it is set to true, then the chanined plugin 
> evaluation will be bypassed - if the base-plugin found applicable policy.
> 
> 
> Diffs
> -
> 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/service/RangerBasePlugin.java
>  5d6c3d97c 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/service/RangerChainedPlugin.java
>  b969fb687 
> 
> 
> Diff: https://reviews.apache.org/r/74823/diff/1/
> 
> 
> Testing
> ---
> 
> Compiled clean and ran unit tests. Verified that for HDFS base-plugin there 
> is no regression, and when the configuration parameter is set to true, the 
> chained-plugin evaluation is bypassed.
> 
> 
> Thanks,
> 
> Abhay Kulkarni
> 
>

[jira] [Updated] (RANGER-4639) Provide an option to bypass evaluation of chained plugin if the parent plugin has applicable policy

[Abhay Kulkarni (Jira)]

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

Abhay Kulkarni updated RANGER-4639:
---
Description: 
When a chained plugin is configured, for every access request processed by the 
parent plugin is also processed by chained plugin. It may be appropriate, in 
some cases, under a configuration option, to bypass the evaluation of chained 
plugin when an applicable policy is found by the parent plugin.

 
This is controlled by a configuration parameter:

ranger.plugin..bypass.chained.plugin.evaluation.if.access.is.determined

with a default value of false. If it is set to true, then the chanined plugin 
evaluation will be bypassed - if the base-plugin found applicable policy.

  was:When a chained plugin is configured, for every access request processed 
by the parent plugin is also processed by chained plugin. It may be 
appropriate, in some cases, under a configuration option, to bypass the 
evaluation of chained plugin when an applicable policy is found by the parent 
plugin.


> Provide an option to bypass evaluation of chained plugin if the parent plugin 
> has applicable policy
> ---
>
> Key: RANGER-4639
> URL: https://issues.apache.org/jira/browse/RANGER-4639
> Project: Ranger
>  Issue Type: Improvement
>  Components: Ranger
>Reporter: Abhay Kulkarni
>Assignee: Abhay Kulkarni
>Priority: Major
>
> When a chained plugin is configured, for every access request processed by 
> the parent plugin is also processed by chained plugin. It may be appropriate, 
> in some cases, under a configuration option, to bypass the evaluation of 
> chained plugin when an applicable policy is found by the parent plugin.
>  
> This is controlled by a configuration parameter:
> ranger.plugin..bypass.chained.plugin.evaluation.if.access.is.determined
> with a default value of false. If it is set to true, then the chanined plugin 
> evaluation will be bypassed - if the base-plugin found applicable policy.



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

Review Request 74823: RANGER-4639: Provide an option to bypass evaluation of chained plugin if the parent plugin has applicable policy

[Abhay Kulkarni]

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

Review request for ranger, madhan, Madhan Neethiraj, Mahesh Bandal, Pradeep 
Agrawal, Ramesh Mani, and Velmurugan Periasamy.


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


Repository: ranger


Description
---

When a chained plugin is configured, for every access request processed by the 
parent plugin is also processed by chained plugin. It may be appropriate, in 
some cases, under a configuration option, to bypass the evaluation of chained 
plugin when an applicable policy is found by the parent plugin.

This is controlled by a configuration parameter:

ranger.plugin..bypass.chained.plugin.evaluation.if.access.is.determined

with a default value of false. If it is set to true, then the chanined plugin 
evaluation will be bypassed - if the base-plugin found applicable policy.


Diffs
-

  
agents-common/src/main/java/org/apache/ranger/plugin/service/RangerBasePlugin.java
 5d6c3d97c 
  
agents-common/src/main/java/org/apache/ranger/plugin/service/RangerChainedPlugin.java
 b969fb687 


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


Testing
---

Compiled clean and ran unit tests. Verified that for HDFS base-plugin there is 
no regression, and when the configuration parameter is set to true, the 
chained-plugin evaluation is bypassed.


Thanks,

Abhay Kulkarni

[jira] [Created] (RANGER-4639) Provide an option to bypass evaluation of chained plugin if the parent plugin has applicable policy

[Abhay Kulkarni (Jira)]

Abhay Kulkarni created RANGER-4639:
--

 Summary: Provide an option to bypass evaluation of chained plugin 
if the parent plugin has applicable policy
 Key: RANGER-4639
 URL: https://issues.apache.org/jira/browse/RANGER-4639
 Project: Ranger
  Issue Type: Improvement
  Components: Ranger
Reporter: Abhay Kulkarni
Assignee: Abhay Kulkarni


When a chained plugin is configured, for every access request processed by the 
parent plugin is also processed by chained plugin. It may be appropriate, in 
some cases, under a configuration option, to bypass the evaluation of chained 
plugin when an applicable policy is found by the parent plugin.



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

[jira] [Created] (RANGER-4638) Multiple Columns Revoke not generating policies with correct number of columns

[Ramesh Mani (Jira)]

Ramesh Mani created RANGER-4638:
---

 Summary: Multiple Columns Revoke not generating policies with 
correct number of columns
 Key: RANGER-4638
 URL: https://issues.apache.org/jira/browse/RANGER-4638
 Project: Ranger
  Issue Type: Bug
  Components: Ranger
Affects Versions: 3.0.0
Reporter: Ramesh Mani


Multiple Columns Revoke not generating policies with correct number of columns. 
E.G

When  " revoke select(col1, col2,col3) on table demo.test from role Role3;" is 
done, the generate policies is not revoking the columns. Currently revoke  
statement is only revoking if the is only one column.

Testing to done"

Impala / Hive beeline.

1) "grant select(col1, col2, col3)  on table demo.test  to role Role1" 

     "revoke select(col1, col2, col3) on table demo.test from role Role1"

2) "grant select(col1, col2, col3, col4)  on table demo.test  to role Role1" 

      "revoke select(col1, col2, col3) on table demo.test from role Role1"

HBASE shell

grant 'nifi', 'RWXCA', 'test'

revoke 'nifi', 'test'

 



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

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

[Abhishek (Jira)]

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

Abhishek reassigned RANGER-:


Assignee: Abhishek

> 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: Abhishek
>Priority: Major
>
> 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] [Commented] (RANGER-4444) When security-zone is deleted with force, trigger cascade delete of datashare

[Madhan Neethiraj (Jira)]

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

Madhan Neethiraj commented on RANGER-:
--

{quote}Should this be the expected behaviour i.e trigger a cascading delete of 
datashare whenever a security zone is deleted?
{quote}
Yes [~abhishek.patil].

> 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
>Priority: Major
>
> 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-4637) /public/api/policy/count does not return the proper value if the number of policies is greater than 200

[Abhishek (Jira)]

Abhishek created RANGER-4637:


 Summary: /public/api/policy/count does not return the proper value 
if the number of policies is greater than 200
 Key: RANGER-4637
 URL: https://issues.apache.org/jira/browse/RANGER-4637
 Project: Ranger
  Issue Type: Bug
  Components: admin
Reporter: Abhishek
Assignee: Abhishek


/public/api/policy/count does not return the proper value if the number of 
policies is greater than 200



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

[jira] [Created] (RANGER-4636) /public/api/repository/count does not return the proper value if the number of repositories is greater than 200

[Abhishek (Jira)]

Abhishek created RANGER-4636:


 Summary: /public/api/repository/count does not return the proper 
value if the number of repositories is greater than 200
 Key: RANGER-4636
 URL: https://issues.apache.org/jira/browse/RANGER-4636
 Project: Ranger
  Issue Type: Bug
  Components: admin
Reporter: Abhishek
Assignee: Abhishek


/public/api/repository/count does not return the proper value if the number of 
repositories is greater than 200



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

Re: Review Request 74822: RANGER-4283: [WIP] UI for GDS: Integrated api for request listing page, created history tab for dataset and datashare detail view

[Madhan Neethiraj]

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


Ship it!




Ship It!

- Madhan Neethiraj


On Jan. 8, 2024, 3:41 p.m., Anand Nadar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/74822/
> ---
> 
> (Updated Jan. 8, 2024, 3:41 p.m.)
> 
> 
> Review request for ranger, Ankita Sinha, Brijesh Bhalala, Dhaval Rajpara, 
> Madhan Neethiraj, Mugdha Varadkar, Prashant Satam, and Subhrat Chaudhary.
> 
> 
> Bugs: https://issues.apache.org/jira/browse/RANGER-4283
> 
> https://issues.apache.org/jira/browse/https://issues.apache.org/jira/browse/RANGER-4283
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> Integrated api for request listing page, created history tab for dataset and 
> datashare detail view. Fixed few bugs.
> 
> 
> Diffs
> -
> 
>   security-admin/src/main/webapp/react-webapp/src/images/history-details.svg 
> PRE-CREATION 
>   
> security-admin/src/main/webapp/react-webapp/src/views/GovernedData/Dataset/DatasetDetailLayout.jsx
>  a08faba49 
>   
> security-admin/src/main/webapp/react-webapp/src/views/GovernedData/Datashare/AddDatashareView.jsx
>  30be71988 
>   
> security-admin/src/main/webapp/react-webapp/src/views/GovernedData/Datashare/AddSharedResourceComp.jsx
>  ecb14c7b2 
>   
> security-admin/src/main/webapp/react-webapp/src/views/GovernedData/Datashare/DatashareDetailLayout.jsx
>  57630ea5c 
>   
> security-admin/src/main/webapp/react-webapp/src/views/GovernedData/Datashare/MyDatashareListing.jsx
>  15c3d5688 
>   
> security-admin/src/main/webapp/react-webapp/src/views/GovernedData/Request/RequestListing.jsx
>  b29b900a0 
> 
> 
> Diff: https://reviews.apache.org/r/74822/diff/1/
> 
> 
> Testing
> ---
> 
> Validated request listing page.
> Validated history tab with search filter and sort by time.
> Validated bugs on Dataset/Datashare visibility operations.
> 
> 
> Thanks,
> 
> Anand Nadar
> 
>

[jira] [Updated] (RANGER-4635) Temporary table creation violates auth principles

[Kundan Kumar Jha (Jira)]

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

Kundan Kumar Jha updated RANGER-4635:
-
Description: Creating temporary table violating auth principles.  (was: 
Creating temporary table via "Like" cmd is violating auth principles.)

> Temporary table creation violates auth principles 
> --
>
> Key: RANGER-4635
> URL: https://issues.apache.org/jira/browse/RANGER-4635
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Reporter: Kundan Kumar Jha
>Priority: Major
>
> Creating temporary table violating auth principles.



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

[jira] [Updated] (RANGER-4635) Temporary table creation violates auth principles

[Kundan Kumar Jha (Jira)]

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

Kundan Kumar Jha updated RANGER-4635:
-
Summary: Temporary table creation violates auth principles   (was: create 
temporary table via "LIKE" cmd need revisit)

> Temporary table creation violates auth principles 
> --
>
> Key: RANGER-4635
> URL: https://issues.apache.org/jira/browse/RANGER-4635
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Reporter: Kundan Kumar Jha
>Priority: Major
>
> Creating temporary table via "Like" cmd is violating auth principles.



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

[jira] [Updated] (RANGER-4635) create temporary table via "LIKE" cmd need revisit

[Kundan Kumar Jha (Jira)]

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

Kundan Kumar Jha updated RANGER-4635:
-
Description: Creating temporary table via "Like" cmd is violating auth 
principles.  (was: *PROBLEM STATEMENT:*
Users which don't have access on any resource can able to create a temporary 
table using"LIKE" statement with same schema as another table and extract 
schema info of non accessible table.

*STEPS TO REPRODUCE:*
1. Delete all the policies in ranger.

2. Then give all access(*, *, *) to "hive" and "user_1" via hive policy.

3. Then create a database a_db and a table a_db.a_table with schema using user 
user_1:
{code:java}
+---++--+
| col_name  | data_type  | comment  |
+---++--+
| id        | int        |          |
| name      | string     |          |
+---++--+ {code}
4. Then kinit as user_2 user(which don't have access to any resource) and 
create a temporary table like a_db.a_table using following cmd:
{code:java}
create temporary table temp_t like a_db.a_table; {code}
5. Then run following cmd to describe temporary table temp_t:
{code:java}
desc temp_t;{code}
output:
{code:java}
+---++--+
| col_name  | data_type  | comment  |
+---++--+
| id        | int        |          |
| name      | string     |          |
+---++--+ {code}
*CURRENT BEHAVIOUR:*

The temp table "temp_t" got created successfully with same schema as "a_table" 
and the user user_2 with no access can able to view the schema of a non 
accessible table.

*EXPECTED BEHAVIOUR:*
The user which doesn't have access on a table should not able to create a 
temporary table with it using "LIKE" query.

*OCCURRENCE:*
manual testing 

*IMPACT:*
User can access the schema of a non accessible table.)

> create temporary table via "LIKE" cmd need revisit
> --
>
> Key: RANGER-4635
> URL: https://issues.apache.org/jira/browse/RANGER-4635
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Reporter: Kundan Kumar Jha
>Priority: Major
>
> Creating temporary table via "Like" cmd is violating auth principles.



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

[jira] [Updated] (RANGER-4635) create temporary table via "LIKE" cmd need revisit

[Kundan Kumar Jha (Jira)]

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

Kundan Kumar Jha updated RANGER-4635:
-
Summary: create temporary table via "LIKE" cmd need revisit  (was: User 
with no access can able to replicate schema of a table using temporary table 
creation via "LIKE")

> create temporary table via "LIKE" cmd need revisit
> --
>
> Key: RANGER-4635
> URL: https://issues.apache.org/jira/browse/RANGER-4635
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Reporter: Kundan Kumar Jha
>Priority: Major
>
> *PROBLEM STATEMENT:*
> Users which don't have access on any resource can able to create a temporary 
> table using"LIKE" statement with same schema as another table and extract 
> schema info of non accessible table.
> *STEPS TO REPRODUCE:*
> 1. Delete all the policies in ranger.
> 2. Then give all access(*, *, *) to "hive" and "user_1" via hive policy.
> 3. Then create a database a_db and a table a_db.a_table with schema using 
> user user_1:
> {code:java}
> +---++--+
> | col_name  | data_type  | comment  |
> +---++--+
> | id        | int        |          |
> | name      | string     |          |
> +---++--+ {code}
> 4. Then kinit as user_2 user(which don't have access to any resource) and 
> create a temporary table like a_db.a_table using following cmd:
> {code:java}
> create temporary table temp_t like a_db.a_table; {code}
> 5. Then run following cmd to describe temporary table temp_t:
> {code:java}
> desc temp_t;{code}
> output:
> {code:java}
> +---++--+
> | col_name  | data_type  | comment  |
> +---++--+
> | id        | int        |          |
> | name      | string     |          |
> +---++--+ {code}
> *CURRENT BEHAVIOUR:*
> The temp table "temp_t" got created successfully with same schema as 
> "a_table" and the user user_2 with no access can able to view the schema of a 
> non accessible table.
> *EXPECTED BEHAVIOUR:*
> The user which doesn't have access on a table should not able to create a 
> temporary table with it using "LIKE" query.
> *OCCURRENCE:*
> manual testing 
> *IMPACT:*
> User can access the schema of a non accessible table.



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

Review Request 74822: RANGER-4283: [WIP] UI for GDS: Integrated api for request listing page, created history tab for dataset and datashare detail view

[Anand Nadar]

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

Review request for ranger, Ankita Sinha, Brijesh Bhalala, Dhaval Rajpara, 
Madhan Neethiraj, Mugdha Varadkar, Prashant Satam, and Subhrat Chaudhary.


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

https://issues.apache.org/jira/browse/https://issues.apache.org/jira/browse/RANGER-4283


Repository: ranger


Description
---

Integrated api for request listing page, created history tab for dataset and 
datashare detail view. Fixed few bugs.


Diffs
-

  security-admin/src/main/webapp/react-webapp/src/images/history-details.svg 
PRE-CREATION 
  
security-admin/src/main/webapp/react-webapp/src/views/GovernedData/Dataset/DatasetDetailLayout.jsx
 a08faba49 
  
security-admin/src/main/webapp/react-webapp/src/views/GovernedData/Datashare/AddDatashareView.jsx
 30be71988 
  
security-admin/src/main/webapp/react-webapp/src/views/GovernedData/Datashare/AddSharedResourceComp.jsx
 ecb14c7b2 
  
security-admin/src/main/webapp/react-webapp/src/views/GovernedData/Datashare/DatashareDetailLayout.jsx
 57630ea5c 
  
security-admin/src/main/webapp/react-webapp/src/views/GovernedData/Datashare/MyDatashareListing.jsx
 15c3d5688 
  
security-admin/src/main/webapp/react-webapp/src/views/GovernedData/Request/RequestListing.jsx
 b29b900a0 


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


Testing
---

Validated request listing page.
Validated history tab with search filter and sort by time.
Validated bugs on Dataset/Datashare visibility operations.


Thanks,

Anand Nadar

[jira] [Resolved] (RANGER-4597) /users/{user_id}/emailchange API is not accessible by keyadmin user

[Pradeep Agrawal (Jira)]

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

Pradeep Agrawal resolved RANGER-4597.
-
Resolution: Fixed

> /users/{user_id}/emailchange API is not accessible by keyadmin user
> ---
>
> Key: RANGER-4597
> URL: https://issues.apache.org/jira/browse/RANGER-4597
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Reporter: Abhishek
>Assignee: Pradeep Agrawal
>Priority: Major
>
> {color:#172b4d}/users/\{user_id}/emailchange API is not accessible by 
> keyadmin user and it returns 403 forbidden status code.{color}
> {color:#172b4d}However, the keyadmin user can update the user email id using 
> Ranger Admin UI,{color}
> {color:#172b4d}and using PUT request to other APIs like /xusers/users and 
> /users.{color}
> {color:#172b4d}The behaviour has to be kept consistent and the user should be 
> allowed access to the emailchange API{color}



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

[jira] [Updated] (RANGER-4576) Implement best coding practice for the {BASE_URL}/plugins/policies/{service_type}/for-resource API

[Pradeep Agrawal (Jira)]

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

Pradeep Agrawal updated RANGER-4576:

Attachment: 0016-RANGER-4576-User-without-access-to-policy-is-able-to.patch

> Implement best coding practice for the 
> {BASE_URL}/plugins/policies/{service_type}/for-resource API
> --
>
> Key: RANGER-4576
> URL: https://issues.apache.org/jira/browse/RANGER-4576
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Reporter: Abhishek
>Assignee: Pradeep Agrawal
>Priority: Major
> Attachments: 
> 0016-RANGER-4576-User-without-access-to-policy-is-able-to.patch
>
>
> Implement best coding practice for the 
> \{BASE_URL}/plugins/policies/\{service_type}/for-resource API



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

[jira] [Updated] (RANGER-4573) /xaudit/trx_log API not accessible by keyadmin user

[Pradeep Agrawal (Jira)]

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

Pradeep Agrawal updated RANGER-4573:

Attachment: 0012-RANGER-4573-xaudit-trx_log-API-not-accessible-by-key.patch

> /xaudit/trx_log API not accessible by keyadmin user
> ---
>
> Key: RANGER-4573
> URL: https://issues.apache.org/jira/browse/RANGER-4573
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Reporter: Abhishek
>Assignee: Pradeep Agrawal
>Priority: Major
> Attachments: 
> 0012-RANGER-4573-xaudit-trx_log-API-not-accessible-by-key.patch
>
>
> {color:#172b4d}If a keyadmin user makes a request to /xaudit/trx_log API 
> endpoint,{color}
> {color:#172b4d}the response is 403 forbidden.{color}
> {color:#172b4d}However, the same function used in /xaudit/trx_log is called 
> by the /assets/report API,{color}
> {color:#172b4d}and the /assets/report API is accessible by the keyadmin user, 
> so ideally, the /xaudit/trx_log API should be accessible 
> {color}{color:#172b4d}by the keyadmin user as well.{color}



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

[jira] [Updated] (RANGER-4574) Implement best coding practice for /public/v2/api/service/{service_name}/policy/{policy_name}

[Pradeep Agrawal (Jira)]

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

Pradeep Agrawal updated RANGER-4574:

Attachment: 0014-RANGER-4574-public-v2-api-service-service_name-polic.patch

> Implement best coding practice for 
> /public/v2/api/service/{service_name}/policy/{policy_name}
> -
>
> Key: RANGER-4574
> URL: https://issues.apache.org/jira/browse/RANGER-4574
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Reporter: Abhishek
>Assignee: Pradeep Agrawal
>Priority: Major
> Attachments: 
> 0014-RANGER-4574-public-v2-api-service-service_name-polic.patch
>
>
> Implement best coding practice for the 
> /public/v2/api/service/\{service_name}/policy/\{policy_name} API



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

[jira] [Updated] (RANGER-4588) /xaudit/trx_log/{trx_log_id} is not accessible by keyadmin user

[Pradeep Agrawal (Jira)]

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

Pradeep Agrawal updated RANGER-4588:

Attachment: 0019-RANGER-4588-xaudit-trx_log-trx_log_id-is-not-accessi.patch

> /xaudit/trx_log/{trx_log_id} is not accessible by keyadmin user
> ---
>
> Key: RANGER-4588
> URL: https://issues.apache.org/jira/browse/RANGER-4588
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Reporter: Abhishek
>Assignee: Pradeep Agrawal
>Priority: Major
> Attachments: 
> 0019-RANGER-4588-xaudit-trx_log-trx_log_id-is-not-accessi.patch
>
>
> keyadmin users can access the trx_logs using the /assets/report and 
> /assets/report/\{transaction_id} API.
> However, the keyadmin user is not allowed to access the /xaudit/trx_log/\{id} 
> API and
> it results in 403 forbidden status code.
> Ideally, as the keyadmin user is allowed to access the kms related entities 
> from other APIs, the user should be allowed to access the details using 
> /xaudit/trx_log/\{id} API as well.



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

[jira] [Updated] (RANGER-4591) Add improvements for /assets/report/{transaction_id} API

[Pradeep Agrawal (Jira)]

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

Pradeep Agrawal updated RANGER-4591:

Attachment: 0020-RANGER-4591-keyadmin-user-can-access-non-kms-related.patch

> Add improvements for  /assets/report/{transaction_id} API
> -
>
> Key: RANGER-4591
> URL: https://issues.apache.org/jira/browse/RANGER-4591
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Reporter: Abhishek
>Assignee: Pradeep Agrawal
>Priority: Major
> Attachments: 
> 0020-RANGER-4591-keyadmin-user-can-access-non-kms-related.patch
>
>
> Add improvements for  /assets/report/\{transaction_id} API



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

[jira] [Updated] (RANGER-4589) keyadmin user can update the user password via UI but cannot update the user password using /users/{user_id}/passwordchange API

[Pradeep Agrawal (Jira)]

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

Pradeep Agrawal updated RANGER-4589:

Attachment: 0018-RANGER-4589-keyadmin-user-can-update-the-user-passwo.patch

> keyadmin user can update the user password via UI but cannot update the user 
> password using /users/{user_id}/passwordchange API
> ---
>
> Key: RANGER-4589
> URL: https://issues.apache.org/jira/browse/RANGER-4589
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Reporter: Abhishek
>Assignee: Pradeep Agrawal
>Priority: Major
> Attachments: 
> 0018-RANGER-4589-keyadmin-user-can-update-the-user-passwo.patch
>
>
> keyadmin user can update the user password through /xusers API or via Ranger 
> admin UI, however, if the keyadmin user tries to update the password through 
> /users/\{user_id}/passwordchange API, the response is 403 forbidden.
> The behaviour has to be kept consistent for the keyadmin users across the 
> APIs for passswordchange



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

[jira] [Updated] (RANGER-4595) Mask / remove some fields from GET /users API for keyadmin users

[Pradeep Agrawal (Jira)]

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

Pradeep Agrawal updated RANGER-4595:

Attachment: 0022-RANGER-4595-keyadmin-user-able-to-view-the-user-perm.patch

> Mask / remove some fields from GET /users API for keyadmin users
> 
>
> Key: RANGER-4595
> URL: https://issues.apache.org/jira/browse/RANGER-4595
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Reporter: Abhishek
>Assignee: Pradeep Agrawal
>Priority: Major
> Attachments: 
> 0022-RANGER-4595-keyadmin-user-able-to-view-the-user-perm.patch
>
>
> Mask / remove some fields from GET /users API for keyadmin users



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

[jira] [Updated] (RANGER-4594) Add improvement to PUT request for keyadmin user with respect to status field

[Pradeep Agrawal (Jira)]

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

Pradeep Agrawal updated RANGER-4594:

Attachment: 0021-RANGER-4594-keyadmin-user-can-mark-ROLE_USER-users-a.patch

> Add improvement to PUT request for keyadmin user with respect to status field
> -
>
> Key: RANGER-4594
> URL: https://issues.apache.org/jira/browse/RANGER-4594
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Reporter: Abhishek
>Assignee: Pradeep Agrawal
>Priority: Major
> Attachments: 
> 0021-RANGER-4594-keyadmin-user-can-mark-ROLE_USER-users-a.patch
>
>
> Add improvement to PUT request for keyadmin user with respect to status field



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

[jira] [Updated] (RANGER-4586) Add improvement for UserREST and XUserREST APIs for keyadmin users

[Pradeep Agrawal (Jira)]

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

Pradeep Agrawal updated RANGER-4586:

Attachment: 0025-RANGER-4586-XUserREST-and-UserREST-API-improvement-f.patch

> Add improvement for UserREST and XUserREST APIs for keyadmin users
> --
>
> Key: RANGER-4586
> URL: https://issues.apache.org/jira/browse/RANGER-4586
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Reporter: Abhishek
>Assignee: Pradeep Agrawal
>Priority: Major
> Attachments: 
> 0025-RANGER-4586-XUserREST-and-UserREST-API-improvement-f.patch
>
>
> Add improvement for UserREST and XUserREST APIs



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

[jira] [Updated] (RANGER-4596) Response of /users API for keyadmin users should be consistent with the UI behaviour for viewing users on the UI

[Pradeep Agrawal (Jira)]

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

Pradeep Agrawal updated RANGER-4596:

Attachment: 0023-RANGER-4596-keyadmin-can-fetch-the-details-of-admin-.patch

> Response of /users API for keyadmin users should be consistent with the UI 
> behaviour for viewing users on the UI
> 
>
> Key: RANGER-4596
> URL: https://issues.apache.org/jira/browse/RANGER-4596
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Reporter: Abhishek
>Assignee: Pradeep Agrawal
>Priority: Major
> Attachments: 
> 0023-RANGER-4596-keyadmin-can-fetch-the-details-of-admin-.patch
>
>
> Response of /users API for keyadmin users should be consistent with the UI 
> behaviour for viewing users on the UI.



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

[jira] [Updated] (RANGER-4577) Implement best coding practice for the /xusers/users API for keyadmin users

[Pradeep Agrawal (Jira)]

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

Pradeep Agrawal updated RANGER-4577:

Attachment: 0017-RANGER-4577-UI-and-API-behaviour-for-fetching-users-.patch

> Implement best coding practice for the /xusers/users API for keyadmin users
> ---
>
> Key: RANGER-4577
> URL: https://issues.apache.org/jira/browse/RANGER-4577
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Reporter: Abhishek
>Assignee: Pradeep Agrawal
>Priority: Major
> Attachments: 
> 0017-RANGER-4577-UI-and-API-behaviour-for-fetching-users-.patch
>
>
> Implement best coding practice for the /xusers/users API for keyadmin users



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

[jira] [Updated] (RANGER-4575) Implement best coding practice for /plugins/policy/{policy_id}/version/{version_number} API

[Pradeep Agrawal (Jira)]

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

Pradeep Agrawal updated RANGER-4575:

Attachment: 0015-RANGER-4575-plugins-policy-policy_id-version-version.patch

> Implement best coding practice for 
> /plugins/policy/{policy_id}/version/{version_number}  API
> 
>
> Key: RANGER-4575
> URL: https://issues.apache.org/jira/browse/RANGER-4575
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Reporter: Abhishek
>Assignee: Pradeep Agrawal
>Priority: Major
> Attachments: 
> 0015-RANGER-4575-plugins-policy-policy_id-version-version.patch
>
>
> Implement best coding practice for 
> /plugins/policy/\{policy_id}/version/\{version_number}  API



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

[jira] [Updated] (RANGER-4578) /xuser/groupgroups and /xuser/groupusers APIs allow creation of entities even without groupId / userId fields in the request

[Pradeep Agrawal (Jira)]

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

Pradeep Agrawal updated RANGER-4578:

Attachment: 0013-RANGER-4578-xuser-groupgroups-and-xuser-groupusers-A.patch

> /xuser/groupgroups and /xuser/groupusers APIs allow creation of entities even 
> without groupId / userId fields in the request
> 
>
> Key: RANGER-4578
> URL: https://issues.apache.org/jira/browse/RANGER-4578
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Reporter: Abhishek
>Assignee: Pradeep Agrawal
>Priority: Major
> Attachments: 
> 0013-RANGER-4578-xuser-groupgroups-and-xuser-groupusers-A.patch
>
>
> /xuser/groupgroups and /xuser/groupusers APIs allow creation of entities even 
> without groupId / userId fields in the request.
> The typical request payload to create an entity using the /xusers/groupgroups 
> API endpoint is :- 
> {code:java|bgColor=#f4f5f7}
> {"name": {group_name}, "parentGroupId": {parent_group_id}, "groupId": 
> {child_group_id}} {code}
> But if a POST request is performed without the groupId / parentGroupId, still 
> the request succeeds.



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

[jira] [Updated] (RANGER-4598) Add improvement for /xusers/groups/groupName/{group_name} API for ROLE_USER users

[Pradeep Agrawal (Jira)]

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

Pradeep Agrawal updated RANGER-4598:

Attachment: 0024-RANGER-4598-ROLE_USER-cannot-acccess-xusers-groups-A.patch

> Add improvement for /xusers/groups/groupName/{group_name} API for ROLE_USER 
> users
> -
>
> Key: RANGER-4598
> URL: https://issues.apache.org/jira/browse/RANGER-4598
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Reporter: Abhishek
>Assignee: Pradeep Agrawal
>Priority: Major
> Attachments: 
> 0024-RANGER-4598-ROLE_USER-cannot-acccess-xusers-groups-A.patch
>
>
> Add improvement for /xusers/groups/groupName/\{group_name} API for ROLE_USER 
> users



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

Re: Review Request 74763: RANGER-4607: Ranger REST API improvements

[Pradeep Agrawal]

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

(Updated Jan. 8, 2024, 2:05 p.m.)


Review request for ranger, Abhishek  Kumar, bhavik patel, Dhaval Shah, 
Dineshkumar Yadav, Kishor Gollapalliwar, Abhay Kulkarni, Madhan Neethiraj, 
Mehul Parikh, Ramesh Mani, Sailaja Polavarapu, and Velmurugan Periasamy.


Summary (updated)
-

RANGER-4607: Ranger REST API improvements


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


Repository: ranger


Description (updated)
---

**Problem Statement:** Ranger REST API responses are not proper. Most of the 
legacy REST API's response format are not correct and gives false information.

**Proposed Solution:** This review request shall address multiple issues 
related to old APIs.
The list of issues which shall be addressed with review request are :

RANGER-4545: DELETE /assets/resources/{resource_id} API should return proper 
status code for non admin users
RANGER-4546: /assets/ugsyncAudits/{sync_source} API is accessible by user 
without permission on audit module
RANGER-4548: Return proper error message in the response for /tags/tags, 
/tags/resources and /tags/types API for non admin users
RANGER-4547: The reponse metrics (pagination values) for the 
/assets/ugsyncAudits/{sync_source} API is not proper
RANGER-4549: Non admin users cannot access /public/v2/api/roles/names and 
/public/v2/api/roles/name/{name} API, but can access /public/v2/api/roles API
RANGER-4551: No response returned for /assets/policyList/{service_name} API
RANGER-4550: API request to /assets/resource/{id} returns no response
RANGER-4552: Response metrics for /assets/report is not proper, and pagination 
does not work
RANGER-4553: Response metrics for /xaudit/trx_log not proper
RANGER-4554: Response metrics for /assets/resources not proper
RANGER-4555: Response metrics for /assets/assets API not proper
RANGER-4573: /xaudit/trx_log API not accessible by keyadmin user
RANGER-4578: /xuser/groupgroups and /xuser/groupusers APIs allow creation of 
entities even without groupId / userId fields in the request
RANGER-4574: /public/v2/api/service/{service_name}/policy/{policy_name} API 
returns policies for users without access to the policy
RANGER-4575: /plugins/policy/{policy_id}/version/{version_number} API returns 
policies for users without access to the policy
RANGER-4576: User without access to policy is able to fetch policy details 
using /plugins/policies/{service_type}/for-resource API endpoint
RANGER-4577: UI and API behaviour for fetching users not consistent for 
keyadmin users
RANGER-4589: keyadmin user can update the user password via UI but cannot 
update the user password using /users/{user_id}/passwordchange API
RANGER-4588: /xaudit/trx_log/{trx_log_id} is not accessible by keyadmin user
RANGER-4591: keyadmin user can access non kms related admin audits using 
/assets/report/{transaction_id} API
RANGER-4594: keyadmin user can mark ROLE_USER users as disabled by setting 
status to 0 using /users API
RANGER-4595: keyadmin user able to view the user permission objects via /users 
API
RANGER-4596: keyadmin can fetch the details of admin and auditor users through 
/users API endpoint
RANGER-4598: ROLE_USER cannot acccess /xusers/groups API but can access 
/xusers/groups/groupName/{group_name} API
RANGER-4586: XUserREST and UserREST API improvement for keyadmin users

Note: For individual issue fix please refer patch file attached in the 
respective jira tickets.


Diffs (updated)
-

  security-admin/src/main/java/org/apache/ranger/biz/AssetMgr.java 8bbeba783 
  security-admin/src/main/java/org/apache/ranger/biz/UserMgr.java d5393603e 
  security-admin/src/main/java/org/apache/ranger/biz/XAuditMgr.java 75371f4b2 
  security-admin/src/main/java/org/apache/ranger/biz/XAuditMgrBase.java 
c90296cf6 
  security-admin/src/main/java/org/apache/ranger/biz/XUserMgr.java 09154491d 
  security-admin/src/main/java/org/apache/ranger/rest/AssetREST.java be077e789 
  security-admin/src/main/java/org/apache/ranger/rest/RoleREST.java 4bfaa862c 
  security-admin/src/main/java/org/apache/ranger/rest/ServiceREST.java 
cc9df27d6 
  security-admin/src/main/java/org/apache/ranger/rest/TagREST.java 6d0019f70 
  security-admin/src/main/java/org/apache/ranger/rest/UserREST.java c6557b11c 
  security-admin/src/main/java/org/apache/ranger/rest/XUserREST.java 9a2253a3d 
  security-admin/src/main/java/org/apache/ranger/service/XGroupService.java 
1f033b33d 
  security-admin/src/main/java/org/apache/ranger/service/XTrxLogService.java 
676552e6e 
  
security-admin/src/main/java/org/apache/ranger/service/XUgsyncAuditInfoService.java
 7fa96fbd0 
  security-admin/src/test/java/org/apache/ranger/biz/TestUserMgr.java b6c43133b 
  security-admin/src/test/java/org/apache/ranger/biz/TestXUserMgr.java 
601dbe918 
  

[jira] [Updated] (RANGER-4607) Ranger REST API improvements

[Pradeep Agrawal (Jira)]

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

Pradeep Agrawal updated RANGER-4607:

Attachment: 0001-RANGER-4607-Ranger-REST-API-improvements.patch

> Ranger REST API improvements
> 
>
> Key: RANGER-4607
> URL: https://issues.apache.org/jira/browse/RANGER-4607
> Project: Ranger
>  Issue Type: Improvement
>  Components: Ranger
>Affects Versions: 3.0.0, 2.4.1
>Reporter: Pradeep Agrawal
>Assignee: Pradeep Agrawal
>Priority: Major
> Attachments: 0001-RANGER-4607-Ranger-REST-API-improvements.patch
>
>




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