[jira] [Resolved] (RANGER-2758) Option to create missing users/groups while creating/updating roles

2020-03-19 Thread Dineshkumar Yadav (Jira)


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

Dineshkumar Yadav resolved RANGER-2758.
---
Resolution: Fixed

patch submitted 

https://github.com/apache/ranger/commit/10f4cff27b703ffbb18e77ac9bd08d4b61e63813

> Option to create missing users/groups while creating/updating roles 
> 
>
> Key: RANGER-2758
> URL: https://issues.apache.org/jira/browse/RANGER-2758
> Project: Ranger
>  Issue Type: Improvement
>  Components: Ranger
>Reporter: Dineshkumar Yadav
>Assignee: Dineshkumar Yadav
>Priority: Major
>
> Option to create missing users/groups while creating/updating roles
> *Problem:* Currently Ranger dose not allow to create or update roles while it 
> passes non existing users or groups during role creation or updating.
> *Solution:* 1. Now this option will be available with one additional optional 
> queryparam "_createNonExistUserGroup_" which is boolean value. If we wanted 
> to create role with non existing  groups or roles, pass the value true in 
> queryparam otherwise false.  
> 2. Default value for QueryParam "_createNonExistUserGroup_" is false and this 
> is optional, so that existing api dose not get affected with this changes.
> 3. This changes done for create and update Role for both internal and public 
> api.   



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (RANGER-2761) Policy evaluators are not correctly updated when using policy deltas for downloads to plugins

2020-03-19 Thread Abhay Kulkarni (Jira)


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

Abhay Kulkarni updated RANGER-2761:
---
Summary: Policy evaluators are not correctly updated when using policy 
deltas for downloads to plugins  (was: Bugs about wildcard evaluator 
incremental creation)

> Policy evaluators are not correctly updated when using policy deltas for 
> downloads to plugins
> -
>
> Key: RANGER-2761
> URL: https://issues.apache.org/jira/browse/RANGER-2761
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Affects Versions: 2.0.0
>Reporter: star
>Assignee: star
>Priority: Major
> Attachments: RANGER-2761.patch
>
>
> When incrementally update wildcard policies, it will not cause any effect. 
> Reproduce steps:
>    1. Create a policy A to grant Peter select access to database test and 
> table t. Verify Peter did have select access.
>    2. Create a policy B to deny Peter select access to all database and 
> table. Verify Peter is rejected select access to database test and table t.
>    3. Delete policy B and verify that Peter again has select access. 
>    4. Create a policy C, the same as policy B and expecting Peter again is 
> rejected select access. But it does not happen.
> {code:java}
> // RangerResourceTrie
> void undoSetup() {
>   if (isSetup) {
> if (evaluators != null) {
> for (TrieNode child : children.values()) {
> child.undoSetup();
> }
> ... 
> }
> isSetup = false;
>   }
> }
> private Set getEvaluatorsForResource(String resource) {
> ...
> while (i < len) {
> if (!isOptimizedForRetrieval) {
> curr.setupIfNeeded(parent);
> }
> ...
> }
> if (!isOptimizedForRetrieval) {
> curr.setupIfNeeded(parent);
> }
> Set ret = i == len ? curr.getEvaluators() : 
> curr.getWildcardEvaluators();
> return ret;
> }
> {code}
> When adding new wildcard policy, evaluators of the root trie is null. So 
> child.undoSetup will not be called. Then setupIfNeeded will not take effect 
> on child trie nodes. At last, new wildcard policy(policy C) does not take 
> effect.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


Re: Review Request 72247: RANGER-2724 Support EXECUTE permission in HBase Authorisation

2020-03-19 Thread Ramesh Mani

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




hbase-agent/src/test/java/org/apache/ranger/authorization/hbase/HbaseAuthUtilsImplTest.java
Lines 32 (patched)


Should this be checked only if the flag for exec permission check is true?
Could you please create a test case for this scenairo?


- Ramesh Mani


On March 19, 2020, 10:10 a.m., Rajeshbabu Chintaguntla wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/72247/
> ---
> 
> (Updated March 19, 2020, 10:10 a.m.)
> 
> 
> Review request for ranger and Ramesh Mani.
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> - added execute permission to HBase service def
>- Added java patch file to support execute permission
>- Made changes in Ranger coprocessor to check for exec permission in 
> endpoint coporcessor hook.
> 
> 
> Diffs
> -
> 
>   agents-common/src/main/resources/service-defs/ranger-servicedef-hbase.json 
> f98c919a1 
>   
> hbase-agent/src/main/java/org/apache/ranger/authorization/hbase/HbaseAuthUtils.java
>  f8ee168d7 
>   
> hbase-agent/src/main/java/org/apache/ranger/authorization/hbase/HbaseAuthUtilsImpl.java
>  c2e1e7753 
>   
> hbase-agent/src/main/java/org/apache/ranger/authorization/hbase/RangerAuthorizationCoprocessor.java
>  952ef61dc 
>   
> hbase-agent/src/test/java/org/apache/ranger/authorization/hbase/HbaseAuthUtilsImplTest.java
>  1b8edd437 
>   security-admin/db/mysql/optimized/current/ranger_core_db_mysql.sql 
> 47618f6b3 
>   security-admin/db/oracle/optimized/current/ranger_core_db_oracle.sql 
> e59e7de61 
>   security-admin/db/postgres/optimized/current/ranger_core_db_postgres.sql 
> 37ea61912 
>   
> security-admin/db/sqlanywhere/optimized/current/ranger_core_db_sqlanywhere.sql
>  bd1c47cc4 
>   security-admin/db/sqlserver/optimized/current/ranger_core_db_sqlserver.sql 
> 22e1746f2 
>   
> security-admin/src/main/java/org/apache/ranger/patch/PatchForHBaseServiceDefUpdate_J10034.java
>  PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/72247/diff/1/
> 
> 
> Testing
> ---
> 
> Tested in the cluster and ranger admin is showing the execute to select along 
> with create,read,write and admin. Verified policy creation by providing the 
> execute permission for an user and listed the policy it's displaying properly.
> 
> 
> Thanks,
> 
> Rajeshbabu Chintaguntla
> 
>



