[GitHub] [ranger] akatona84 closed pull request #132: RANGER-2426: Using kafka-clients artifact only instead of kafka core …

2022-02-24 Thread GitBox 


akatona84 closed pull request #132:
URL: https://github.com/apache/ranger/pull/132


   


-- 
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

[jira] [Updated] (RANGER-3643) Directly expose plugin authentication related attributes in the service page.

2022-02-24 Thread kirby zhou (Jira) 


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

kirby zhou updated RANGER-3643:
---
Description: 
Should directly expose plugin authentication related attributes in the service 
page.

 
 # tag.download.auth.users
 # service.admin.users
 # policy.download.auth.users
 # policy.grantrevoke.auth.users

Just like commonNameForCertificate which is already on service pages

!WhatIWant.jpg|width=312,height=331!

 

  was:
Should directly expose plugin authentication related attributes in the service 
page.

 
 # tag.download.auth.users
 # service.admin.users
 # policy.download.auth.users
 # policy.grantrevoke.auth.users

Just like commonNameForCertificate which is already on service pages

 


> Directly expose plugin authentication related attributes in the service page.
> -
>
> Key: RANGER-3643
> URL: https://issues.apache.org/jira/browse/RANGER-3643
> Project: Ranger
>  Issue Type: Improvement
>  Components: admin, plugins
>Affects Versions: 3.0.0, 2.3.0
>Reporter: kirby zhou
>Priority: Major
> Attachments: WhatIWant.jpg
>
>
> Should directly expose plugin authentication related attributes in the 
> service page.
>  
>  # tag.download.auth.users
>  # service.admin.users
>  # policy.download.auth.users
>  # policy.grantrevoke.auth.users
> Just like commonNameForCertificate which is already on service pages
> !WhatIWant.jpg|width=312,height=331!
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (RANGER-3643) Directly expose plugin authentication related attributes in the service page.

2022-02-24 Thread kirby zhou (Jira) 


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

kirby zhou updated RANGER-3643:
---
Attachment: WhatIWant.jpg

> Directly expose plugin authentication related attributes in the service page.
> -
>
> Key: RANGER-3643
> URL: https://issues.apache.org/jira/browse/RANGER-3643
> Project: Ranger
>  Issue Type: Improvement
>  Components: admin, plugins
>Affects Versions: 3.0.0, 2.3.0
>Reporter: kirby zhou
>Priority: Major
> Attachments: WhatIWant.jpg
>
>
> Should directly expose plugin authentication related attributes in the 
> service page.
>  
>  # tag.download.auth.users
>  # service.admin.users
>  # policy.download.auth.users
>  # policy.grantrevoke.auth.users
> Just like commonNameForCertificate which is already on service pages
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

Re: Review Request 73853: RANGER-3628 : Support fine grain authorization for different solr objects

2022-02-24 Thread Mateen Mansoori 

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

(Updated Feb. 25, 2022, 7:09 a.m.)


Review request for ranger, Mehul Parikh, Sailaja Polavarapu, and Velmurugan 
Periasamy.


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


Repository: ranger


Description
---

Modifying ranger solr plugin to allow granting the following privileges:
  
   - QUERY - read only privilege on an object
   - UPDATE - write only privilege on an object
   - All - read and write access

Privileges can be defined on the following objects:

- admin
- collections
- cores
- metrics
- autoscaling
- security
- collection
- config
- schema


Diffs (updated)
-

  agents-common/src/main/resources/service-defs/ranger-servicedef-solr.json 
dfaa2f701 
  
plugin-solr/src/main/java/org/apache/ranger/authorization/solr/authorizer/RangerSolrAuditHandler.java
 359211cb2 
  
plugin-solr/src/main/java/org/apache/ranger/authorization/solr/authorizer/RangerSolrAuthorizer.java
 d4dd7b0ec 
  
plugin-solr/src/main/java/org/apache/ranger/authorization/solr/authorizer/SolrAuthzUtil.java
 PRE-CREATION 
  
plugin-solr/src/main/java/org/apache/ranger/services/solr/RangerServiceSolr.java
 97909ae54 
  
plugin-solr/src/main/java/org/apache/ranger/services/solr/RangerSolrConstants.java
 PRE-CREATION 
  
plugin-solr/src/main/java/org/apache/ranger/services/solr/client/ServiceSolrClient.java
 5f7b9b924 
  
ranger-solr-plugin-shim/src/main/java/org/apache/ranger/authorization/solr/authorizer/RangerSolrAuthorizer.java
 3a10bc2af 


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

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


Testing
---

Tested on cluster with by covering test cases as per new implementation.


Thanks,

Mateen Mansoori

[jira] [Updated] (RANGER-3644) tagsync: FileTagSource to retry if Ranger is not reachable

2022-02-24 Thread Madhan Neethiraj (Jira) 


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

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

> tagsync: FileTagSource to retry if Ranger is not reachable
> --
>
> Key: RANGER-3644
> URL: https://issues.apache.org/jira/browse/RANGER-3644
> Project: Ranger
>  Issue Type: Bug
>  Components: tagsync
>Reporter: Madhan Neethiraj
>Assignee: Madhan Neethiraj
>Priority: Minor
> Fix For: 3.0.0, 2.3.0
>
> Attachments: RANGER-3644.patch
>
>
> In Docker setup, of Ranger tagsync is configured with FileTagSource to help 
> demonstrate tag-based policies. At the time of tagsync startup, if Ranger 
> admin is not available, tag upload fails and tagsync doesn't retry. It 
> requires tagsync restart to resolve this issue.
>  
> It will help to have FileTagSource retry tag upload in case of failure in 
> reaching Ranger.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

Review Request 73868: RANGER-3644: updated FileTagSource to retry on failure

2022-02-24 Thread Madhan Neethiraj 

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

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


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


Repository: ranger


Description
---

updated FileTagSource to retry uploading tags on failure


Diffs
-

  
tagsync/src/main/java/org/apache/ranger/tagsync/source/file/FileTagSource.java 
90adef25c 


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


Testing
---

- verified that tagsync retries uploading on failure


Thanks,

Madhan Neethiraj

[jira] [Created] (RANGER-3644) tagsync: FileTagSource to retry if Ranger is not reachable

2022-02-24 Thread Madhan Neethiraj (Jira) 
Madhan Neethiraj created RANGER-3644:


 Summary: tagsync: FileTagSource to retry if Ranger is not reachable
 Key: RANGER-3644
 URL: https://issues.apache.org/jira/browse/RANGER-3644
 Project: Ranger
  Issue Type: Bug
  Components: tagsync
