[jira] [Commented] (RANGER-3691) Upgrade spring to 5.3.18 CVE-2022-22965

[Pradeep Agrawal (Jira)]

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

Pradeep Agrawal commented on RANGER-3691:
-

[~kirbyzhou]  : Please close the RR : [https://reviews.apache.org/r/73924]/

> Upgrade spring to 5.3.18 CVE-2022-22965
> ---
>
> Key: RANGER-3691
> URL: https://issues.apache.org/jira/browse/RANGER-3691
> Project: Ranger
>  Issue Type: Bug
>  Components: admin, kms
>Reporter: kirby zhou
>Assignee: kirby zhou
>Priority: Blocker
> Fix For: 3.0.0
>
>
> [https://tanzu.vmware.com/security/cve-2022-22965|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22965]
> [https://github.com/spring-projects/spring-framework/releases]
>  
> Spring has a new 0day Remote-Code-Execution problem, related to spring-beans 
> and JDK9+
> Fixed at spring 5.3.18 / 5.2.20
>  



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

[jira] [Assigned] (RANGER-3442) Ranger KMS DAO memory issues when many new keys are created

[Velmurugan Periasamy (Jira)]

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

Velmurugan Periasamy reassigned RANGER-3442:


Assignee: Pavi Subenderan

> Ranger KMS DAO memory issues when many new keys are created
> ---
>
> Key: RANGER-3442
> URL: https://issues.apache.org/jira/browse/RANGER-3442
> Project: Ranger
>  Issue Type: Bug
>  Components: kms
>Affects Versions: 2.0.0
>Reporter: Pavi Subenderan
>Assignee: Pavi Subenderan
>Priority: Major
> Attachments: RANGER-3442-entity-manager-clear.patch, kms-key.py
>
>
> We have many keys created in our KMS keystore and recently we found that when 
> we create new keys, the KMS instances easily hit against the memory limit. 
> We can reproduce this with a script to call KMS createKey and then 
> getMetadata for new keys in a loop. Basically we restart our instances and 
> memory usage is approximately 1.5GB out of 8GB, but after running this script 
> for a bit (1-5 minutes), we hit close to the 8GB limit and the memory usage 
> does not go back down after that.  
> I did a heap dump and saw that most of the memory was being retained by 
> XXRangerKeystore and eclipse EntityManagerImpl.  
>  * org.eclipse.persistence.internal.jpa.EntityManagerImpl
>  * org.eclipse.persistence.internal.sessions.RepeatableWriteUnitOfWork 
> And the largest shallow size object was char[] with 4GB+...
>  
> *My fix*
> I was ultimately able to solve this issue by adding an 
> getEntityManager().clear() call in BaseDao.java getAllKeys(). 
> After I added this fix, we can now run as many KMS CreateKey / getMetadata 
> calls as we want without any increase in memory usage whatsoever. Memory 
> usage now stays constant at <1.7GB.
> My understanding is that Ranger KMS has a many instances of ThreadLocal 
> EntityManager (160+ according to my heap dump) which each held a cache of the 
> results for getAllKeys. Since we have so many keys in our KMS, this would 
> easily put as at the memory limit. 
> Not sure if there are any drawbacks to clearing EntityManager in 
> BaseDao.getAllKeys() but we are seeing greatly improved performance in our 
> case since we aren't constantly hitting the memory limit anymore.



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

[jira] [Commented] (RANGER-3442) Ranger KMS DAO memory issues when many new keys are created

[Velmurugan Periasamy (Jira)]

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

Velmurugan Periasamy commented on RANGER-3442:
--

[~pavitheran] is added as contributor. Thanks. 

CC [~dhavalshah9131] / [~spolavarapu]

> Ranger KMS DAO memory issues when many new keys are created
> ---
>
> Key: RANGER-3442
> URL: https://issues.apache.org/jira/browse/RANGER-3442
> Project: Ranger
>  Issue Type: Bug
>  Components: kms
>Affects Versions: 2.0.0
>Reporter: Pavi Subenderan
>Assignee: Pavi Subenderan
>Priority: Major
> Attachments: RANGER-3442-entity-manager-clear.patch, kms-key.py
>
>
> We have many keys created in our KMS keystore and recently we found that when 
> we create new keys, the KMS instances easily hit against the memory limit. 
> We can reproduce this with a script to call KMS createKey and then 
> getMetadata for new keys in a loop. Basically we restart our instances and 
> memory usage is approximately 1.5GB out of 8GB, but after running this script 
> for a bit (1-5 minutes), we hit close to the 8GB limit and the memory usage 
> does not go back down after that.  
> I did a heap dump and saw that most of the memory was being retained by 
> XXRangerKeystore and eclipse EntityManagerImpl.  
>  * org.eclipse.persistence.internal.jpa.EntityManagerImpl
>  * org.eclipse.persistence.internal.sessions.RepeatableWriteUnitOfWork 
> And the largest shallow size object was char[] with 4GB+...
>  
> *My fix*
> I was ultimately able to solve this issue by adding an 
> getEntityManager().clear() call in BaseDao.java getAllKeys(). 
> After I added this fix, we can now run as many KMS CreateKey / getMetadata 
> calls as we want without any increase in memory usage whatsoever. Memory 
> usage now stays constant at <1.7GB.
> My understanding is that Ranger KMS has a many instances of ThreadLocal 
> EntityManager (160+ according to my heap dump) which each held a cache of the 
> results for getAllKeys. Since we have so many keys in our KMS, this would 
> easily put as at the memory limit. 
> Not sure if there are any drawbacks to clearing EntityManager in 
> BaseDao.getAllKeys() but we are seeing greatly improved performance in our 
> case since we aren't constantly hitting the memory limit anymore.



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

Re: Review Request 72024: RANGER-2704 : Support browser login using kerberized authentication.

[bhavik patel]

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




security-admin/src/main/java/org/apache/ranger/security/web/filter/RangerKrbFilter.java
Lines 126 (patched)


Initialisation is not required here.



security-admin/src/main/java/org/apache/ranger/security/web/filter/RangerSSOAuthenticationFilter.java
Lines 607 (patched)


same method is there in RangerKrbFilter class


- bhavik patel


On April 4, 2022, 1:04 p.m., Vishal Suvagia wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/72024/
> ---
> 
> (Updated April 4, 2022, 1:04 p.m.)
> 
> 
> Review request for ranger, Ankita Sinha, Dhaval Shah, Dineshkumar Yadav, 
> Gautam Borad, Jayendra Parab, Kishor Gollapalliwar, Abhay Kulkarni, Madhan 
> Neethiraj, Mehul Parikh, Pradeep Agrawal, Ramesh Mani, Sailaja Polavarapu, 
> and Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-2704
> https://issues.apache.org/jira/browse/RANGER-2704
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> Need to support browser login using kerberos authentication. Added a logout 
> for an unauthenticated user to redirect to the login page.
> 
> 
> Diffs
> -
> 
>   
> security-admin/src/main/java/org/apache/ranger/security/web/filter/RangerKrbFilter.java
>  223a991c76bae7d25f5ce89604d0a8a90d426fe5 
>   
> security-admin/src/main/java/org/apache/ranger/security/web/filter/RangerSSOAuthenticationFilter.java
>  abbf2d983beb30b59e5d3f6429d6fc226f735793 
>   security-admin/src/main/resources/conf.dist/ranger-admin-default-site.xml 
> 0a1128613dca50fe67ea3f891261f1ee449c46db 
> 
> 
> Diff: https://reviews.apache.org/r/72024/diff/2/
> 
> 
> Testing
> ---
> 
> Veriried kerberos ticket authentication is working on a kerberized browser.
> 
> 
> Steps to test for a kerberized browser:
> #1) For Kerberized browsers:
> #1> To open Chrome in kerberos enabled mode need to run below command:
>google-chrome --auth-server-whitelist="*ranger.testserver.com"
> #2> For Firefox, need to go to about:configs and then search for 
> negotiate and then add the host domain
> ranger.testserver.com to the property 
> "network.negotiate-auth.trusted-uris"
> #2) Perform kinit with the required user.
> #3) Open the Ranger Admin portal using FQDN of the server host.
> 
> 
> Known Issue: If there is no valid kerberos ticket, user lands on a blank page 
> and a short hack is to either append locallogin to the URL or refresh the 
> browser tab to redirect to the login page.
> P.S: this issue is not observed on Google Chrome browser
> 
> 
> File Attachments
> 
> 
> RANGER-2704.patch
>   
> https://reviews.apache.org/media/uploaded/files/2020/01/17/8c9682ca-1ade-4281-89e7-d43a8af09300__RANGER-2704.patch
> RANGER-2704.02.patch
>   
> https://reviews.apache.org/media/uploaded/files/2022/04/04/6e737bec-e640-4459-922c-353793172b12__RANGER-2704.02.patch
> 
> 
> Thanks,
> 
> Vishal Suvagia
> 
>

[jira] [Created] (RANGER-3695) Ranger Keystore alias should be configurable

[Vishal Suvagia (Jira)]

Vishal Suvagia created RANGER-3695:
--

 Summary: Ranger Keystore alias should be configurable
 Key: RANGER-3695
 URL: https://issues.apache.org/jira/browse/RANGER-3695
 Project: Ranger
  Issue Type: Improvement
  Components: admin
Affects Versions: 3.0.0
Reporter: Vishal Suvagia
Assignee: Vishal Suvagia


Ranger keystore alias is currently hard-coded, it should be configurable to 
allow user to provide a custom alias



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

Re: Review Request 72024: RANGER-2704 : Support browser login using kerberized authentication.

[Vishal Suvagia via Review Board]

> On March 1, 2022, 3:25 a.m., Kirby Zhou wrote:
> > What will happens at following situation?
> > 
> > 1. A kerberosized browser with unauthorized principal want to login to 
> > ranger by HTML form using another user/password.
> > 
> > 2. A kerberosized browser with different KDC want to login to ranger by by 
> > HTML form using another user/password.
> 
> Vishal Suvagia wrote:
> Hi Kirby Zhou,
> There is a flag to enable/disable kerberos based authentication for 
> Ranger UI, it is disabled by default. If the kerberos auth is enabled by 
> setting the flag and any user wants to use user/password credentials to login 
> to Ranger UI it can be done by appending the "/locallogin" to the Ranger URL.
> For e.g : If url for Ranger UI is http://abc.cluster.com:6080 then the 
> local-login url will be http://abc.cluster.com:6080/locallogin
>   using this url, user can get the login page and enter the 
> required user/password credentials.
> 
> Kirby Zhou wrote:
> I known that: If a browser without kerberos try to access 
> kerberos-enabled Ranger UI, it will be forwarded to 
> http://abc.cluster.com:6080/login.jsp
> 
> What I donot know is that: a kerbero-authenticated browser, but its 
> kerberos ticket is rejected by Ranger UI by many ways, what will happen.
> 
> Should I have to let my browser logout kerberos? Or I have to add 
> /locallogin by hand in address bar?

Q) A kerbero-authenticated browser, but its kerberos ticket is rejected by 
Ranger UI by many ways, what will happen.
A) If the ticket is invalid, user will be redirected to the Ranger Login page. 
If it does land on a blank page, user can perform a refresh to get the login 
page.


- Vishal


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


On April 4, 2022, 1:04 p.m., Vishal Suvagia wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/72024/
> ---
> 
> (Updated April 4, 2022, 1:04 p.m.)
> 
> 
> Review request for ranger, Ankita Sinha, Dhaval Shah, Dineshkumar Yadav, 
> Gautam Borad, Jayendra Parab, Kishor Gollapalliwar, Abhay Kulkarni, Madhan 
> Neethiraj, Mehul Parikh, Pradeep Agrawal, Ramesh Mani, Sailaja Polavarapu, 
> and Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-2704
> https://issues.apache.org/jira/browse/RANGER-2704
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> Need to support browser login using kerberos authentication. Added a logout 
> for an unauthenticated user to redirect to the login page.
> 
> 
> Diffs
> -
> 
>   
> security-admin/src/main/java/org/apache/ranger/security/web/filter/RangerKrbFilter.java
>  223a991c76bae7d25f5ce89604d0a8a90d426fe5 
>   
> security-admin/src/main/java/org/apache/ranger/security/web/filter/RangerSSOAuthenticationFilter.java
>  abbf2d983beb30b59e5d3f6429d6fc226f735793 
>   security-admin/src/main/resources/conf.dist/ranger-admin-default-site.xml 
> 0a1128613dca50fe67ea3f891261f1ee449c46db 
> 
> 
> Diff: https://reviews.apache.org/r/72024/diff/2/
> 
> 
> Testing
> ---
> 
> Veriried kerberos ticket authentication is working on a kerberized browser.
> 
> 
> Steps to test for a kerberized browser:
> #1) For Kerberized browsers:
> #1> To open Chrome in kerberos enabled mode need to run below command:
>google-chrome --auth-server-whitelist="*ranger.testserver.com"
> #2> For Firefox, need to go to about:configs and then search for 
> negotiate and then add the host domain
> ranger.testserver.com to the property 
> "network.negotiate-auth.trusted-uris"
> #2) Perform kinit with the required user.
> #3) Open the Ranger Admin portal using FQDN of the server host.
> 
> 
> Known Issue: If there is no valid kerberos ticket, user lands on a blank page 
> and a short hack is to either append locallogin to the URL or refresh the 
> browser tab to redirect to the login page.
> P.S: this issue is not observed on Google Chrome browser
> 
> 
> File Attachments
> 
> 
> RANGER-2704.patch
>   
> https://reviews.apache.org/media/uploaded/files/2020/01/17/8c9682ca-1ade-4281-89e7-d43a8af09300__RANGER-2704.patch
> RANGER-2704.02.patch
>   
> https://reviews.apache.org/media/uploaded/files/2022/04/04/6e737bec-e640-4459-922c-353793172b12__RANGER-2704.02.patch
> 
> 
> Thanks,
> 
> Vishal Suvagia
> 
>

Re: Review Request 72024: RANGER-2704 : Support browser login using kerberized authentication.

[Vishal Suvagia via Review Board]

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

(Updated April 4, 2022, 1:04 p.m.)


Review request for ranger, Ankita Sinha, Dhaval Shah, Dineshkumar Yadav, Gautam 
Borad, Jayendra Parab, Kishor Gollapalliwar, Abhay Kulkarni, Madhan Neethiraj, 
Mehul Parikh, Pradeep Agrawal, Ramesh Mani, Sailaja Polavarapu, and Velmurugan 
Periasamy.


Changes
---

Updated patch to remove unnecessary changes.


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


Repository: ranger


Description
---

Need to support browser login using kerberos authentication. Added a logout for 
an unauthenticated user to redirect to the login page.


Diffs
-

  
security-admin/src/main/java/org/apache/ranger/security/web/filter/RangerKrbFilter.java
 223a991c76bae7d25f5ce89604d0a8a90d426fe5 
  
security-admin/src/main/java/org/apache/ranger/security/web/filter/RangerSSOAuthenticationFilter.java
 abbf2d983beb30b59e5d3f6429d6fc226f735793 
  security-admin/src/main/resources/conf.dist/ranger-admin-default-site.xml 
0a1128613dca50fe67ea3f891261f1ee449c46db 


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


Testing (updated)
---

Veriried kerberos ticket authentication is working on a kerberized browser.


Steps to test for a kerberized browser:
#1) For Kerberized browsers:
#1> To open Chrome in kerberos enabled mode need to run below command:
   google-chrome --auth-server-whitelist="*ranger.testserver.com"
#2> For Firefox, need to go to about:configs and then search for negotiate 
and then add the host domain
ranger.testserver.com to the property 
"network.negotiate-auth.trusted-uris"
#2) Perform kinit with the required user.
#3) Open the Ranger Admin portal using FQDN of the server host.


Known Issue: If there is no valid kerberos ticket, user lands on a blank page 
and a short hack is to either append locallogin to the URL or refresh the 
browser tab to redirect to the login page.
P.S: this issue is not observed on Google Chrome browser


File Attachments (updated)


RANGER-2704.patch
  
https://reviews.apache.org/media/uploaded/files/2020/01/17/8c9682ca-1ade-4281-89e7-d43a8af09300__RANGER-2704.patch
RANGER-2704.02.patch
  
https://reviews.apache.org/media/uploaded/files/2022/04/04/6e737bec-e640-4459-922c-353793172b12__RANGER-2704.02.patch


Thanks,

Vishal Suvagia

[jira] [Updated] (RANGER-2704) Support browser login using kerberized authentication

[Vishal Suvagia (Jira)]

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

Vishal Suvagia updated RANGER-2704:
---
Attachment: RANGER-2704.02.patch

> Support browser login using kerberized authentication
> -
>
> Key: RANGER-2704
> URL: https://issues.apache.org/jira/browse/RANGER-2704
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Reporter: Vishal Suvagia
>Assignee: Vishal Suvagia
>Priority: Minor
> Attachments: RANGER-2704.01.patch, RANGER-2704.02.patch, 
> RANGER-2704.patch
>
>
> Need to support browser login using kerberos authentication.



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

[jira] [Created] (RANGER-3694) Cannot get script-engine from null pluginClassLoader

[alain pellegrino (Jira)]

alain pellegrino created RANGER-3694:


 Summary: Cannot get script-engine from null pluginClassLoader
 Key: RANGER-3694
 URL: https://issues.apache.org/jira/browse/RANGER-3694
 Project: Ranger
  Issue Type: Bug
  Components: plugins
Affects Versions: 3.0.0
Reporter: alain pellegrino


In the current vesion 3.0.0-SNAPSHOT of the kafka plugin, I have this couple of 
new errors, seems to be raised when downloading the policies from ranger-admin :

 
{code:java}
2022-03-31 13:17:14,058 WARN [PolicyRefresher(serviceName=CLUSTER_kafka)-66] 
org.apache.ranger.plugin.util.ScriptEngineUtil (ScriptEngineUtil.java:62) - 
failed to initialize script engine 'JavaScript' in a default manner. Will try 
to get script-engine from plugin-class-loader
2022-03-31 13:17:14,058 ERROR [PolicyRefresher(serviceName=CLUSTER_kafka)-66] 
org.apache.ranger.plugin.util.ScriptEngineUtil (ScriptEngineUtil.java:73) - 
Cannot get script-engine from null pluginClassLoader
2022-03-31 13:17:14,059 ERROR [PolicyRefresher(serviceName=CLUSTER_kafka)-66] 
org.apache.ranger.plugin.conditionevaluator.RangerScriptConditionEvaluator 
(RangerScriptConditionEvaluator.java:77) - failed to initialize condition 
'accessed-after-expiry': script engine 'JavaScript' was not created{code}
But when testing authorization it's working fine.

 



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

Re: Review Request 73928: RANGER-3693 : Upgrade tomcat to 8.5.78

[bhavik patel]

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


Ship it!




Ship It!

- bhavik patel


On April 4, 2022, 10:36 a.m., Mateen Mansoori wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/73928/
> ---
> 
> (Updated April 4, 2022, 10:36 a.m.)
> 
> 
> Review request for ranger, Kishor Gollapalliwar, Mehul Parikh, Pradeep 
> Agrawal, and Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-3693
> https://issues.apache.org/jira/browse/RANGER-3693
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> Currently ranger is pulling tomcat - 8.5.76, updated tomcat version to 8.5.78
> 
> 
> Diffs
> -
> 
>   pom.xml 20c101ff6 
> 
> 
> Diff: https://reviews.apache.org/r/73928/diff/1/
> 
> 
> Testing
> ---
> 
> Verified on local VM - Performed all necessary crud operations.
> 
> 
> Thanks,
> 
> Mateen Mansoori
> 
>

[jira] [Commented] (RANGER-3442) Ranger KMS DAO memory issues when many new keys are created

[Bhavik Patel (Jira)]

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

Bhavik Patel commented on RANGER-3442:
--

[~vel]  [~madhan]  [~rmani]  [~abhayk]  Please add [~pavitheran] as a 
contributor.

> Ranger KMS DAO memory issues when many new keys are created
> ---
>
> Key: RANGER-3442
> URL: https://issues.apache.org/jira/browse/RANGER-3442
> Project: Ranger
>  Issue Type: Bug
>  Components: kms
>Affects Versions: 2.0.0
>Reporter: Pavi Subenderan
>Priority: Major
> Attachments: RANGER-3442-entity-manager-clear.patch, kms-key.py
>
>
> We have many keys created in our KMS keystore and recently we found that when 
> we create new keys, the KMS instances easily hit against the memory limit. 
> We can reproduce this with a script to call KMS createKey and then 
> getMetadata for new keys in a loop. Basically we restart our instances and 
> memory usage is approximately 1.5GB out of 8GB, but after running this script 
> for a bit (1-5 minutes), we hit close to the 8GB limit and the memory usage 
> does not go back down after that.  
> I did a heap dump and saw that most of the memory was being retained by 
> XXRangerKeystore and eclipse EntityManagerImpl.  
>  * org.eclipse.persistence.internal.jpa.EntityManagerImpl
>  * org.eclipse.persistence.internal.sessions.RepeatableWriteUnitOfWork 
> And the largest shallow size object was char[] with 4GB+...
>  
> *My fix*
> I was ultimately able to solve this issue by adding an 
> getEntityManager().clear() call in BaseDao.java getAllKeys(). 
> After I added this fix, we can now run as many KMS CreateKey / getMetadata 
> calls as we want without any increase in memory usage whatsoever. Memory 
> usage now stays constant at <1.7GB.
> My understanding is that Ranger KMS has a many instances of ThreadLocal 
> EntityManager (160+ according to my heap dump) which each held a cache of the 
> results for getAllKeys. Since we have so many keys in our KMS, this would 
> easily put as at the memory limit. 
> Not sure if there are any drawbacks to clearing EntityManager in 
> BaseDao.getAllKeys() but we are seeing greatly improved performance in our 
> case since we aren't constantly hitting the memory limit anymore.



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

[jira] [Commented] (RANGER-3693) Ranger - Upgrade tomcat to 8.5.78

[Mateen N Mansoori (Jira)]

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

Mateen N Mansoori commented on RANGER-3693:
---

Review Board : https://reviews.apache.org/r/73928/

> Ranger - Upgrade tomcat to 8.5.78
> -
>
> Key: RANGER-3693
> URL: https://issues.apache.org/jira/browse/RANGER-3693
> Project: Ranger
>  Issue Type: Task
>  Components: Ranger
>Reporter: Mateen N Mansoori
>Priority: Major
>
> Currently ranger is pulling tomcat - 8.5.76, This task is to upgrade tomcat 
> version to 8.5.78.



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

Review Request 73928: RANGER-3693 : Upgrade tomcat to 8.5.78

[Mateen Mansoori]

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

Review request for ranger, Kishor Gollapalliwar, Mehul Parikh, Pradeep Agrawal, 
and Velmurugan Periasamy.


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


Repository: ranger


Description
---

Currently ranger is pulling tomcat - 8.5.76, updated tomcat version to 8.5.78


Diffs
-

  pom.xml 20c101ff6 


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


Testing
---

Verified on local VM - Performed all necessary crud operations.


Thanks,

Mateen Mansoori

[jira] [Created] (RANGER-3693) Ranger - Upgrade tomcat to 8.5.78

[Mateen N Mansoori (Jira)]

Mateen N Mansoori created RANGER-3693:
-

 Summary: Ranger - Upgrade tomcat to 8.5.78
 Key: RANGER-3693
 URL: https://issues.apache.org/jira/browse/RANGER-3693
 Project: Ranger
  Issue Type: Task
  Components: Ranger
Reporter: Mateen N Mansoori


Currently ranger is pulling tomcat - 8.5.76, This task is to upgrade tomcat 
version to 8.5.78.



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

Re: Review Request 73922: RANGER-3687: Password Policy Best Practices for Strong Security

[bhavik patel]

> On April 1, 2022, 9:22 a.m., Kirby Zhou wrote:
> > A question.
> > If admin want to change other user's password, The rule shoud be forced or 
> > not?
> > If not, how the code to impl it?
> 
> bhavik patel wrote:
> yes, that rule is forced.
> 
> Kirby Zhou wrote:
> I consider admin do not love it. Especially when admin needs to reset 
> someone's password to a specific value.

That’s also true, I thought og having the same functionality throughout the 
application.

@PMC any suggestions?


- bhavik


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


On April 1, 2022, 7:50 a.m., bhavik patel wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/73922/
> ---
> 
> (Updated April 1, 2022, 7:50 a.m.)
> 
> 
> Review request for ranger, Dhaval Shah, Dineshkumar Yadav, Kirby Zhou, Abhay 
> Kulkarni, Madhan Neethiraj, Mateen Mansoori, Mehul Parikh, Pradeep Agrawal, 
> Ramesh Mani, and Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-3687
> https://issues.apache.org/jira/browse/RANGER-3687
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> Password history should be configured to restrict users from reusing their 
> last 4 or 5 passwords.
> 
> 
> Diffs
> -
> 
>   security-admin/db/mysql/optimized/current/ranger_core_db_mysql.sql 
> 26282f770 
>   security-admin/db/mysql/patches/059-update-x-portal-user-table.sql 
> PRE-CREATION 
>   security-admin/src/main/java/org/apache/ranger/biz/UserMgr.java 0e61038d5 
>   security-admin/src/main/java/org/apache/ranger/entity/XXPortalUser.java 
> d0451b4d2 
>   security-admin/src/main/resources/conf.dist/ranger-admin-default-site.xml 
> e2bfc8fff 
> 
> 
> Diff: https://reviews.apache.org/r/73922/diff/2/
> 
> 
> Testing
> ---
> 
> 1. Verified the basic functionality of "/passwordchange" api
> 2. Verified "/secure/users" & "/secure/users/{id}" API’s
> 
> 3. Once the basic review/discussion is done will fix the Test-cases
> 
> 
> Thanks,
> 
> bhavik patel
> 
>

Re: Review Request 73869: RANGER-3389 : Swagger UI Support for Ranger REST API.

[Dhaval Rajpara]

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

(Updated April 4, 2022, 9 a.m.)


Review request for ranger, Dhaval Shah, Dineshkumar Yadav, Kishor 
Gollapalliwar, Abhay Kulkarni, Madhan Neethiraj, Mehul Parikh, Nitin Galave, 
Pradeep Agrawal, Sailaja Polavarapu, Steven Ramirez, and Velmurugan Periasamy.


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


Repository: ranger


Description
---

Create documentation for ranger REST API then display that documentation 
through swagger ui as part of ranger admin ui.


Diffs (updated)
-

  distro/src/main/assembly/admin-web.xml e19d50572 
  docs/src/site/resources/index.html PRE-CREATION 
  docs/src/site/resources/index.js PRE-CREATION 
  docs/src/site/resources/swagger-ui-bundle.js PRE-CREATION 
  docs/src/site/resources/swagger-ui-es-bundle-core.js PRE-CREATION 
  docs/src/site/resources/swagger-ui-es-bundle.js PRE-CREATION 
  docs/src/site/resources/swagger-ui-standalone-preset.js PRE-CREATION 
  docs/src/site/resources/swagger-ui.css PRE-CREATION 
  docs/src/site/resources/swagger-ui.js PRE-CREATION 
  enunciate.xml 13b465b55 
  pom.xml 252463227 
  security-admin/src/main/webapp/scripts/modules/RestCsrf.js 63561e3d1 
  security-admin/src/main/webapp/templates/common/ProfileBar_tmpl.html 
285d10617 


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

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


Testing
---

Updated Review request form https://reviews.apache.org/r/73566/
Fixed issue where swagger UI is not loading.
Fixed all review comment on patch.


Thanks,

Dhaval Rajpara

Re: Review Request 73922: RANGER-3687: Password Policy Best Practices for Strong Security

[bhavik patel]

> On April 1, 2022, 6:04 a.m., Kirby Zhou wrote:
> > security-admin/src/main/java/org/apache/ranger/biz/UserMgr.java
> > Line 1412 (original), 1424 (patched)
> > 
> >
> > It not works for FIPS.
> > FIPS require random salt, so we can not compare oldPassword and 
> > newPassword, encoded-oldPassword and encoded-newPassword directy,
> 
> bhavik patel wrote:
> That's true and That’s the main reason I pinged in the Jira to discuss 
> the approach.
> 
> Kirby Zhou wrote:
> You can simply call the old version function in a loop.

if we execute in the loop than also the result will be same unless we have the 
old salt value.


- bhavik


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


On April 1, 2022, 7:50 a.m., bhavik patel wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/73922/
> ---
> 
> (Updated April 1, 2022, 7:50 a.m.)
> 
> 
> Review request for ranger, Dhaval Shah, Dineshkumar Yadav, Kirby Zhou, Abhay 
> Kulkarni, Madhan Neethiraj, Mateen Mansoori, Mehul Parikh, Pradeep Agrawal, 
> Ramesh Mani, and Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-3687
> https://issues.apache.org/jira/browse/RANGER-3687
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> Password history should be configured to restrict users from reusing their 
> last 4 or 5 passwords.
> 
> 
> Diffs
> -
> 
>   security-admin/db/mysql/optimized/current/ranger_core_db_mysql.sql 
> 26282f770 
>   security-admin/db/mysql/patches/059-update-x-portal-user-table.sql 
> PRE-CREATION 
>   security-admin/src/main/java/org/apache/ranger/biz/UserMgr.java 0e61038d5 
>   security-admin/src/main/java/org/apache/ranger/entity/XXPortalUser.java 
> d0451b4d2 
>   security-admin/src/main/resources/conf.dist/ranger-admin-default-site.xml 
> e2bfc8fff 
> 
> 
> Diff: https://reviews.apache.org/r/73922/diff/2/
> 
> 
> Testing
> ---
> 
> 1. Verified the basic functionality of "/passwordchange" api
> 2. Verified "/secure/users" & "/secure/users/{id}" API’s
> 
> 3. Once the basic review/discussion is done will fix the Test-cases
> 
> 
> Thanks,
> 
> bhavik patel
> 
>

[jira] [Commented] (RANGER-3692) Ranger cannot connect to the DB when the DB is outaged for a long time

[Bhavik Patel (Jira)]

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

Bhavik Patel commented on RANGER-3692:
--

[~zilong zhu] Please check https://issues.apache.org/jira/browse/RANGER-2895

> Ranger cannot connect to the DB when the DB is outaged for a long time
> --
>
> Key: RANGER-3692
> URL: https://issues.apache.org/jira/browse/RANGER-3692
> Project: Ranger
>  Issue Type: Bug
>  Components: admin
>Affects Versions: 2.1.0
>Reporter: Zilong Zhu
>Assignee: Zilong Zhu
>Priority: Major
> Attachments: 
> 0001-RANGER-3692-Ranger-cannot-connect-to-the-DB-when-the.patch
>
>
> We had a database problem where the database was offline for more than a 
> week. However ranger connot connect to the DB.
> {code:java}
> Internal Exception: java.sql.SQLException: Connections could not be acquired 
> from the underlying database!
> [C3P0PooledConnectionPoolManager[identityToken->1hgf80qaljdycrokead8h|73c6299]-HelperThread-#0]
>  WARN  com.mchange.v2.log.slf4j.Slf4jMLog$Slf4jMLogger$WarnLogger 
> (Slf4jMLog.java:223) - 
> com.mchange.v2.resourcepool.BasicResourcePool$ScatteredAcquireTask@7179549 -- 
> Acquisition Attempt Failed!!! Clearing pending acquires. While trying to 
> acquire a needed new resource, we failed to succeed more than the maximum 
> number of allowed acquisition attempts (30). Last acquisition attempt 
> exception:
> com.mysql.cj.jdbc.exceptions.CommunicationsException: Communications link 
> failure
> [C3P0PooledConnectionPoolManager[identityToken->1hgf80qaljdycrokead8h|73c6299]-HelperThread-#0]
>  WARN  com.mchange.v2.log.slf4j.Slf4jMLog$Slf4jMLogger$WarnLogger 
> (Slf4jMLog.java:220) - Having failed to acquire a resource, 
> com.mchange.v2.resourcepool.BasicResourcePool@5efb2b9 is interrupting all 
> Threads waiting on a resource to check out. Will try again in response to new 
> client requests. {code}
> {code:java}
> Internal Exception: java.sql.SQLException: An SQLException was provoked by 
> the following failure: com.mchange.v2.resourcepool.ResourcePoolException: A 
> ResourcePool cannot acquire a new resource -- the factory or source appears 
> to be down.
> {code}
> I found out that this is a bug in c3p0 0.9.5.3. This bug was resolved in 
> 0.9.5.4. So I suggest to upgrade the version of c3p0 to 0.9.5.4. 
> [Force kill acquires by rscadrde · Pull Request #91 · swaldman/c3p0 · 
> GitHub|https://github.com/swaldman/c3p0/pull/91]



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

[jira] [Resolved] (RANGER-3691) Upgrade spring to 5.3.18 CVE-2022-22965

[Pradeep Agrawal (Jira)]

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

Pradeep Agrawal resolved RANGER-3691.
-
Fix Version/s: 3.0.0
 Assignee: kirby zhou
   Resolution: Fixed

Commit link : 
https://github.com/apache/ranger/commit/9ffa882f731a3d13c6d0bc0791b2363fb9289672

> Upgrade spring to 5.3.18 CVE-2022-22965
> ---
>
> Key: RANGER-3691
> URL: https://issues.apache.org/jira/browse/RANGER-3691
> Project: Ranger
>  Issue Type: Bug
>  Components: admin, kms
>Reporter: kirby zhou
>Assignee: kirby zhou
>Priority: Blocker
> Fix For: 3.0.0
>
>
> [https://tanzu.vmware.com/security/cve-2022-22965|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22965]
> [https://github.com/spring-projects/spring-framework/releases]
>  
> Spring has a new 0day Remote-Code-Execution problem, related to spring-beans 
> and JDK9+
> Fixed at spring 5.3.18 / 5.2.20
>  



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

Re: Review Request 73924: RANGER-3691: Upgrade spring to 5.3.18 for CVE-2022-22965

[Pradeep Agrawal]

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


Ship it!




Ship It!

- Pradeep Agrawal


On April 1, 2022, 9:54 a.m., Kirby Zhou wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/73924/
> ---
> 
> (Updated April 1, 2022, 9:54 a.m.)
> 
> 
> Review request for ranger and Bhavik Bavishi.
> 
> 
> Bugs: RANGER-3691
> https://issues.apache.org/jira/browse/RANGER-3691
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> Spring has a new 0day Remote-Code-Execution problem, related to spring-beans 
> and JDK9+
> Fixed at spring 5.3.18 / 5.2.20
> 
> 
> https://tanzu.vmware.com/security/cve-2022-22965
> https://github.com/spring-projects/spring-framework/releases
> 
> 
> Diffs
> -
> 
>   pom.xml 20c101ff6b561aac41399bf76efab4476079ab42 
> 
> 
> Diff: https://reviews.apache.org/r/73924/diff/1/
> 
> 
> Testing
> ---
> 
> quick tested under centos7
> 
> 
> Thanks,
> 
> Kirby Zhou
> 
>