[jira] [Commented] (RANGER-2766) enable implementations of RangerAccessResourceImpl to provide custom stringified value

2020-03-19 Thread Abhay Kulkarni (Jira)


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

Abhay Kulkarni commented on RANGER-2766:


+1

> enable implementations of RangerAccessResourceImpl to provide custom 
> stringified value
> --
>
> Key: RANGER-2766
> URL: https://issues.apache.org/jira/browse/RANGER-2766
> Project: Ranger
>  Issue Type: Improvement
>  Components: plugins
>Reporter: Madhan Neethiraj
>Assignee: Madhan Neethiraj
>Priority: Minor
> Attachments: RANGER-2766.patch
>
>
> Audit log generated by Ranger plugin has the resource details in a 
> stringified form, for example: {{db1/tbl1}} for Hive table {{tbl1}} in 
> database {{db1}}. This formatting of resources is handled by 
> RangerAccessResourceImpl. 
> It will be useful to enable implementations of RangerAccessResourceImpl to 
> customize the string format of the resource.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (RANGER-2766) enable implementations of RangerAccessResourceImpl to provide custom stringified value

2020-03-19 Thread Madhan Neethiraj (Jira)


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

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

> enable implementations of RangerAccessResourceImpl to provide custom 
> stringified value
> --
>
> Key: RANGER-2766
> URL: https://issues.apache.org/jira/browse/RANGER-2766
> Project: Ranger
>  Issue Type: Improvement
>  Components: plugins
>Reporter: Madhan Neethiraj
>Assignee: Madhan Neethiraj
>Priority: Minor
> Attachments: RANGER-2766.patch
>
>
> Audit log generated by Ranger plugin has the resource details in a 
> stringified form, for example: {{db1/tbl1}} for Hive table {{tbl1}} in 
> database {{db1}}. This formatting of resources is handled by 
> RangerAccessResourceImpl. 
> It will be useful to enable implementations of RangerAccessResourceImpl to 
> customize the string format of the resource.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (RANGER-2766) enable implementations of RangerAccessResourceImpl to provide custom stringified value

2020-03-19 Thread Madhan Neethiraj (Jira)
Madhan Neethiraj created RANGER-2766:


 Summary: enable implementations of RangerAccessResourceImpl to 
provide custom stringified value
 Key: RANGER-2766
 URL: https://issues.apache.org/jira/browse/RANGER-2766
 Project: Ranger
  Issue Type: Improvement
  Components: plugins
Reporter: Madhan Neethiraj
Assignee: Madhan Neethiraj


Audit log generated by Ranger plugin has the resource details in a stringified 
form, for example: {{db1/tbl1}} for Hive table {{tbl1}} in database {{db1}}. 
This formatting of resources is handled by RangerAccessResourceImpl. 

It will be useful to enable implementations of RangerAccessResourceImpl to 
customize the string format of the resource.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


Re: Review Request 72251: RANGER-2762: Handling browser requests when knox trusted proxy is enabled and requests are not through knox

2020-03-19 Thread Abhay Kulkarni

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




security-admin/src/main/java/org/apache/ranger/biz/SessionMgr.java
Lines 184 (patched)


Please consider doing this check before line 182. If the check fails, then 
the rest of the condition(s) may be checked.


- Abhay Kulkarni


On March 19, 2020, 2:25 p.m., Sailaja Polavarapu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/72251/
> ---
> 
> (Updated March 19, 2020, 2:25 p.m.)
> 
> 
> Review request for ranger, Abhay Kulkarni, Mehul Parikh, Nitin Galave, Ramesh 
> Mani, and Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-2762
> https://issues.apache.org/jira/browse/RANGER-2762
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> Made code changes to check if the browser requests are coming from knox when 
> trusted proxy is enabled before applying proper authentication filters. Also 
> labeled the browser session as "sso enabled" when session is created for knox 
> trusted proxy case. This label is used for handling logout from ranger UI and 
> redirect to appropriate page.
> 
> 
> Diffs
> -
> 
>   security-admin/src/main/java/org/apache/ranger/biz/SessionMgr.java 
> ce09c36eb 
>   
> security-admin/src/main/java/org/apache/ranger/security/web/filter/RangerKrbFilter.java
>  b7b2b2ab3 
>   
> security-admin/src/main/java/org/apache/ranger/security/web/filter/RangerSecurityContextFormationFilter.java
>  99fb21f59 
> 
> 
> Diff: https://reviews.apache.org/r/72251/diff/1/
> 
> 
> Testing
> ---
> 
> 1. Tested browser requests with and without knox trusted proxy enabled
> 2. Also verified few regression cases.
> 
> 
> Thanks,
> 
> Sailaja Polavarapu
> 
>



[jira] [Updated] (RANGER-2762) Logout issue when knox-trusted proxy is enabled

2020-03-19 Thread Sailaja Polavarapu (Jira)


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

Sailaja Polavarapu updated RANGER-2762:
---
Attachment: 0001-RANGER-2762-Handling-browser-requests-when-knox-trus.patch

> Logout issue when knox-trusted proxy is enabled
> ---
>
> Key: RANGER-2762
> URL: https://issues.apache.org/jira/browse/RANGER-2762
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Reporter: Harshal Chavan
>Assignee: Sailaja Polavarapu
>Priority: Major
> Attachments: 
> 0001-RANGER-2762-Handling-browser-requests-when-knox-trus.patch
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