Reporter: Madhan Neethiraj
Assignee: Madhan Neethiraj


In Docker setup, of Ranger tagsync is configured with FileTagSource to help 
demonstrate tag-based policies. At the time of tagsync startup, if Ranger admin 
is not available, tag upload fails and tagsync doesn't retry. It requires 
tagsync restart to resolve this issue.

 

It will help to have FileTagSource retry tag upload in case of failure in 
reaching Ranger.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (RANGER-3643) Directly expose plugin authentication related attributes in the service page.

2022-02-24 Thread kirby zhou (Jira) 
kirby zhou created RANGER-3643:
--

 Summary: Directly expose plugin authentication related attributes 
in the service page.
 Key: RANGER-3643
 URL: https://issues.apache.org/jira/browse/RANGER-3643
 Project: Ranger
  Issue Type: Improvement
  Components: admin, plugins
Affects Versions: 3.0.0, 2.3.0
Reporter: kirby zhou


Should directly expose plugin authentication related attributes in the service 
page.

 
 # tag.download.auth.users
 # service.admin.users
 # policy.download.auth.users
 # policy.grantrevoke.auth.users

Just like commonNameForCertificate which is already on service pages

 



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (RANGER-3642) Ranger - Upgrade jquery-ui to 1.13.1

2022-02-24 Thread Dhaval Rajpara (Jira) 


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

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

> Ranger - Upgrade jquery-ui to 1.13.1
> 
>
> Key: RANGER-3642
> URL: https://issues.apache.org/jira/browse/RANGER-3642
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Reporter: Dhaval Rajpara
>Assignee: Dhaval Rajpara
>Priority: Major
> Attachments: 0001-RANGER-3642.patch
>
>
> Ranger - Upgrade jquery-ui to 1.13.1



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (RANGER-3642) Ranger - Upgrade jquery-ui to 1.13.1

2022-02-24 Thread Dhaval Rajpara (Jira) 
Dhaval Rajpara created RANGER-3642:
--

 Summary: Ranger - Upgrade jquery-ui to 1.13.1
 Key: RANGER-3642
 URL: https://issues.apache.org/jira/browse/RANGER-3642
 Project: Ranger
  Issue Type: Bug
  Components: Ranger
Reporter: Dhaval Rajpara
Assignee: Dhaval Rajpara


Ranger - Upgrade jquery-ui to 1.13.1



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Resolved] (RANGER-2426) ranger-plugins-audits should depend on kafka-clients not kafka server

2022-02-24 Thread Madhan Neethiraj (Jira) 


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

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

[~akatona] - thank you for the patch. The patch is now in following branches.

master branch:
{noformat}
commit 4f4184d6183ef52c07f96b1116bf21eae0c32b72 (HEAD -> master, origin/master, 
origin/HEAD)
Author: Andras Katona 
Date:   Thu Dec 10 14:00:52 2020 +0100

RANGER-2426: Using kafka-clients artifact only instead of kafka core in 
ranger-plugins-audit, ranger-schema-registry-plugin and ranger-tagsync modules

Signed-off-by: Madhan Neethiraj 
{noformat}
 

ranger-2.3 branch:
{noformat}
commit 7680d0f63ce838742ef51ab54720c0f7636d6734 (HEAD -> ranger-2.3, 
origin/ranger-2.3)
Author: Andras Katona 
Date:   Thu Dec 10 14:00:52 2020 +0100

RANGER-2426: Using kafka-clients artifact only instead of kafka core in 
ranger-plugins-audit, ranger-schema-registry-plugin and ranger-tagsync modules

Signed-off-by: Madhan Neethiraj 
(cherry picked from commit 4f4184d6183ef52c07f96b1116bf21eae0c32b72)
{noformat}

> ranger-plugins-audits should depend on kafka-clients not kafka server
> -
>
> Key: RANGER-2426
> URL: https://issues.apache.org/jira/browse/RANGER-2426
> Project: Ranger
>  Issue Type: Bug
>  Components: audit
>Reporter: Fredy Wijaya
>Assignee: Andras Katona
>Priority: Major
> Fix For: 3.0.0, 2.3.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> https://github.com/apache/ranger/blob/f2d310a54ee64a1738a9c1a6afdd93d032e64ddf/agents-audit/pom.xml#L72
> To reduce the transitive dependency, ranger-plugins-audit should depend on 
> kafka-clients.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Assigned] (RANGER-2426) ranger-plugins-audits should depend on kafka-clients not kafka server

2022-02-24 Thread Madhan Neethiraj (Jira) 


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

Madhan Neethiraj reassigned RANGER-2426:


Assignee: Andras Katona

> ranger-plugins-audits should depend on kafka-clients not kafka server
> -
>
> Key: RANGER-2426
> URL: https://issues.apache.org/jira/browse/RANGER-2426
> Project: Ranger
>  Issue Type: Bug
>  Components: audit
>Reporter: Fredy Wijaya
>Assignee: Andras Katona
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> https://github.com/apache/ranger/blob/f2d310a54ee64a1738a9c1a6afdd93d032e64ddf/agents-audit/pom.xml#L72
> To reduce the transitive dependency, ranger-plugins-audit should depend on 
> kafka-clients.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

Re: Review Request 73854: RANGER-3629 : Handle solr permissions during upgrade

2022-02-24 Thread Sailaja Polavarapu 

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


Ship it!




Ship It!

- Sailaja Polavarapu


On Feb. 22, 2022, 4:22 p.m., Mateen Mansoori wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/73854/
> ---
> 
> (Updated Feb. 22, 2022, 4:22 p.m.)
> 
> 
> Review request for ranger, Jayendra Parab, Mehul Parikh, Sailaja Polavarapu, 
> and Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-3629
> https://issues.apache.org/jira/browse/RANGER-3629
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> Handling permissions during upgrades
> Since we are moving to a finer grained privilege model, a 100% mapping will 
> likely not be possible.
> 
> When a user has solr_admin access type privileges on all collections (*), we 
> are mapping it to:
> - admin=*->(QERY and UPDATE)
> - collection=*->(QERY and UPDATE)
> - schemas=*->(QERY and UPDATE)
> - configs=*->(QERY and UPDATE)
> 
> When a user has solr_admin access type on a particular collection 
> collection_name, we are mapping it to
> - collection=collection_name->(QERY and UPDATE)
> - schemas=collection_name->(QERY and UPDATE)
> 
> One should verify their permissions after the upgrade.
> 
> 
> Diffs
> -
> 
>   security-admin/db/mysql/optimized/current/ranger_core_db_mysql.sql 
> b603f96cd 
>   security-admin/db/oracle/optimized/current/ranger_core_db_oracle.sql 
> c111a28f6 
>   security-admin/db/postgres/optimized/current/ranger_core_db_postgres.sql 
> 854a2c676 
>   
> security-admin/db/sqlanywhere/optimized/current/ranger_core_db_sqlanywhere.sql
>  b45eace3b 
>   security-admin/db/sqlserver/optimized/current/ranger_core_db_sqlserver.sql 
> adec99857 
>   
> security-admin/src/main/java/org/apache/ranger/patch/PatchForSolrSvcDefAndPoliciesUpdate_J10055.java
>  PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/73854/diff/1/
> 
> 
> Testing
> ---
> 
> Verified upgrade on local/cluser - policies are getting migrated as per 
> description.
> 
> 
> Thanks,
> 
> Mateen Mansoori
> 
>