Review Request 72251: RANGER-2762: Handling browser requests when knox trusted proxy is enabled and requests are not through knox

2020-03-19 Thread Sailaja Polavarapu

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

Review request for ranger, Abhay Kulkarni, Mehul Parikh, Nitin Galave, Ramesh 
Mani, and Velmurugan Periasamy.


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


Repository: ranger


Description
---

Made code changes to check if the browser requests are coming from knox when 
trusted proxy is enabled before applying proper authentication filters. Also 
labeled the browser session as "sso enabled" when session is created for knox 
trusted proxy case. This label is used for handling logout from ranger UI and 
redirect to appropriate page.


Diffs
-

  security-admin/src/main/java/org/apache/ranger/biz/SessionMgr.java ce09c36eb 
  
security-admin/src/main/java/org/apache/ranger/security/web/filter/RangerKrbFilter.java
 b7b2b2ab3 
  
security-admin/src/main/java/org/apache/ranger/security/web/filter/RangerSecurityContextFormationFilter.java
 99fb21f59 


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


Testing
---

1. Tested browser requests with and without knox trusted proxy enabled
2. Also verified few regression cases.


Thanks,

Sailaja Polavarapu



[jira] [Assigned] (RANGER-2762) Logout issue when knox-trusted proxy is enabled

2020-03-19 Thread Sailaja Polavarapu (Jira)


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

Sailaja Polavarapu reassigned RANGER-2762:
--

Assignee: Sailaja Polavarapu

> Logout issue when knox-trusted proxy is enabled
> ---
>
> Key: RANGER-2762
> URL: https://issues.apache.org/jira/browse/RANGER-2762
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Reporter: Harshal Chavan
>Assignee: Sailaja Polavarapu
>Priority: Major
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (RANGER-2765) Correct permissions are not getting loaded for entity-label in Atlas service

2020-03-19 Thread Preetam Tripathi (Jira)


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

Preetam Tripathi updated RANGER-2765:
-
Attachment: Expected_Result.png
Actual Result.png

> Correct permissions are not getting loaded for entity-label in Atlas service
> 
>
> Key: RANGER-2765
> URL: https://issues.apache.org/jira/browse/RANGER-2765
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Reporter: Preetam Tripathi
>Priority: Major
> Attachments: Actual Result.png, Expected_Result.png
>
>
> Actual Behavior: Correct permissions are not getting displayed for 
> Entity-Entity Label
> Expected Behavior: "Add Label" and "Remove Label" permissions should be 
> displayed for entity - Entity label
> Steps to Reproduce:
>  # Create a policy for atlas service with Entity - Entity Type, Entity 
> Classification, Entity Id and Entity Label
>  # Select User
>  # Select permissions



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (RANGER-2753) Optimize populating user group mappings from DB.

2020-03-19 Thread Sailaja Polavarapu (Jira)


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

Sailaja Polavarapu updated RANGER-2753:
---
Attachment: 0001-RANGER-2753-Minor-fix-on-expanding-imports-in-XXUser.patch

> Optimize populating user group mappings from DB.
> 
>
> Key: RANGER-2753
> URL: https://issues.apache.org/jira/browse/RANGER-2753
> Project: Ranger
>  Issue Type: Improvement
>  Components: Ranger
>Reporter: Sailaja Polavarapu
>Assignee: Sailaja Polavarapu
>Priority: Major
> Attachments: 
> 0001-RANGER-2753-Minor-fix-on-expanding-imports-in-XXUser.patch
>
>
> As part of ranger userstore cache, user to group mappings are built from DB. 
> Current implementation opens lot of DB connections which is very performance 
> intensive operation. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


Re: Review Request 72237: RANGER-2758 :Option to create missing users/groups while creating/updating roles

2020-03-19 Thread Mehul Parikh

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


Ship it!




Ship It!

- Mehul Parikh


On March 17, 2020, 1:06 p.m., Dineshkumar Yadav wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/72237/
> ---
> 
> (Updated March 17, 2020, 1:06 p.m.)
> 
> 
> Review request for ranger, Ankita Sinha, Dhaval Shah, Gautam Borad, Jayendra 
> Parab, Kishor Gollapalliwar, Abhay Kulkarni, Madhan Neethiraj, Mehul Parikh, 
> Nitin Galave, Nixon Rodrigues, Pradeep Agrawal, Ramesh Mani, Sailaja 
> Polavarapu, and Velmurugan Periasamy.
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> Problem Statement: Currently Ranger dose not allow to create or update roles 
> while it passes non-existing users or groups during role creation or updating.
> 
> Solution: 1. Now this option will be available with one additional optional 
> Queryparam "createNonExistUserGroup" which is boolean value. If we wanted to 
> create role with non existing  groups or roles, pass the value true in 
> queryparam otherwise false. Role will be get created or updated.   
> 2. Default value for QueryParam "createNonExistUserGroup" is false and this 
> is optional, so that existing api dose not get affected with this changes.
> 3. This changes done for create and update Role for both internal and public 
> api.
> 
> 
> Diffs
> -
> 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/model/validation/RangerRoleValidator.java
>  bc3459852 
>   agents-common/src/main/java/org/apache/ranger/plugin/store/RoleStore.java 
> 7da43d518 
>   security-admin/src/main/java/org/apache/ranger/biz/PolicyRefUpdater.java 
> baacfa4d8 
>   security-admin/src/main/java/org/apache/ranger/biz/RoleDBStore.java 
> 5be8d9de8 
>   security-admin/src/main/java/org/apache/ranger/biz/RoleRefUpdater.java 
> 3742bd687 
>   security-admin/src/main/java/org/apache/ranger/rest/PublicAPIsv2.java 
> 1a8394978 
>   security-admin/src/main/java/org/apache/ranger/rest/RoleREST.java d690297bf 
> 
> 
> Diff: https://reviews.apache.org/r/72237/diff/1/
> 
> 
> Testing
> ---
> 
> Steps Performed (without patch):
>  1. Try to create role using non-existing users/groups. It won't allow to 
> create.
>   
> Steps Performed (with patch):  
> Note we have to pass optional Queryparam createNonExistUserGroup=true
> 1. Try same steps as mentioned above this time role will get created.
> 2. Try to update role with non- exisitng users/groups. It will allow to 
> update.
> 3. without Queryparam or createNonExistUserGroup=false it will behave as per 
> existing behavior
> 
> 
> Thanks,
> 
> Dineshkumar Yadav
> 
>



[jira] [Created] (RANGER-2765) Correct permissions are not getting loaded for entity-label in Atlas service

2020-03-19 Thread Preetam Tripathi (Jira)
Preetam Tripathi created RANGER-2765:


 Summary: Correct permissions are not getting loaded for 
entity-label in Atlas service
 Key: RANGER-2765
 URL: https://issues.apache.org/jira/browse/RANGER-2765
 Project: Ranger
  Issue Type: Bug
  Components: Ranger
Reporter: Preetam Tripathi


Actual Behavior: Correct permissions are not getting displayed for 
Entity-Entity Label

Expected Behavior: "Add Label" and "Remove Label" permissions should be 
displayed for entity - Entity label

Steps to Reproduce:
 # Create a policy for atlas service with Entity - Entity Type, Entity 
Classification, Entity Id and Entity Label
 # Select User
 # Select permissions



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


Re: Review Request 72155: RANGER-2735: Update Atlas serviceDef for upgrade case of RANGER-2734

2020-03-19 Thread Mehul Parikh

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


Ship it!




Ship It!

- Mehul Parikh


On Feb. 21, 2020, 9:48 a.m., Pradeep Agrawal wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/72155/
> ---
> 
> (Updated Feb. 21, 2020, 9:48 a.m.)
> 
> 
> Review request for ranger, Ankita Sinha, Dhaval Shah, Dineshkumar Yadav, 
> Gautam Borad, Jayendra Parab, Kishor Gollapalliwar, Abhay Kulkarni, Madhan 
> Neethiraj, Mehul Parikh, Nitin Galave, Nixon Rodrigues, Ramesh Mani, Sailaja 
> Polavarapu, and Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-2735
> https://issues.apache.org/jira/browse/RANGER-2735
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> **Problem Statement:** Currently RANGER-2734 and RANGER-2755 patch does not 
> add mentioned new opertations in the older version of ranger having atlas 
> ranger service def. If anyone will upgrade his ranger from previous version 
> to 2.1.0 then he won't able to see the new operations in the atlas policies 
> and default policies for the new operations will not be added.
> 
> 
> **Proposed Solution:** Proposed solution has a java patch J10034 which shall 
> add the new operations in the atlas service def and create default policy for 
> the mentioned operation in each service of atlas service def.
> 
> 
> Diffs
> -
> 
>   security-admin/db/mysql/optimized/current/ranger_core_db_mysql.sql 
> 47618f6b3 
>   security-admin/db/oracle/optimized/current/ranger_core_db_oracle.sql 
> e59e7de61 
>   security-admin/db/postgres/optimized/current/ranger_core_db_postgres.sql 
> 37ea61912 
>   
> security-admin/db/sqlanywhere/optimized/current/ranger_core_db_sqlanywhere.sql
>  bd1c47cc4 
>   security-admin/db/sqlserver/optimized/current/ranger_core_db_sqlserver.sql 
> 22e1746f2 
>   
> security-admin/src/main/java/org/apache/ranger/patch/PatchForAtlasToAddEntityLabelAndBusinessMetadata_J10034.java
>  PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/72155/diff/2/
> 
> 
> Testing
> ---
> 
> **Steps Performed (without patch):**
> 1. After mvn Build; untar the Ranger-2.0.0 module and updated 
> install.properties for MySQL DB flavor.
> 2. Called setup.sh to install Ranger-admin.
> 3. Started Ranger-admin.
> 4. Created atlas service in ranger-admin which has 5 default policies.
> 5. Stopped ranger-admin
> 
> **Steps Performed (with patch):**
> 1. After mvn Build; untar the Ranger-2.1.0 module and updated 
> install.properties for MySQL DB flavor with same settings used in previous 
> step.
> 2. Executed setup.sh to install Ranger-admin.
> 3. Setup process should apply patch J10034 and create default 
> policies.(Referred ranger_db_patch.log file to see patch applied or not)
> 4. Started Ranger-admin.
> 5. Visited atlas service page in ranger-admin UI which has 2 new policies 
> now. one for the Label and another for the business metadata.
> 6. Compared policy json with latest running Ranger admin(after commit of 
> RANGER-2734)
> 
> **Expected Behavior:**
> 1. Ranger installation should finish successfully and java patch J10034 
> should get applied successfully.
> 2. Policy with name "all - entity-type, entity-classification, entity, 
> entity-label" should get created.
> 3. Policy with name "all - entity-type, entity-classification, entity, 
> entity-business-metadata" should get created.
> 
> **Actual Behavior: **
> 1. Ranger installation finished successfully and java patch J10034 was 
> applied successfully.
> 2. Policy with name "all - entity-type, entity-classification, entity, 
> entity-label" was created with 2 policy items.
>first policy item was having "Add Label" and "Remove Label" access to user 
> 'admin' and 'atlas' with delegated admin set to true.
>second policy item was having "Read Entity" access to user 'rangertagsync' 
> and to group 'public' with delegated admin set to false
> 3. Policy with name "all - entity-type, entity-classification, entity, 
> entity-business-metadata" was created with 2 policy items.
>first policy item was having "Add Label" and "Remove Label" access to user 
> 'admin' and 'atlas' with delegated admin set to true.
>second policy item was having "Read Entity" access to user 'rangertagsync' 
> and to group 'public' with delegated admin set to false
> 
> **Note:**
> 1. Patch has been tested only on MySQL DB Flavor.
> 2. New Policies will not be added in any security zone except the unzone one.
> 
> 
> Thanks,
> 
> Pradeep Agrawal
> 
>