Re: Review Request 73853: RANGER-3628 : Support fine grain authorization for different solr objects

2022-02-24 Thread Sailaja Polavarapu 

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




plugin-solr/src/main/java/org/apache/ranger/authorization/solr/authorizer/RangerSolrAuthorizer.java
Line 580 (original), 627 (patched)


Can you please check the indentation?



plugin-solr/src/main/java/org/apache/ranger/authorization/solr/authorizer/RangerSolrAuthorizer.java
Lines 648 (patched)


Can you please check the indentation?



plugin-solr/src/main/java/org/apache/ranger/authorization/solr/authorizer/RangerSolrAuthorizer.java
Line 601 (original), 660 (patched)


Same as above


- Sailaja Polavarapu


On Feb. 22, 2022, 4:26 p.m., Mateen Mansoori wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/73853/
> ---
> 
> (Updated Feb. 22, 2022, 4:26 p.m.)
> 
> 
> Review request for ranger, Mehul Parikh, Sailaja Polavarapu, and Velmurugan 
> Periasamy.
> 
> 
> Bugs: RANGER-3628
> https://issues.apache.org/jira/browse/RANGER-3628
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> Modifying ranger solr plugin to allow granting the following privileges:
>   
>- QUERY - read only privilege on an object
>- UPDATE - write only privilege on an object
>- All - read and write access
> 
> Privileges can be defined on the following objects:
> 
> - admin
> - collections
> - cores
> - metrics
> - autoscaling
> - security
> - collection
> - config
> - schema
> 
> 
> Diffs
> -
> 
>   agents-common/src/main/resources/service-defs/ranger-servicedef-solr.json 
> dfaa2f701 
>   
> plugin-solr/src/main/java/org/apache/ranger/authorization/solr/authorizer/RangerSolrAuditHandler.java
>  359211cb2 
>   
> plugin-solr/src/main/java/org/apache/ranger/authorization/solr/authorizer/RangerSolrAuthorizer.java
>  d4dd7b0ec 
>   
> plugin-solr/src/main/java/org/apache/ranger/authorization/solr/authorizer/SolrAuthzUtil.java
>  PRE-CREATION 
>   
> plugin-solr/src/main/java/org/apache/ranger/services/solr/RangerServiceSolr.java
>  97909ae54 
>   
> plugin-solr/src/main/java/org/apache/ranger/services/solr/RangerSolrConstants.java
>  PRE-CREATION 
>   
> plugin-solr/src/main/java/org/apache/ranger/services/solr/client/ServiceSolrClient.java
>  5f7b9b924 
> 
> 
> Diff: https://reviews.apache.org/r/73853/diff/1/
> 
> 
> Testing
> ---
> 
> Tested on cluster with by covering test cases as per new implementation.
> 
> 
> Thanks,
> 
> Mateen Mansoori
> 
>

[jira] [Updated] (RANGER-3630) Support wildcards, group short names, and list of memberof attribute DNs for computing user search filter

2022-02-24 Thread Sailaja Polavarapu (Jira) 


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

Sailaja Polavarapu updated RANGER-3630:
---
Attachment: 0001-RANGER-3630-Added-code-to-support-wildcards-group-sh.patch