[jira] [Updated] (RANGER-2764) Role API : Duplicate key value violates unique constraint "x_ranger_global_state_uk_state_name"

2020-03-19 Thread Mehul Parikh (Jira)


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

Mehul Parikh updated RANGER-2764:
-
Attachment: RANGER-2764.patch

> Role API : Duplicate key value violates unique constraint 
> "x_ranger_global_state_uk_state_name"
> ---
>
> Key: RANGER-2764
> URL: https://issues.apache.org/jira/browse/RANGER-2764
> Project: Ranger
>  Issue Type: Improvement
>  Components: Ranger
>Affects Versions: ranger-2.0
>Reporter: Mehul Parikh
>Assignee: Mahesh Hanumant Bandal
>Priority: Major
>  Labels: patch
> Fix For: master
>
> Attachments: 0001-insert-statename-in-x-ranger-global-state.patch, 
> RANGER-2764.patch
>
>
> When Role creation is tried in multiple thread, it fails with exception for 
> duplicate key constraint : 
> {code:java}
> 2020-03-12 14:33:26,670 ERROR org.apache.ranger.rest.RoleREST: 
> createRole({name=dummy_role1, description=dummy role1 - Cluster1, options={}, 
> users=[], groups=[{hive, false}, {roleAdmin, false}], roles=[], 
> createdByUser=null}) failed
> javax.persistence.PersistenceException: Exception [EclipseLink-4002] (Eclipse 
> Persistence Services - 2.5.2.v20140319-9ad6abd): 
> org.eclipse.persistence.exceptions.DatabaseException
> Internal Exception: org.postgresql.util.PSQLException: ERROR: duplicate key 
> value violates unique constraint "x_ranger_global_state_uk_state_name"
>   Detail: Key (state_name)=(RangerRole) already exists.
> Error Code: 0
> Call: INSERT INTO x_ranger_global_state (id, ADDED_BY_ID, app_data, 
> CREATE_TIME, state_name, UPDATE_TIME, UPD_BY_ID, version) VALUES (?, ?, ?, ?, 
> ?, ?, ?, ?)
> bind => [8 parameters bound]
> at 
> org.eclipse.persistence.internal.jpa.EntityManagerImpl.flush(EntityManagerImpl.java:868)
> at sun.reflect.GeneratedMethodAccessor79.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (RANGER-2764) Role API : Duplicate key value violates unique constraint "x_ranger_global_state_uk_state_name"

2020-03-19 Thread Mahesh Hanumant Bandal (Jira)


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

Mahesh Hanumant Bandal updated RANGER-2764:
---
Attachment: 0001-insert-statename-in-x-ranger-global-state.patch

> Role API : Duplicate key value violates unique constraint 
> "x_ranger_global_state_uk_state_name"
> ---
>
> Key: RANGER-2764
> URL: https://issues.apache.org/jira/browse/RANGER-2764
> Project: Ranger
>  Issue Type: Improvement
>  Components: Ranger
>Reporter: Mehul Parikh
>Assignee: Mahesh Hanumant Bandal
>Priority: Major
> Attachments: 0001-insert-statename-in-x-ranger-global-state.patch
>
>
> When Role creation is tried in multiple thread, it fails with exception for 
> duplicate key constraint : 
> {code:java}
> 2020-03-12 14:33:26,670 ERROR org.apache.ranger.rest.RoleREST: 
> createRole({name=dummy_role1, description=dummy role1 - Cluster1, options={}, 
> users=[], groups=[{hive, false}, {roleAdmin, false}], roles=[], 
> createdByUser=null}) failed
> javax.persistence.PersistenceException: Exception [EclipseLink-4002] (Eclipse 
> Persistence Services - 2.5.2.v20140319-9ad6abd): 
> org.eclipse.persistence.exceptions.DatabaseException
> Internal Exception: org.postgresql.util.PSQLException: ERROR: duplicate key 
> value violates unique constraint "x_ranger_global_state_uk_state_name"
>   Detail: Key (state_name)=(RangerRole) already exists.
> Error Code: 0
> Call: INSERT INTO x_ranger_global_state (id, ADDED_BY_ID, app_data, 
> CREATE_TIME, state_name, UPDATE_TIME, UPD_BY_ID, version) VALUES (?, ?, ?, ?, 
> ?, ?, ?, ?)
> bind => [8 parameters bound]
> at 
> org.eclipse.persistence.internal.jpa.EntityManagerImpl.flush(EntityManagerImpl.java:868)
> at sun.reflect.GeneratedMethodAccessor79.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (RANGER-2724) Support EXECUTE permission in HBase Authorisation

2020-03-19 Thread Rajeshbabu Chintaguntla (Jira)


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

Rajeshbabu Chintaguntla commented on RANGER-2724:
-

uploaded the screenshots how the execute is showing in permissions and policy 
definition.

> Support EXECUTE permission in HBase Authorisation
> -
>
> Key: RANGER-2724
> URL: https://issues.apache.org/jira/browse/RANGER-2724
> Project: Ranger
>  Issue Type: Improvement
>  Components: Ranger
>Reporter: Rajeshbabu Chintaguntla
>Assignee: Rajeshbabu Chintaguntla
>Priority: Major
> Attachments: 
> 0001-RANGER-2724-Support-EXECUTE-permission-in-HBase-Auth.patch, 
> RANGER-2724.patch, Screen Shot 2020-03-18 at 12.58.42 PM.png, Screen Shot 
> 2020-03-19 at 4.00.22 PM.png
>
>
> HBase Authorisation supports execute permission along with read,write,create 
> and admin. 
> https://docs.cloudera.com/documentation/enterprise/6/6.3/topics/cdh_sg_hbase_authorization.html#
> # Read (R) - can read data at the given scope
> # Write (W) - can write data at the given scope
> # Execute (X) - can execute coprocessor endpoints at the given scope
> # Create (C) - can create tables or drop tables (even those they did not 
> create) at the given scope
> # Admin (A) - can perform cluster operations such as balancing the cluster or 
> assigning regions at the given scope
> In the HBase we can define the endpoint implementations to extend the HBase 
> functionality without touching the core. These endpoints can be called in 
> table scope.
> Example: Endpoint section in 
> https://blogs.apache.org/hbase/entry/coprocessor_introduction
> To run the endpoint implementations users can be authorised  with execute 
> permissions. There are hooks also coprocessor hooks also supported for this 
> endpoint invocations.
> {noformat}
> public Message 
> preEndpointInvocation(ObserverContext ctx, 
> Service service, String methodName, Message request) throws IOException {
> if (this.shouldCheckExecPermission && !(service instanceof 
> AccessControlService)) {
> this.requirePermission(ctx, "invoke(" + 
> service.getDescriptorForType().getName() + "." + methodName + ")", 
> this.getTableName((RegionCoprocessorEnvironment)ctx.getEnvironment()), 
> (byte[])null, (byte[])null, Action.EXEC);
> }
> return request;
> }
> public void 
> postEndpointInvocation(ObserverContext ctx, 
> Service service, String methodName, Message request, Builder responseBuilder) 
> throws IOException {
> }
> {noformat}
> Any way this execute permission is optional but better to have in the Ranger 
> mainly in case of Phoenix we do use most of the coprocessor endpoints to 
> tackle with meta data for tables/resources to be written to system tables. So 
> It would be helpful to have it.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (RANGER-2724) Support EXECUTE permission in HBase Authorisation

2020-03-19 Thread Rajeshbabu Chintaguntla (Jira)


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

Rajeshbabu Chintaguntla updated RANGER-2724:

Attachment: Screen Shot 2020-03-19 at 4.00.22 PM.png

> Support EXECUTE permission in HBase Authorisation
> -
>
> Key: RANGER-2724
> URL: https://issues.apache.org/jira/browse/RANGER-2724
> Project: Ranger
>  Issue Type: Improvement
>  Components: Ranger
>Reporter: Rajeshbabu Chintaguntla
>Assignee: Rajeshbabu Chintaguntla
>Priority: Major
> Attachments: 
> 0001-RANGER-2724-Support-EXECUTE-permission-in-HBase-Auth.patch, 
> RANGER-2724.patch, Screen Shot 2020-03-18 at 12.58.42 PM.png, Screen Shot 
> 2020-03-19 at 4.00.22 PM.png
>
>
> HBase Authorisation supports execute permission along with read,write,create 
> and admin. 
> https://docs.cloudera.com/documentation/enterprise/6/6.3/topics/cdh_sg_hbase_authorization.html#
> # Read (R) - can read data at the given scope
> # Write (W) - can write data at the given scope
> # Execute (X) - can execute coprocessor endpoints at the given scope
> # Create (C) - can create tables or drop tables (even those they did not 
> create) at the given scope
> # Admin (A) - can perform cluster operations such as balancing the cluster or 
> assigning regions at the given scope
> In the HBase we can define the endpoint implementations to extend the HBase 
> functionality without touching the core. These endpoints can be called in 
> table scope.
> Example: Endpoint section in 
> https://blogs.apache.org/hbase/entry/coprocessor_introduction
> To run the endpoint implementations users can be authorised  with execute 
> permissions. There are hooks also coprocessor hooks also supported for this 
> endpoint invocations.
> {noformat}
> public Message 
> preEndpointInvocation(ObserverContext ctx, 
> Service service, String methodName, Message request) throws IOException {
> if (this.shouldCheckExecPermission && !(service instanceof 
> AccessControlService)) {
> this.requirePermission(ctx, "invoke(" + 
> service.getDescriptorForType().getName() + "." + methodName + ")", 
> this.getTableName((RegionCoprocessorEnvironment)ctx.getEnvironment()), 
> (byte[])null, (byte[])null, Action.EXEC);
> }
> return request;
> }
> public void 
> postEndpointInvocation(ObserverContext ctx, 
> Service service, String methodName, Message request, Builder responseBuilder) 
> throws IOException {
> }
> {noformat}
> Any way this execute permission is optional but better to have in the Ranger 
> mainly in case of Phoenix we do use most of the coprocessor endpoints to 
> tackle with meta data for tables/resources to be written to system tables. So 
> It would be helpful to have it.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (RANGER-2724) Support EXECUTE permission in HBase Authorisation

2020-03-19 Thread Rajeshbabu Chintaguntla (Jira)


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

Rajeshbabu Chintaguntla commented on RANGER-2724:
-

Uploaded patch for review at https://reviews.apache.org/r/72247/
[~rmani] Could you please review it. Thanks.