> Support wildcards, group short names, and list of memberof attribute DNs for 
> computing user search filter
> -
>
> Key: RANGER-3630
> URL: https://issues.apache.org/jira/browse/RANGER-3630
> Project: Ranger
>  Issue Type: New Feature
>  Components: Ranger, usersync
>Reporter: Sailaja Polavarapu
>Assignee: Sailaja Polavarapu
>Priority: Major
> Attachments: 
> 0001-RANGER-3630-Added-code-to-support-wildcards-group-sh.patch, 
> RANGER-3630_proposal.pdf
>
>
> Ranger Usersync provides multiple configuration properties to sync users & 
> groups from AD/LDAP. One of the key configuration properties is the User 
> Search filter (ranger.usersync.ldap.user.searchfilter). Currently, the value 
> of user search filter must be a valid ldap search filter and is used by 
> ranger usersync “as is” to limit the no. of users to be sync’d from AD/LDAP. 
> Example values include:
>  # samaccountname=*  
>  ** Syncs all users from a given user search base
>  # (|(memberof=CN=finance,ou=Hadoop 
> Groups,dc=apache,dc=org)(memberof=CN=eng_dev,ou=Hadoop 
> Groups,dc=apache,dc=org)(memberof=CN=eng_testing,ou=Hadoop 
> Groups,dc=apache,dc=org))
>  ** Sync users that are members of finance, eng_dev, and eng_testing groups
> According to [Microsoft 
> documentation|https://social.technet.microsoft.com/wiki/contents/articles/5392.active-directory-ldap-syntax-filters.aspx],
>  the wildcard character * is not allowed when the  is a DN 
> attribute. Examples of DN attributes are distinguishedName, manager, 
> directReports, member, and memberOf. If users need to be sync'd from multiple 
> Active Directory groups with memberOf filters, this value can quickly become 
> a long string of OR concatenated group DNs. A single misplaced character in 
> this cryptic string results in all users failing to sync. 



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

Review Request 73867: RANGER-3630: Support wildcards, group short names, and list of memberof attribute DNs for computing user search filter

2022-02-24 Thread Sailaja Polavarapu 

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

Review request for ranger, Mateen Mansoori, Mehul Parikh, Pradeep Agrawal, and 
Ramesh Mani.


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


Repository: ranger


Description
---

Introduced new usersync configuration "ranger.usersync.ldap.groupnames" that 
accepts ";" separated list of group names with wildcards, shortname, or DN 
format. During startup of usersync added logic to read this configuration to 
compute the user search filter. Also added new unit tests to cover some 
functional and error cases.


Diffs
-

  
ugsync/src/main/java/org/apache/ranger/ldapusersync/process/LdapUserGroupBuilder.java
 dae78e9f2 
  
ugsync/src/main/java/org/apache/ranger/unixusersync/config/UserGroupSyncConfig.java
 5f301651b 
  ugsync/src/test/java/org/apache/ranger/usergroupsync/TestLdapUserGroup.java 
78bc56cd9 


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


Testing
---

1. Patched cluster and ran some functional tests to verify the new logic
2. Ran few regression tests with AD/LDAP sync source


Thanks,

Sailaja Polavarapu

Re: Review Request 73863: RANGER-3638: Solr Ranger document level security breaks solr if collection is reloaded

2022-02-24 Thread Sailaja Polavarapu 

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

(Updated Feb. 25, 2022, 1:56 a.m.)


Review request for ranger, Abhay Kulkarni, Mateen Mansoori, Mehul Parikh, and 
Ramesh Mani.


Changes
---

incorporated review comments


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


Repository: ranger


Description
---

RangerSolrAuthorizer is a common implementation call for both SearchComponent 
(for Document level Authorization) and AuthorizationPlugin (for collection 
level Authorization). RangerSolrAuthorizer implementation close() shutdowns the 
plugin and should be avoided when the call is for SearchComponent. Added check 
to get the authorizer class name to determine if the call is for 
SearchComponent of for the authorization plugin.


Diffs (updated)
-

  
ranger-solr-plugin-shim/src/main/java/org/apache/ranger/authorization/solr/authorizer/RangerSolrAuthorizer.java
 dfa219670 


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

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


Testing
---

1. Patched cluster with the changes and verified the end to end functionality 
with and without Document level authorization
2. Verified basic functional tests and audits for regression testing.


Thanks,

Sailaja Polavarapu

[jira] [Updated] (RANGER-3637) setpolicies failed because of NullPointerException

2022-02-24 Thread wangzhongwei (Jira) 


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

wangzhongwei updated RANGER-3637:
-
Description: 
when use ranger hdfs plugins ,update policies and save the policies ,sometimes 
failed because of the NullPointerException,like the same issue as 
RANGER-3108,but its not the root reason

issue log:

2022-02-22 16:32:06,200 INFO 
org.apache.ranger.plugin.policyengine.RangerPolicyRepository: This policy 
engine contains 4 policy evaluators
2022-02-22 16:32:06,200 DEBUG 
org.apache.ranger.plugin.policyengine.RangerPolicyRepository: policy evaluation 
order: 4 policies
2022-02-22 16:32:06,200 DEBUG 
org.apache.ranger.plugin.policyengine.RangerPolicyRepository: policy evaluation 
order: #1 - policy id=1; name=all - path; evalOrder=9933
2022-02-22 16:32:06,200 DEBUG 
org.apache.ranger.plugin.policyengine.RangerPolicyRepository: policy evaluation 
order: #2 - policy id=2; name=kms-audit-path; evalOrder=9944
2022-02-22 16:32:06,200 DEBUG 
org.apache.ranger.plugin.policyengine.RangerPolicyRepository: policy evaluation 
order: #3 - policy id=3; name=hbase-archive; evalOrder=9944
2022-02-22 16:32:06,200 DEBUG 
org.apache.ranger.plugin.policyengine.RangerPolicyRepository: policy evaluation 
order: #4 - policy id=5; name=test2; evalOrder=9952
2022-02-22 16:32:06,200 DEBUG 
org.apache.ranger.plugin.policyengine.RangerPolicyRepository: dataMask policy 
evaluation order: 0 policies
2022-02-22 16:32:06,200 DEBUG 
org.apache.ranger.plugin.policyengine.RangerPolicyRepository: rowFilter policy 
evaluation order: 0 policies
2022-02-22 16:32:06,200 ERROR 
org.apache.ranger.plugin.service.RangerBasePlugin: setPolicies: policy engine 
initialization failed!  Leaving current policy engine as-is. Exception :
java.lang.NullPointerException
        at 
org.apache.ranger.plugin.policyengine.RangerPolicyRepository.init(RangerPolicyRepository.java:991)
        at 
org.apache.ranger.plugin.policyengine.RangerPolicyRepository.(RangerPolicyRepository.java:229)
        at 
org.apache.ranger.plugin.policyengine.RangerPolicyRepository.(RangerPolicyRepository.java:180)
        at 
org.apache.ranger.plugin.policyengine.PolicyEngine.(PolicyEngine.java:212)
        at 
org.apache.ranger.plugin.policyengine.RangerPolicyEngineImpl.(RangerPolicyEngineImpl.java:104)
        at 
org.apache.ranger.plugin.service.RangerBasePlugin.setPolicies(RangerBasePlugin.java:325)
        at 
org.apache.ranger.plugin.util.PolicyRefresher.loadPolicy(PolicyRefresher.java:263)
        at 
org.apache.ranger.plugin.util.PolicyRefresher.run(PolicyRefresher.java:209)
@                                                                               
           

 

 

  was:
when use ranger hdfs plugins ,update policies and save the policies ,sometimes 
failed because of the NullPointerException,like the same issue as 
RANGER-3108,but we should

make a non-empty judgment on  all 3 
lists:dataMaskPolicyEvaluators,rowFilterPolicyEvaluators,auditPolicyEvaluators 

issue log:

2022-02-22 16:32:06,200 INFO 
org.apache.ranger.plugin.policyengine.RangerPolicyRepository: This policy 
engine contains 4 policy evaluators
2022-02-22 16:32:06,200 DEBUG 
org.apache.ranger.plugin.policyengine.RangerPolicyRepository: policy evaluation 
order: 4 policies
2022-02-22 16:32:06,200 DEBUG 
org.apache.ranger.plugin.policyengine.RangerPolicyRepository: policy evaluation 
order: #1 - policy id=1; name=all - path; evalOrder=9933
2022-02-22 16:32:06,200 DEBUG 
org.apache.ranger.plugin.policyengine.RangerPolicyRepository: policy evaluation 
order: #2 - policy id=2; name=kms-audit-path; evalOrder=9944
2022-02-22 16:32:06,200 DEBUG 
org.apache.ranger.plugin.policyengine.RangerPolicyRepository: policy evaluation 
order: #3 - policy id=3; name=hbase-archive; evalOrder=9944
2022-02-22 16:32:06,200 DEBUG 
org.apache.ranger.plugin.policyengine.RangerPolicyRepository: policy evaluation 
order: #4 - policy id=5; name=test2; evalOrder=9952
2022-02-22 16:32:06,200 DEBUG 
org.apache.ranger.plugin.policyengine.RangerPolicyRepository: dataMask policy 
evaluation order: 0 policies
2022-02-22 16:32:06,200 DEBUG 
org.apache.ranger.plugin.policyengine.RangerPolicyRepository: rowFilter policy 
evaluation order: 0 policies
2022-02-22 16:32:06,200 ERROR 
org.apache.ranger.plugin.service.RangerBasePlugin: setPolicies: policy engine 
initialization failed!  Leaving current policy engine as-is. Exception :
java.lang.NullPointerException
        at 
org.apache.ranger.plugin.policyengine.RangerPolicyRepository.init(RangerPolicyRepository.java:991)
        at 
org.apache.ranger.plugin.policyengine.RangerPolicyRepository.(RangerPolicyRepository.java:229)
        at 
org.apache.ranger.plugin.policyengine.RangerPolicyRepository.(RangerPolicyRepository.java:180)
        at 
org.apache.ranger.plugin.policyengine.PolicyEngine.(PolicyEngine.java:212)
        at

Re: Review Request 73863: RANGER-3638: Solr Ranger document level security breaks solr if collection is reloaded

2022-02-24 Thread Madhan Neethiraj 

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


Fix it, then Ship it!





ranger-solr-plugin-shim/src/main/java/org/apache/ranger/authorization/solr/authorizer/RangerSolrAuthorizer.java
Lines 130 (patched)


I think following will make it a little easier to read; please consider:

  // close() to be forwarded only for authorizer instances
  // see: 
https://solr.apache.org/docs/8_11_1/solr-core/org/apache/solr/core/SolrInfoBean.html#getName--
  boolean isAuthorizer = StringUtils.equals(super.getName(), 
RANGER_SOLR_AUTHORIZER_IMPL_CLASSNAME);

  if (isAuthorizer) {
   ...
  } else {
if (LOG.isDebugEnabled()) {
  LOG.debug("RangerSolrAuthorizer.close(): not forwarding for instance 
'" + super.getName() + "'");
}
  }


- Madhan Neethiraj


On Feb. 24, 2022, 2:31 p.m., Sailaja Polavarapu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/73863/
> ---
> 
> (Updated Feb. 24, 2022, 2:31 p.m.)
> 
> 
> Review request for ranger, Abhay Kulkarni, Mateen Mansoori, Mehul Parikh, and 
> Ramesh Mani.
> 
> 
> Bugs: RANGER-3638
> https://issues.apache.org/jira/browse/RANGER-3638
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> RangerSolrAuthorizer is a common implementation call for both SearchComponent 
> (for Document level Authorization) and AuthorizationPlugin (for collection 
> level Authorization). RangerSolrAuthorizer implementation close() shutdowns 
> the plugin and should be avoided when the call is for SearchComponent. Added 
> check to get the authorizer class name to determine if the call is for 
> SearchComponent of for the authorization plugin.
> 
> 
> Diffs
> -
> 
>   
> ranger-solr-plugin-shim/src/main/java/org/apache/ranger/authorization/solr/authorizer/RangerSolrAuthorizer.java
>  dfa219670 
> 
> 
> Diff: https://reviews.apache.org/r/73863/diff/2/
> 
> 
> Testing
> ---
> 
> 1. Patched cluster with the changes and verified the end to end functionality 
> with and without Document level authorization
> 2. Verified basic functional tests and audits for regression testing.
> 
> 
> Thanks,
> 
> Sailaja Polavarapu
> 
>

Re: Review Request 73863: RANGER-3638: Solr Ranger document level security breaks solr if collection is reloaded

2022-02-24 Thread Ramesh Mani 

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


Ship it!




Ship It!

- Ramesh Mani


On Feb. 24, 2022, 2:31 p.m., Sailaja Polavarapu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/73863/
> ---
> 
> (Updated Feb. 24, 2022, 2:31 p.m.)
> 
> 
> Review request for ranger, Abhay Kulkarni, Mateen Mansoori, Mehul Parikh, and 
> Ramesh Mani.
> 
> 
> Bugs: RANGER-3638
> https://issues.apache.org/jira/browse/RANGER-3638
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> RangerSolrAuthorizer is a common implementation call for both SearchComponent 
> (for Document level Authorization) and AuthorizationPlugin (for collection 
> level Authorization). RangerSolrAuthorizer implementation close() shutdowns 
> the plugin and should be avoided when the call is for SearchComponent. Added 
> check to get the authorizer class name to determine if the call is for 
> SearchComponent of for the authorization plugin.
> 
> 
> Diffs
> -
> 
>   
> ranger-solr-plugin-shim/src/main/java/org/apache/ranger/authorization/solr/authorizer/RangerSolrAuthorizer.java
>  dfa219670 
> 
> 
> Diff: https://reviews.apache.org/r/73863/diff/2/
> 
> 
> Testing
> ---
> 
> 1. Patched cluster with the changes and verified the end to end functionality 
> with and without Document level authorization
> 2. Verified basic functional tests and audits for regression testing.
> 
> 
> Thanks,
> 
> Sailaja Polavarapu
> 
>

Re: Review Request 73863: RANGER-3638: Solr Ranger document level security breaks solr if collection is reloaded

2022-02-24 Thread Abhay Kulkarni 

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


Ship it!




Ship It!

- Abhay Kulkarni


On Feb. 24, 2022, 2:31 p.m., Sailaja Polavarapu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/73863/
> ---
> 
> (Updated Feb. 24, 2022, 2:31 p.m.)
> 
> 
> Review request for ranger, Abhay Kulkarni, Mateen Mansoori, Mehul Parikh, and 
> Ramesh Mani.
> 
> 
> Bugs: RANGER-3638
> https://issues.apache.org/jira/browse/RANGER-3638
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> RangerSolrAuthorizer is a common implementation call for both SearchComponent 
> (for Document level Authorization) and AuthorizationPlugin (for collection 
> level Authorization). RangerSolrAuthorizer implementation close() shutdowns 
> the plugin and should be avoided when the call is for SearchComponent. Added 
> check to get the authorizer class name to determine if the call is for 
> SearchComponent of for the authorization plugin.
> 
> 
> Diffs
> -
> 
>   
> ranger-solr-plugin-shim/src/main/java/org/apache/ranger/authorization/solr/authorizer/RangerSolrAuthorizer.java
>  dfa219670 
> 
> 
> Diff: https://reviews.apache.org/r/73863/diff/2/
> 
> 
> Testing
> ---
> 
> 1. Patched cluster with the changes and verified the end to end functionality 
> with and without Document level authorization
> 2. Verified basic functional tests and audits for regression testing.
> 
> 
> Thanks,
> 
> Sailaja Polavarapu
> 
>

Re: Review Request 73866: RANGER-2426: Using kafka-clients artifact only instead of kafka core in ranger-plugins-audit, ranger-schema-registry-plugin and ranger-tagsync modules

2022-02-24 Thread Madhan Neethiraj 

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


Ship it!




Ship It!

- Madhan Neethiraj


On Feb. 24, 2022, 3:14 p.m., Andras Katona wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/73866/
> ---
> 
> (Updated Feb. 24, 2022, 3:14 p.m.)
> 
> 
> Review request for ranger and Ramesh Mani.
> 
> 
> Bugs: RANGER-2426
> https://issues.apache.org/jira/browse/RANGER-2426
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> kafka core depencencies are not used any more hence we can remove them
> 
> 
> Diffs
> -
> 
>   agents-audit/pom.xml a1ec2f204 
>   plugin-schema-registry/pom.xml b89b5d889 
>   tagsync/pom.xml 8c4ecb204 
> 
> 
> Diff: https://reviews.apache.org/r/73866/diff/1/
> 
> 
> Testing
> ---
> 
> compiling and testing relevant modules via mvn
> 
> 
> Thanks,
> 
> Andras Katona
> 
>

[jira] [Commented] (RANGER-3634) Remove duplicate entries from usersync distribution file

2022-02-24 Thread Bhavik Patel (Jira) 


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

Bhavik Patel commented on RANGER-3634:
--

master branch commit link: 
https://github.com/apache/ranger/commit/3a4667342e653ca6132fcb140740a9e1b19b40b0

> Remove duplicate entries from usersync distribution file 
> -
>
> Key: RANGER-3634
> URL: https://issues.apache.org/jira/browse/RANGER-3634
> Project: Ranger
>  Issue Type: Improvement
>  Components: usersync
>Affects Versions: 3.0.0
>Reporter: Bhavik Patel
>Assignee: Bhavik Patel
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: 
> 0001-RANGER-3634-Remove-duplicate-entries-from-usersync-d.patch
>
>
> Remove duplicate entries from usersync distribution file 



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (RANGER-3624) Update Ranger services Password Policy

2022-02-24 Thread Bhavik Patel (Jira) 


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

Bhavik Patel updated RANGER-3624:
-
Affects Version/s: 2.3.0

> Update Ranger services Password Policy
> --
>
> Key: RANGER-3624
> URL: https://issues.apache.org/jira/browse/RANGER-3624
> Project: Ranger
>  Issue Type: Improvement
>  Components: admin
>Affects Versions: 3.0.0, 2.3.0
>Reporter: Bhavik Patel
>Assignee: Bhavik Patel
>Priority: Major
> Fix For: 3.0.0, 2.3.0
>
> Attachments: 
> 0001-RANGER-3624-Update-Ranger-services-Password-Policy.patch
>
>
> Current Password policies(validation) is not strong enough as it expect the 
> {*}"minimum 8 characters with minimum one alphabet and one numeric"{*}.
> In this improvement Jira will enhance the password policies to *"minimum 8 
> characters, at least one uppercase letter, one lowercase letter and one 
> numeric"*



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (RANGER-3624) Update Ranger services Password Policy

2022-02-24 Thread Bhavik Patel (Jira) 


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

Bhavik Patel commented on RANGER-3624:
--

master branch commit link: 
https://github.com/apache/ranger/commit/30486a024aa7be8707ba1050e5ebff6d866c9ba9
ranger-2.3 branch commit link: 
https://github.com/apache/ranger/commit/b0e7ded902b68bc1210098edcd8c367f230290f7

> Update Ranger services Password Policy
> --
>
> Key: RANGER-3624
> URL: https://issues.apache.org/jira/browse/RANGER-3624
> Project: Ranger
>  Issue Type: Improvement
>  Components: admin
>Affects Versions: 3.0.0
>Reporter: Bhavik Patel
>Assignee: Bhavik Patel
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: 
> 0001-RANGER-3624-Update-Ranger-services-Password-Policy.patch
>
>
> Current Password policies(validation) is not strong enough as it expect the 
> {*}"minimum 8 characters with minimum one alphabet and one numeric"{*}.
> In this improvement Jira will enhance the password policies to *"minimum 8 
> characters, at least one uppercase letter, one lowercase letter and one 
> numeric"*



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (RANGER-2426) ranger-plugins-audits should depend on kafka-clients not kafka server

2022-02-24 Thread Andras Katona (Jira) 


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

Andras Katona commented on RANGER-2426:
---

PR:
https://github.com/apache/ranger/pull/132
Reviewboard request:
https://reviews.apache.org/r/73866/

> ranger-plugins-audits should depend on kafka-clients not kafka server
> -
>
> Key: RANGER-2426
> URL: https://issues.apache.org/jira/browse/RANGER-2426
> Project: Ranger
>  Issue Type: Bug
>  Components: audit
>Reporter: Fredy Wijaya
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> https://github.com/apache/ranger/blob/f2d310a54ee64a1738a9c1a6afdd93d032e64ddf/agents-audit/pom.xml#L72
> To reduce the transitive dependency, ranger-plugins-audit should depend on 
> kafka-clients.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

Review Request 73866: RANGER-2426: Using kafka-clients artifact only instead of kafka core in ranger-plugins-audit, ranger-schema-registry-plugin and ranger-tagsync modules

2022-02-24 Thread Andras Katona via Review Board 

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

Review request for ranger and Ramesh Mani.


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


Repository: ranger


Description
---

kafka core depencencies are not used any more hence we can remove them


Diffs
-

  agents-audit/pom.xml a1ec2f204 
  plugin-schema-registry/pom.xml b89b5d889 
  tagsync/pom.xml 8c4ecb204 


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


Testing
---

compiling and testing relevant modules via mvn


Thanks,

Andras Katona

[jira] [Updated] (RANGER-3637) setpolicies failed because of NullPointerException

2022-02-24 Thread wangzhongwei (Jira) 


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

wangzhongwei updated RANGER-3637:
-
Attachment: RANGER-3637.004.patch

> setpolicies failed because of NullPointerException
> --
>
> Key: RANGER-3637
> URL: https://issues.apache.org/jira/browse/RANGER-3637
> Project: Ranger
>  Issue Type: Bug
>  Components: plugins
>Affects Versions: 2.2.0
> Environment: centos7 java1.8
>Reporter: wangzhongwei
>Priority: Major
> Attachments: RANGER-3637.001.patch, RANGER-3637.002.patch, 
> RANGER-3637.003.patch, RANGER-3637.004.patch, 
> image-2022-02-24-15-11-26-819.png
>
>   Original Estimate: 72h
>  Remaining Estimate: 72h
>
> when use ranger hdfs plugins ,update policies and save the policies 
> ,sometimes failed because of the NullPointerException,like the same issue as 
> RANGER-3108,but we should
> make a non-empty judgment on  all 3 
> lists:dataMaskPolicyEvaluators,rowFilterPolicyEvaluators,auditPolicyEvaluators
>  
> issue log:
> 2022-02-22 16:32:06,200 INFO 
> org.apache.ranger.plugin.policyengine.RangerPolicyRepository: This policy 
> engine contains 4 policy evaluators
> 2022-02-22 16:32:06,200 DEBUG 
> org.apache.ranger.plugin.policyengine.RangerPolicyRepository: policy 
> evaluation order: 4 policies
> 2022-02-22 16:32:06,200 DEBUG 
> org.apache.ranger.plugin.policyengine.RangerPolicyRepository: policy 
> evaluation order: #1 - policy id=1; name=all - path; evalOrder=9933
> 2022-02-22 16:32:06,200 DEBUG 
> org.apache.ranger.plugin.policyengine.RangerPolicyRepository: policy 
> evaluation order: #2 - policy id=2; name=kms-audit-path; evalOrder=9944
> 2022-02-22 16:32:06,200 DEBUG 
> org.apache.ranger.plugin.policyengine.RangerPolicyRepository: policy 
> evaluation order: #3 - policy id=3; name=hbase-archive; evalOrder=9944
> 2022-02-22 16:32:06,200 DEBUG 
> org.apache.ranger.plugin.policyengine.RangerPolicyRepository: policy 
> evaluation order: #4 - policy id=5; name=test2; evalOrder=9952
> 2022-02-22 16:32:06,200 DEBUG 
> org.apache.ranger.plugin.policyengine.RangerPolicyRepository: dataMask policy 
> evaluation order: 0 policies
> 2022-02-22 16:32:06,200 DEBUG 
> org.apache.ranger.plugin.policyengine.RangerPolicyRepository: rowFilter 
> policy evaluation order: 0 policies
> 2022-02-22 16:32:06,200 ERROR 
> org.apache.ranger.plugin.service.RangerBasePlugin: setPolicies: policy engine 
> initialization failed!  Leaving current policy engine as-is. Exception :
> java.lang.NullPointerException
>         at 
> org.apache.ranger.plugin.policyengine.RangerPolicyRepository.init(RangerPolicyRepository.java:991)
>         at 
> org.apache.ranger.plugin.policyengine.RangerPolicyRepository.(RangerPolicyRepository.java:229)
>         at 
> org.apache.ranger.plugin.policyengine.RangerPolicyRepository.(RangerPolicyRepository.java:180)
>         at 
> org.apache.ranger.plugin.policyengine.PolicyEngine.(PolicyEngine.java:212)
>         at 
> org.apache.ranger.plugin.policyengine.RangerPolicyEngineImpl.(RangerPolicyEngineImpl.java:104)
>         at 
> org.apache.ranger.plugin.service.RangerBasePlugin.setPolicies(RangerBasePlugin.java:325)
>         at 
> org.apache.ranger.plugin.util.PolicyRefresher.loadPolicy(PolicyRefresher.java:263)
>         at 
> org.apache.ranger.plugin.util.PolicyRefresher.run(PolicyRefresher.java:209)
> @                                                                             
>              
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

Re: Review Request 73863: RANGER-3638: Solr Ranger document level security breaks solr if collection is reloaded

2022-02-24 Thread Sailaja Polavarapu 

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

(Updated Feb. 24, 2022, 2:31 p.m.)


Review request for ranger, Abhay Kulkarni, Mateen Mansoori, Mehul Parikh, and 
Ramesh Mani.


Changes
---

Placed comments before checking the authorizer class name


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


Repository: ranger


Description
---

RangerSolrAuthorizer is a common implementation call for both SearchComponent 
(for Document level Authorization) and AuthorizationPlugin (for collection 
level Authorization). RangerSolrAuthorizer implementation close() shutdowns the 
plugin and should be avoided when the call is for SearchComponent. Added check 
to get the authorizer class name to determine if the call is for 
SearchComponent of for the authorization plugin.


Diffs (updated)
-

  
ranger-solr-plugin-shim/src/main/java/org/apache/ranger/authorization/solr/authorizer/RangerSolrAuthorizer.java
 dfa219670 


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

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


Testing
---

1. Patched cluster with the changes and verified the end to end functionality 
with and without Document level authorization
2. Verified basic functional tests and audits for regression testing.


Thanks,

Sailaja Polavarapu

[GitHub] [ranger] akatona84 opened a new pull request #132: RANGER-2426: Using kafka-clients artifact only instead of kafka core …

2022-02-24 Thread GitBox 


akatona84 opened a new pull request #132:
URL: https://github.com/apache/ranger/pull/132


   …in ranger-plugins-audit, ranger-schema-registry-plugin and ranger-tagsync 
modules


-- 
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

[jira] [Updated] (RANGER-3639) Ranger KMS should stop invading java package of hadoop

2022-02-24 Thread kirby zhou (Jira) 


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

kirby zhou updated RANGER-3639:
---
Summary: Ranger KMS should stop invading java package of hadoop  (was: 
Ranger KMS should refactor top stop invading java package of hadoop)

> Ranger KMS should stop invading java package of hadoop
> --
>
> Key: RANGER-3639
> URL: https://issues.apache.org/jira/browse/RANGER-3639
> Project: Ranger
>  Issue Type: Improvement
>  Components: kms
>Affects Versions: 3.0.0, 2.2.0, 2.3.0
>Reporter: kirby zhou
>Priority: Major
>
> Now, ranger-kms have some conflict packages with hadoop.
> org.apache.hadoop.crypto.key
> org.apache.hadoop.crypto.key.kms.server
>  
> It is caused by some historical reason.
> For example:
> Copied code from hadoop-kms, 
> Want to use protected method such as Metadata().
>  
> But it also creates some problems:
> 1. Developers need to be careful with files with duplicate names. such as:  
> KMSAcls.java
> [https://github.com/apache/hadoop/tree/trunk/hadoop-common-project/hadoop-kms/src/main/java/org/apache/hadoop/crypto/key/kms/server]
> 2. Sometime runtime conflict happens.
> 3. [split 
> package|https://blog.codefx.org/java/java-9-migration-guide/#Split-Packages]  
> can not work with Java-9 modules.
>  
> So we should do something to stop reuse the package name of original hadoop.
>  
>  
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (RANGER-3641) Add API to enhance KMS capabilities

2022-02-24 Thread kirby zhou (Jira) 
kirby zhou created RANGER-3641:
--

 Summary: Add API to enhance KMS capabilities
 Key: RANGER-3641
 URL: https://issues.apache.org/jira/browse/RANGER-3641
 Project: Ranger
  Issue Type: Improvement
  Components: kms
Affects Versions: 3.0.0, 2.3.0
Reporter: kirby zhou


Some APIs are very useful.

 
 * GenerateEEK with decrypted EEK returned together

Like:

{EEK, EK} = GenerateEEK2(KeyVersion)

This helps Program which request a EEK to encrypt something itself such like 
KUDU or MySQL.

It now takes 2 RPC calls to complete encryption. If a API can return EEK and EK 
together, we can save 1 RPC call.

 
 * Simple Encryption and Decryption API

Like:

{EncryptedData} = Encrypt(KeyVersion, PlainData)

{PlainData} = Decrypt(KeyVersion, EncryptedData)

This helps Ranger KMS works for some simple situation such as encrypting 
password.

 

 



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (RANGER-3640) The naming of log files is a mess.

2022-02-24 Thread kirby zhou (Jira) 
kirby zhou created RANGER-3640:
--

 Summary: The naming of log files is a mess.
 Key: RANGER-3640
 URL: https://issues.apache.org/jira/browse/RANGER-3640
 Project: Ranger
  Issue Type: Improvement
  Components: admin, kms
Affects Versions: 3.0.0, 2.3.0
Reporter: kirby zhou


Now we have some confusing default log filenames:

Sometimes we use "-", sometimes we use "_".

Sometimes we have "ranger-" prefix, sometimes we do not.

 

ranger{color:#ff}-{color}admin-${hostname}-${user}.log

ranger{color:#ff}_{color}admin{color:#ff}_{color}sql.log.*

ranger{color:#ff}_{color}admin{color:#ff}_{color}perf.log.*

 

kms{color:#ff}-{color}audit{color:#ff}-{color}${hostname}{color:#ff}-{color}${user}.log

ranger{color:#ff}_{color}kms{color:#ff}_{color}metric{color:#ff}_{color}data{color:#ff}_{color}for{color:#ff}_{color}${metric.type}.log

ranger{color:#ff}-{color}kms{color:#ff}-{color}${hostname}{color:#ff}-{color}${user}.log

 

These should be unified to improve the quality of our products.

 

 

 



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (RANGER-3612) KMS should either Die or Auto-Recover when its ranger-agent auth to KDC failed

2022-02-24 Thread kirby zhou (Jira) 


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

kirby zhou commented on RANGER-3612:


Anybody?

> KMS should either Die or Auto-Recover when its ranger-agent auth to KDC failed
> --
>
> Key: RANGER-3612
> URL: https://issues.apache.org/jira/browse/RANGER-3612
> Project: Ranger
>  Issue Type: Bug
>  Components: kms, plugins
>Affects Versions: 3.0.0, 2.2.0
>Reporter: kirby zhou
>Priority: Major
>
> If we install ranger agent to KMS, the agent would auth itself to KDC at 
> startup. But if it failed, it just print a log in ranger-kms-.log, 
> and the KMS can never recover to refresh its policies.
> {code:java}
> ]$ tail -f log/ranger-kms-ranger_kms-.log  | fgrep ERROR 
> 2022-02-09 19:00:18,227 ERROR MiscUtil - Failed to login with given keytab 
> and principal{code}
> {code:java}
> package org.apache.ranger.authorization.kms.authorizer;
> public class RangerKmsAuthorizer implements Runnable, KeyACLs {
> RangerKmsAuthorizer(Configuration conf) { 
>authWithKerberos(conf); 
> }
> private void authWithKerberos(Configuration conf) {
>     MiscUtil.authWithKerberos(keytab, principal, nameRules);
> }
> }
> package org.apache.ranger.audit.provider;
> public class MiscUtil {
> public static void authWithKerberos(...) {
>   try {
> {
>   UserGroupInformation ugi = UserGroupInformation
>  .loginUserFromKeytabAndReturnUGI(spnegoPrincipals[0],
>  keytab);
>   MiscUtil.setUGILoginUser(ugi, null);
>  }
>   } catch (Throwable t) {
> logger.error("Failed to login with given keytab and principal", t);
>   }
> }
> }{code}
>  
> There seems only one chance for plugin to auth to KDC, so it can not auto 
> recover.
> And MiscUtil.authWithKerberos never fail when auth failed, so KMS would not 
> die when the plugin failed.
> This situation is too unfriendly to administrators. It should be fixed.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (RANGER-3639) Ranger KMS should refactor top stop invading java package of hadoop

2022-02-24 Thread kirby zhou (Jira) 
kirby zhou created RANGER-3639:
--

 Summary: Ranger KMS should refactor top stop invading java package 
of hadoop
 Key: RANGER-3639
 URL: https://issues.apache.org/jira/browse/RANGER-3639
 Project: Ranger
  Issue Type: Improvement
  Components: kms
Affects Versions: 2.2.0, 3.0.0, 2.3.0
Reporter: kirby zhou


Now, ranger-kms have some conflict packages with hadoop.

org.apache.hadoop.crypto.key

org.apache.hadoop.crypto.key.kms.server

 

It is caused by some historical reason.

For example:

Copied code from hadoop-kms, 

Want to use protected method such as Metadata().

 

But it also creates some problems:

1. Developers need to be careful with files with duplicate names. such as:  
KMSAcls.java

[https://github.com/apache/hadoop/tree/trunk/hadoop-common-project/hadoop-kms/src/main/java/org/apache/hadoop/crypto/key/kms/server]

2. Sometime runtime conflict happens.

3. [split 
package|https://blog.codefx.org/java/java-9-migration-guide/#Split-Packages]  
can not work with Java-9 modules.

 

So we should do something to stop reuse the package name of original hadoop.

 

 

 

 



--
This message was sent by Atlassian Jira
(v8.20.1#820001)