> Support EXECUTE permission in HBase Authorisation
> -
>
> Key: RANGER-2724
> URL: https://issues.apache.org/jira/browse/RANGER-2724
> Project: Ranger
>  Issue Type: Improvement
>  Components: Ranger
>Reporter: Rajeshbabu Chintaguntla
>Assignee: Rajeshbabu Chintaguntla
>Priority: Major
> Attachments: 
> 0001-RANGER-2724-Support-EXECUTE-permission-in-HBase-Auth.patch, 
> RANGER-2724.patch, Screen Shot 2020-03-18 at 12.58.42 PM.png
>
>
> HBase Authorisation supports execute permission along with read,write,create 
> and admin. 
> https://docs.cloudera.com/documentation/enterprise/6/6.3/topics/cdh_sg_hbase_authorization.html#
> # Read (R) - can read data at the given scope
> # Write (W) - can write data at the given scope
> # Execute (X) - can execute coprocessor endpoints at the given scope
> # Create (C) - can create tables or drop tables (even those they did not 
> create) at the given scope
> # Admin (A) - can perform cluster operations such as balancing the cluster or 
> assigning regions at the given scope
> In the HBase we can define the endpoint implementations to extend the HBase 
> functionality without touching the core. These endpoints can be called in 
> table scope.
> Example: Endpoint section in 
> https://blogs.apache.org/hbase/entry/coprocessor_introduction
> To run the endpoint implementations users can be authorised  with execute 
> permissions. There are hooks also coprocessor hooks also supported for this 
> endpoint invocations.
> {noformat}
> public Message 
> preEndpointInvocation(ObserverContext ctx, 
> Service service, String methodName, Message request) throws IOException {
> if (this.shouldCheckExecPermission && !(service instanceof 
> AccessControlService)) {
> this.requirePermission(ctx, "invoke(" + 
> service.getDescriptorForType().getName() + "." + methodName + ")", 
> this.getTableName((RegionCoprocessorEnvironment)ctx.getEnvironment()), 
> (byte[])null, (byte[])null, Action.EXEC);
> }
> return request;
> }
> public void 
> postEndpointInvocation(ObserverContext ctx, 
> Service service, String methodName, Message request, Builder responseBuilder) 
> throws IOException {
> }
> {noformat}
> Any way this execute permission is optional but better to have in the Ranger 
> mainly in case of Phoenix we do use most of the coprocessor endpoints to 
> tackle with meta data for tables/resources to be written to system tables. So 
> It would be helpful to have it.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (RANGER-2724) Support EXECUTE permission in HBase Authorisation

2020-03-19 Thread Rajeshbabu Chintaguntla (Jira)


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

Rajeshbabu Chintaguntla updated RANGER-2724:

Attachment: Screen Shot 2020-03-18 at 12.58.42 PM.png

> Support EXECUTE permission in HBase Authorisation
> -
>
> Key: RANGER-2724
> URL: https://issues.apache.org/jira/browse/RANGER-2724
> Project: Ranger
>  Issue Type: Improvement
>  Components: Ranger
>Reporter: Rajeshbabu Chintaguntla
>Assignee: Rajeshbabu Chintaguntla
>Priority: Major
> Attachments: 
> 0001-RANGER-2724-Support-EXECUTE-permission-in-HBase-Auth.patch, 
> RANGER-2724.patch, Screen Shot 2020-03-18 at 12.58.42 PM.png
>
>
> HBase Authorisation supports execute permission along with read,write,create 
> and admin. 
> https://docs.cloudera.com/documentation/enterprise/6/6.3/topics/cdh_sg_hbase_authorization.html#
> # Read (R) - can read data at the given scope
> # Write (W) - can write data at the given scope
> # Execute (X) - can execute coprocessor endpoints at the given scope
> # Create (C) - can create tables or drop tables (even those they did not 
> create) at the given scope
> # Admin (A) - can perform cluster operations such as balancing the cluster or 
> assigning regions at the given scope
> In the HBase we can define the endpoint implementations to extend the HBase 
> functionality without touching the core. These endpoints can be called in 
> table scope.
> Example: Endpoint section in 
> https://blogs.apache.org/hbase/entry/coprocessor_introduction
> To run the endpoint implementations users can be authorised  with execute 
> permissions. There are hooks also coprocessor hooks also supported for this 
> endpoint invocations.
> {noformat}
> public Message 
> preEndpointInvocation(ObserverContext ctx, 
> Service service, String methodName, Message request) throws IOException {
> if (this.shouldCheckExecPermission && !(service instanceof 
> AccessControlService)) {
> this.requirePermission(ctx, "invoke(" + 
> service.getDescriptorForType().getName() + "." + methodName + ")", 
> this.getTableName((RegionCoprocessorEnvironment)ctx.getEnvironment()), 
> (byte[])null, (byte[])null, Action.EXEC);
> }
> return request;
> }
> public void 
> postEndpointInvocation(ObserverContext ctx, 
> Service service, String methodName, Message request, Builder responseBuilder) 
> throws IOException {
> }
> {noformat}
> Any way this execute permission is optional but better to have in the Ranger 
> mainly in case of Phoenix we do use most of the coprocessor endpoints to 
> tackle with meta data for tables/resources to be written to system tables. So 
> It would be helpful to have it.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


Review Request 72247: RANGER-2724 Support EXECUTE permission in HBase Authorisation

2020-03-19 Thread Rajeshbabu Chintaguntla

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

Review request for ranger and Ramesh Mani.


Repository: ranger


Description
---

- added execute permission to HBase service def
   - Added java patch file to support execute permission
   - Made changes in Ranger coprocessor to check for exec permission in 
endpoint coporcessor hook.


Diffs
-

  agents-common/src/main/resources/service-defs/ranger-servicedef-hbase.json 
f98c919a1 
  
hbase-agent/src/main/java/org/apache/ranger/authorization/hbase/HbaseAuthUtils.java
 f8ee168d7 
  
hbase-agent/src/main/java/org/apache/ranger/authorization/hbase/HbaseAuthUtilsImpl.java
 c2e1e7753 
  
hbase-agent/src/main/java/org/apache/ranger/authorization/hbase/RangerAuthorizationCoprocessor.java
 952ef61dc 
  
hbase-agent/src/test/java/org/apache/ranger/authorization/hbase/HbaseAuthUtilsImplTest.java
 1b8edd437 
  security-admin/db/mysql/optimized/current/ranger_core_db_mysql.sql 47618f6b3 
  security-admin/db/oracle/optimized/current/ranger_core_db_oracle.sql 
e59e7de61 
  security-admin/db/postgres/optimized/current/ranger_core_db_postgres.sql 
37ea61912 
  
security-admin/db/sqlanywhere/optimized/current/ranger_core_db_sqlanywhere.sql 
bd1c47cc4 
  security-admin/db/sqlserver/optimized/current/ranger_core_db_sqlserver.sql 
22e1746f2 
  
security-admin/src/main/java/org/apache/ranger/patch/PatchForHBaseServiceDefUpdate_J10034.java
 PRE-CREATION 


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


Testing
---

Tested in the cluster and ranger admin is showing the execute to select along 
with create,read,write and admin. Verified policy creation by providing the 
execute permission for an user and listed the policy it's displaying properly.


Thanks,

Rajeshbabu Chintaguntla



[jira] [Updated] (RANGER-2724) Support EXECUTE permission in HBase Authorisation

2020-03-19 Thread Rajeshbabu Chintaguntla (Jira)


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

Rajeshbabu Chintaguntla updated RANGER-2724:

Attachment: 0001-RANGER-2724-Support-EXECUTE-permission-in-HBase-Auth.patch

> Support EXECUTE permission in HBase Authorisation
> -
>
> Key: RANGER-2724
> URL: https://issues.apache.org/jira/browse/RANGER-2724
> Project: Ranger
>  Issue Type: Improvement
>  Components: Ranger
>Reporter: Rajeshbabu Chintaguntla
>Assignee: Rajeshbabu Chintaguntla
>Priority: Major
> Attachments: 
> 0001-RANGER-2724-Support-EXECUTE-permission-in-HBase-Auth.patch, 
> RANGER-2724.patch
>
>
> HBase Authorisation supports execute permission along with read,write,create 
> and admin. 
> https://docs.cloudera.com/documentation/enterprise/6/6.3/topics/cdh_sg_hbase_authorization.html#
> # Read (R) - can read data at the given scope
> # Write (W) - can write data at the given scope
> # Execute (X) - can execute coprocessor endpoints at the given scope
> # Create (C) - can create tables or drop tables (even those they did not 
> create) at the given scope
> # Admin (A) - can perform cluster operations such as balancing the cluster or 
> assigning regions at the given scope
> In the HBase we can define the endpoint implementations to extend the HBase 
> functionality without touching the core. These endpoints can be called in 
> table scope.
> Example: Endpoint section in 
> https://blogs.apache.org/hbase/entry/coprocessor_introduction
> To run the endpoint implementations users can be authorised  with execute 
> permissions. There are hooks also coprocessor hooks also supported for this 
> endpoint invocations.
> {noformat}
> public Message 
> preEndpointInvocation(ObserverContext ctx, 
> Service service, String methodName, Message request) throws IOException {
> if (this.shouldCheckExecPermission && !(service instanceof 
> AccessControlService)) {
> this.requirePermission(ctx, "invoke(" + 
> service.getDescriptorForType().getName() + "." + methodName + ")", 
> this.getTableName((RegionCoprocessorEnvironment)ctx.getEnvironment()), 
> (byte[])null, (byte[])null, Action.EXEC);
> }
> return request;
> }
> public void 
> postEndpointInvocation(ObserverContext ctx, 
> Service service, String methodName, Message request, Builder responseBuilder) 
> throws IOException {
> }
> {noformat}
> Any way this execute permission is optional but better to have in the Ranger 
> mainly in case of Phoenix we do use most of the coprocessor endpoints to 
> tackle with meta data for tables/resources to be written to system tables. So 
> It would be helpful to have it.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (RANGER-2764) Role API : Duplicate key value violates unique constraint "x_ranger_global_state_uk_state_name"

2020-03-19 Thread Mehul Parikh (Jira)
Mehul Parikh created RANGER-2764:


 Summary: Role API : Duplicate key value violates unique constraint 
"x_ranger_global_state_uk_state_name"
 Key: RANGER-2764
 URL: https://issues.apache.org/jira/browse/RANGER-2764
 Project: Ranger
  Issue Type: Improvement
  Components: Ranger
Reporter: Mehul Parikh
Assignee: Mahesh Hanumant Bandal


When Role creation is tried in multiple thread, it fails with exception for 
duplicate key constraint : 

{code:java}
2020-03-12 14:33:26,670 ERROR org.apache.ranger.rest.RoleREST: 
createRole({name=dummy_role1, description=dummy role1 - Cluster1, options={}, 
users=[], groups=[{hive, false}, {roleAdmin, false}], roles=[], 
createdByUser=null}) failed
javax.persistence.PersistenceException: Exception [EclipseLink-4002] (Eclipse 
Persistence Services - 2.5.2.v20140319-9ad6abd): 
org.eclipse.persistence.exceptions.DatabaseException
Internal Exception: org.postgresql.util.PSQLException: ERROR: duplicate key 
value violates unique constraint "x_ranger_global_state_uk_state_name"
  Detail: Key (state_name)=(RangerRole) already exists.
Error Code: 0
Call: INSERT INTO x_ranger_global_state (id, ADDED_BY_ID, app_data, 
CREATE_TIME, state_name, UPDATE_TIME, UPD_BY_ID, version) VALUES (?, ?, ?, ?, 
?, ?, ?, ?)
bind => [8 parameters bound]
at 
org.eclipse.persistence.internal.jpa.EntityManagerImpl.flush(EntityManagerImpl.java:868)
at sun.reflect.GeneratedMethodAccessor79.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

{code}




--
This message was sent by Atlassian Jira
(v8.3.4#803005)