[jira] [Commented] (RANGER-3243) Build fails on JDK 8 and 11

[Martin Tzvetanov Grigorov (Jira)]

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

Martin Tzvetanov Grigorov commented on RANGER-3243:
---

Thanks for merging it, [~rmani] !

Please also take a look at RANGER-3245: it updates .travisci.yml to test on JDK 
8 and 11, on both x86_64 and arm64! This will prevent regressions in the future!

> Build fails on JDK 8 and 11
> ---
>
> Key: RANGER-3243
> URL: https://issues.apache.org/jira/browse/RANGER-3243
> Project: Ranger
>  Issue Type: Task
>  Components: build-infra
>Affects Versions: 3.0.0, 2.2.0
>Reporter: Martin Tzvetanov Grigorov
>Priority: Major
> Fix For: 3.0.0, 2.2.0
>
> Attachments: 0001-RANGER-3243-Build-fails-on-JDK-8-and-11.patch
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> The build of current master branch fails - 
> [https://travis-ci.com/github/apache/ranger/builds/223139469]
> There are several issues:
> [Issue 1|https://reviews.apache.org/r/73281/bugs/1/]) 
> org.apache.ranger.authorization.presto.authorizer.RangerSystemAccessControlFactory
>  was not able to import com.google.common.base.Throwables.throwIfUnchecked 
> because it was coming from an old copy of Guava's Throwables shaded in 
> hive-exec.
> By replacing hive-exec with orc-core in agents-audit module all depending 
> modules use their preferred version of Guava (26.0-jre)
> [Issue 2|https://reviews.apache.org/r/73281/bugs/2/]) 
> RangerSafenetKeySecure.java uses directly sun.security.pkcs11.SunPKCS11 - a 
> class that is not available in Java 9+ and this breaks the compilation.
> This should use reflection to load SunPKCS11 class dynamically.
> [Issue 3|https://reviews.apache.org/r/73281/bugs/3/]) JAXB is no more part of 
> JDK 11+
> [Issue 4|https://reviews.apache.org/r/73281/bugs/4/]) JUnit 4 
> Assert.assertThat() is deprecated in favour of Hamcrest's 
> MatcherAssert.assertThat(). This fixes a compilation issue with JDK11.



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

[jira] [Updated] (RANGER-3031) Optimize authentication by cancelling setup when optimized for retrieval is false

[Selvamohan Neethiraj (Jira)]

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

Selvamohan Neethiraj updated RANGER-3031:
-
Fix Version/s: (was: 2.1.0)
   2.1.1

> Optimize authentication by cancelling setup when optimized for retrieval is 
> false
> -
>
> Key: RANGER-3031
> URL: https://issues.apache.org/jira/browse/RANGER-3031
> Project: Ranger
>  Issue Type: Improvement
>  Components: plugins
>Affects Versions: 2.0.0, 1.2.0, 2.1.0
>Reporter: JieMin
>Priority: Major
>  Labels: performance, pull-request-available
> Fix For: 2.1.1
>
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> when the optimized for retrieval is false , the process of setting up 
> wildcard policies will be postponed to authentication, which will slow down 
> the authentication.



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

[jira] [Updated] (RANGER-3217) Ranger's Atlas plugin throws unexpected errors

[Selvamohan Neethiraj (Jira)]

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

Selvamohan Neethiraj updated RANGER-3217:
-
Fix Version/s: (was: 2.1.0)
   2.1.1

> Ranger's Atlas plugin throws unexpected errors
> --
>
> Key: RANGER-3217
> URL: https://issues.apache.org/jira/browse/RANGER-3217
> Project: Ranger
>  Issue Type: Bug
>  Components: plugins
>Affects Versions: 2.1.0
>Reporter: Hisham Ismail
>Priority: Blocker
> Fix For: 2.1.1
>
>
> After deploying atlas with ranger plugin enabled, we receive the following 
> errors in the logs:
>  2021-03-22 08:10:26,633 ERROR - [main:] ~ 
> addResourceIfReadable(ranger-atlas-policymgr-ssl.xml): couldn't find resource 
> file location (RangerConfiguration:63)                                        
>                                                                      │
> │ 2021-03-22 08:10:26,643 ERROR - [main:] ~ 
> addResourceIfReadable(ranger-atlas-atlas-audit.xml): couldn't find resource 
> file location (RangerConfiguration:63)                                        
>                                                                        │
> │ 2021-03-22 08:10:26,644 ERROR - [main:] ~ 
> addResourceIfReadable(ranger-atlas-atlas-security.xml): couldn't find 
> resource file location (RangerConfiguration:63) 
>  
> In our install.properties file we used service_name = atlas and this error 
> changes on different values of service_name. On the ranger webui the plugin 
> is green with 200 and if i reinstall and use an invalid service name atlas 
> crashes. Therefore, i assume that the plugin is somehow working (I also 
> tested a simple feature) but i am not sure if these errors are causing harm 
> or making the plugin not fully functional. Can you please advise?
>  



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

[jira] [Updated] (RANGER-3111) Presto UI 8443 cannot be configured with permissions

[Selvamohan Neethiraj (Jira)]

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

Selvamohan Neethiraj updated RANGER-3111:
-
Fix Version/s: (was: 2.10)
   2.2.0

> Presto UI 8443 cannot be configured with permissions
> 
>
> Key: RANGER-3111
> URL: https://issues.apache.org/jira/browse/RANGER-3111
> Project: Ranger
>  Issue Type: Improvement
>  Components: plugins
>Affects Versions: 2.1.0
>Reporter: wangfei
>Priority: Major
> Fix For: 2.2.0
>
>
> When I configure the Presto plug-in, I can only view presto Web's query 
> details with my own account. What if I configure Presto Web to view details?



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

Re: Review Request 73605: RANGER-3438: In Knox plugin group lookup sometimes takes long time

[Sailaja Polavarapu]

> On Sept. 23, 2021, 9:29 p.m., Abhay Kulkarni wrote:
> > knox-agent/src/main/java/org/apache/ranger/authorization/knox/RangerPDPKnoxFilter.java
> > Line 124 (original), 126 (patched)
> > 
> >
> > Is it possible that primaryUser and/or impersonatedUser (therefore 
> > user) are all null? If so, is this error condition?

I don't think this is possible in the regular code flow as knox is supposedly 
set the PrimaryPrincipal in the Subject as part of authentication. Now we are 
actually more expicitly checking if (primaryPrincipals != null && 
primaryPrincipals.size() > 0)


- Sailaja


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


On Sept. 23, 2021, 9:15 p.m., Sailaja Polavarapu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/73605/
> ---
> 
> (Updated Sept. 23, 2021, 9:15 p.m.)
> 
> 
> Review request for ranger, Abhay Kulkarni, Mehul Parikh, Ramesh Mani, and 
> Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-3438
> https://issues.apache.org/jira/browse/RANGER-3438
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> Optimized code to extract GroupPrincipals from javax Subject and used similar 
> logic for retrieving primaryUser & impersonatedUser from Subject.
> 
> 
> Diffs
> -
> 
>   
> knox-agent/src/main/java/org/apache/ranger/authorization/knox/RangerPDPKnoxFilter.java
>  62363ab06 
> 
> 
> Diff: https://reviews.apache.org/r/73605/diff/1/
> 
> 
> Testing
> ---
> 
> 1. Patched cluster and verified functionality by accessing UI services like 
> ranger, atlas, etc... through knox proxy.
> 2. Also verified few regression tests both with group based policies and user 
> based policies for knox
> 
> 
> Thanks,
> 
> Sailaja Polavarapu
> 
>

Re: Review Request 73602: RANGER-3441: Refactoring logging of potentially sensitive data in PropertiesUtil

[Abhay Kulkarni]

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


Ship it!




Ship It!

- Abhay Kulkarni


On Sept. 23, 2021, 9:56 p.m., Abhishek  Kumar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/73602/
> ---
> 
> (Updated Sept. 23, 2021, 9:56 p.m.)
> 
> 
> Review request for ranger, Abhay Kulkarni, Madhan Neethiraj, Ramesh Mani, 
> Sailaja Polavarapu, and Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-3441
> https://issues.apache.org/jira/browse/RANGER-3441
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> Review aims to be more robust in avoiding sensitive data being written in 
> logs. 
> Verified that callers of PropertiesUtil are not logging any senstive data.
> 
> 
> Diffs
> -
> 
>   security-admin/src/main/java/org/apache/ranger/common/PropertiesUtil.java 
> 80a2d605f 
> 
> 
> Diff: https://reviews.apache.org/r/73602/diff/3/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Abhishek  Kumar
> 
>

Re: Review Request 73602: RANGER-3441: Refactoring logging of potentially sensitive data in PropertiesUtil

[Abhishek Kumar]

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

(Updated Sept. 23, 2021, 9:56 p.m.)


Review request for ranger, Abhay Kulkarni, Madhan Neethiraj, Ramesh Mani, 
Sailaja Polavarapu, and Velmurugan Periasamy.


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


Repository: ranger


Description
---

Review aims to be more robust in avoiding sensitive data being written in logs. 
Verified that callers of PropertiesUtil are not logging any senstive data.


Diffs (updated)
-

  security-admin/src/main/java/org/apache/ranger/common/PropertiesUtil.java 
80a2d605f 


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

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


Testing
---


Thanks,

Abhishek  Kumar

Re: Review Request 73602: RANGER-3441: Refactoring logging of potentially sensitive data in PropertiesUtil

[Abhishek Kumar]

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

(Updated Sept. 23, 2021, 9:42 p.m.)


Review request for ranger, Abhay Kulkarni, Madhan Neethiraj, Ramesh Mani, 
Sailaja Polavarapu, and Velmurugan Periasamy.


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


Repository: ranger


Description
---

Review aims to be more robust in avoiding sensitive data being written in logs. 
Verified that callers of PropertiesUtil are not logging any senstive data.


Diffs (updated)
-

  security-admin/src/main/java/org/apache/ranger/common/PropertiesUtil.java 
80a2d605f 


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

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


Testing
---


Thanks,

Abhishek  Kumar

Re: Review Request 73605: RANGER-3438: In Knox plugin group lookup sometimes takes long time

[Abhay Kulkarni]

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




knox-agent/src/main/java/org/apache/ranger/authorization/knox/RangerPDPKnoxFilter.java
Line 124 (original), 126 (patched)


Is it possible that primaryUser and/or impersonatedUser (therefore user) 
are all null? If so, is this error condition?


- Abhay Kulkarni


On Sept. 23, 2021, 9:15 p.m., Sailaja Polavarapu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/73605/
> ---
> 
> (Updated Sept. 23, 2021, 9:15 p.m.)
> 
> 
> Review request for ranger, Abhay Kulkarni, Mehul Parikh, Ramesh Mani, and 
> Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-3438
> https://issues.apache.org/jira/browse/RANGER-3438
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> Optimized code to extract GroupPrincipals from javax Subject and used similar 
> logic for retrieving primaryUser & impersonatedUser from Subject.
> 
> 
> Diffs
> -
> 
>   
> knox-agent/src/main/java/org/apache/ranger/authorization/knox/RangerPDPKnoxFilter.java
>  62363ab06 
> 
> 
> Diff: https://reviews.apache.org/r/73605/diff/1/
> 
> 
> Testing
> ---
> 
> 1. Patched cluster and verified functionality by accessing UI services like 
> ranger, atlas, etc... through knox proxy.
> 2. Also verified few regression tests both with group based policies and user 
> based policies for knox
> 
> 
> Thanks,
> 
> Sailaja Polavarapu
> 
>

[jira] [Updated] (RANGER-3438) In Knox plugin group lookup sometimes takes long time

[Sailaja Polavarapu (Jira)]

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

Sailaja Polavarapu updated RANGER-3438:
---
Attachment: 0001-RANGER-3438-Optimized-code-to-extract-GroupPrincipal.patch

> In Knox plugin group lookup sometimes takes long time
> -
>
> Key: RANGER-3438
> URL: https://issues.apache.org/jira/browse/RANGER-3438
> Project: Ranger
>  Issue Type: Improvement
>  Components: Ranger
>Reporter: Sailaja Polavarapu
>Assignee: Sailaja Polavarapu
>Priority: Major
> Attachments: 
> 0001-RANGER-3438-Optimized-code-to-extract-GroupPrincipal.patch
>
>
> When trusted proxy is enabled for various UI services, all the request go 
> through knox. plugin authorization. In some cases group lookup is taking long 
> time and the UI is very sluggish.



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

Review Request 73605: RANGER-3438: In Knox plugin group lookup sometimes takes long time

[Sailaja Polavarapu]

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

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


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


Repository: ranger


Description
---

Optimized code to extract GroupPrincipals from javax Subject and used similar 
logic for retrieving primaryUser & impersonatedUser from Subject.


Diffs
-

  
knox-agent/src/main/java/org/apache/ranger/authorization/knox/RangerPDPKnoxFilter.java
 62363ab06 


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


Testing
---

1. Patched cluster and verified functionality by accessing UI services like 
ranger, atlas, etc... through knox proxy.
2. Also verified few regression tests both with group based policies and user 
based policies for knox


Thanks,

Sailaja Polavarapu

[jira] [Commented] (RANGER-3243) Build fails on JDK 8 and 11

[Ramesh Mani (Jira)]

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

Ramesh Mani commented on RANGER-3243:
-

[~mgrigorov] This is committed into 2.20 and 3.0.0 branch. Thank you!

> Build fails on JDK 8 and 11
> ---
>
> Key: RANGER-3243
> URL: https://issues.apache.org/jira/browse/RANGER-3243
> Project: Ranger
>  Issue Type: Task
>  Components: build-infra
>Affects Versions: 3.0.0, 2.2.0
>Reporter: Martin Tzvetanov Grigorov
>Priority: Major
> Fix For: 3.0.0, 2.2.0
>
> Attachments: 0001-RANGER-3243-Build-fails-on-JDK-8-and-11.patch
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> The build of current master branch fails - 
> [https://travis-ci.com/github/apache/ranger/builds/223139469]
> There are several issues:
> [Issue 1|https://reviews.apache.org/r/73281/bugs/1/]) 
> org.apache.ranger.authorization.presto.authorizer.RangerSystemAccessControlFactory
>  was not able to import com.google.common.base.Throwables.throwIfUnchecked 
> because it was coming from an old copy of Guava's Throwables shaded in 
> hive-exec.
> By replacing hive-exec with orc-core in agents-audit module all depending 
> modules use their preferred version of Guava (26.0-jre)
> [Issue 2|https://reviews.apache.org/r/73281/bugs/2/]) 
> RangerSafenetKeySecure.java uses directly sun.security.pkcs11.SunPKCS11 - a 
> class that is not available in Java 9+ and this breaks the compilation.
> This should use reflection to load SunPKCS11 class dynamically.
> [Issue 3|https://reviews.apache.org/r/73281/bugs/3/]) JAXB is no more part of 
> JDK 11+
> [Issue 4|https://reviews.apache.org/r/73281/bugs/4/]) JUnit 4 
> Assert.assertThat() is deprecated in favour of Hamcrest's 
> MatcherAssert.assertThat(). This fixes a compilation issue with JDK11.



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

[jira] [Resolved] (RANGER-3243) Build fails on JDK 8 and 11

[Ramesh Mani (Jira)]

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

Ramesh Mani resolved RANGER-3243.
-
Resolution: Fixed

> Build fails on JDK 8 and 11
> ---
>
> Key: RANGER-3243
> URL: https://issues.apache.org/jira/browse/RANGER-3243
> Project: Ranger
>  Issue Type: Task
>  Components: build-infra
>Affects Versions: 3.0.0, 2.2.0
>Reporter: Martin Tzvetanov Grigorov
>Priority: Major
> Fix For: 3.0.0, 2.2.0
>
> Attachments: 0001-RANGER-3243-Build-fails-on-JDK-8-and-11.patch
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> The build of current master branch fails - 
> [https://travis-ci.com/github/apache/ranger/builds/223139469]
> There are several issues:
> [Issue 1|https://reviews.apache.org/r/73281/bugs/1/]) 
> org.apache.ranger.authorization.presto.authorizer.RangerSystemAccessControlFactory
>  was not able to import com.google.common.base.Throwables.throwIfUnchecked 
> because it was coming from an old copy of Guava's Throwables shaded in 
> hive-exec.
> By replacing hive-exec with orc-core in agents-audit module all depending 
> modules use their preferred version of Guava (26.0-jre)
> [Issue 2|https://reviews.apache.org/r/73281/bugs/2/]) 
> RangerSafenetKeySecure.java uses directly sun.security.pkcs11.SunPKCS11 - a 
> class that is not available in Java 9+ and this breaks the compilation.
> This should use reflection to load SunPKCS11 class dynamically.
> [Issue 3|https://reviews.apache.org/r/73281/bugs/3/]) JAXB is no more part of 
> JDK 11+
> [Issue 4|https://reviews.apache.org/r/73281/bugs/4/]) JUnit 4 
> Assert.assertThat() is deprecated in favour of Hamcrest's 
> MatcherAssert.assertThat(). This fixes a compilation issue with JDK11.



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

[jira] [Updated] (RANGER-3243) Build fails on JDK 8 and 11

[Ramesh Mani (Jira)]

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

Ramesh Mani updated RANGER-3243:

Attachment: 0001-RANGER-3243-Build-fails-on-JDK-8-and-11.patch

> Build fails on JDK 8 and 11
> ---
>
> Key: RANGER-3243
> URL: https://issues.apache.org/jira/browse/RANGER-3243
> Project: Ranger
>  Issue Type: Task
>  Components: build-infra
>Affects Versions: 3.0.0, 2.2.0
>Reporter: Martin Tzvetanov Grigorov
>Priority: Major
> Fix For: 3.0.0, 2.2.0
>
> Attachments: 0001-RANGER-3243-Build-fails-on-JDK-8-and-11.patch
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> The build of current master branch fails - 
> [https://travis-ci.com/github/apache/ranger/builds/223139469]
> There are several issues:
> [Issue 1|https://reviews.apache.org/r/73281/bugs/1/]) 
> org.apache.ranger.authorization.presto.authorizer.RangerSystemAccessControlFactory
>  was not able to import com.google.common.base.Throwables.throwIfUnchecked 
> because it was coming from an old copy of Guava's Throwables shaded in 
> hive-exec.
> By replacing hive-exec with orc-core in agents-audit module all depending 
> modules use their preferred version of Guava (26.0-jre)
> [Issue 2|https://reviews.apache.org/r/73281/bugs/2/]) 
> RangerSafenetKeySecure.java uses directly sun.security.pkcs11.SunPKCS11 - a 
> class that is not available in Java 9+ and this breaks the compilation.
> This should use reflection to load SunPKCS11 class dynamically.
> [Issue 3|https://reviews.apache.org/r/73281/bugs/3/]) JAXB is no more part of 
> JDK 11+
> [Issue 4|https://reviews.apache.org/r/73281/bugs/4/]) JUnit 4 
> Assert.assertThat() is deprecated in favour of Hamcrest's 
> MatcherAssert.assertThat(). This fixes a compilation issue with JDK11.



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

Re: Review Request 73604: RANGER-3444: fixed isAccessAllowed() return to reference the same request object given by the caller

[Abhay Kulkarni]

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


Ship it!




Ship It!

- Abhay Kulkarni


On Sept. 23, 2021, 4:40 p.m., Madhan Neethiraj wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/73604/
> ---
> 
> (Updated Sept. 23, 2021, 4:40 p.m.)
> 
> 
> Review request for ranger, Don Bosco Durai, Abhay Kulkarni, Mehul Parikh, 
> Pradeep Agrawal, Ramesh Mani, Selvamohan Neethiraj, Sailaja Polavarapu, and 
> Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-3444
> https://issues.apache.org/jira/browse/RANGER-3444
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> updated _any access-type processing to copy result from individual 
> access-type evaluation, instead of directly returning it
> 
> 
> Diffs
> -
> 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/policyengine/RangerPolicyEngineImpl.java
>  b6ab72c05 
> 
> 
> Diff: https://reviews.apache.org/r/73604/diff/1/
> 
> 
> Testing
> ---
> 
> verified that all unit tests pass successfully
> 
> 
> Thanks,
> 
> Madhan Neethiraj
> 
>

[jira] [Updated] (RANGER-3243) Build fails on JDK 8 and 11

[Ramesh Mani (Jira)]

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

Ramesh Mani updated RANGER-3243:

Fix Version/s: 2.2.0
   3.0.0

> Build fails on JDK 8 and 11
> ---
>
> Key: RANGER-3243
> URL: https://issues.apache.org/jira/browse/RANGER-3243
> Project: Ranger
>  Issue Type: Task
>  Components: build-infra
>Affects Versions: 3.0.0, 2.2.0
>Reporter: Martin Tzvetanov Grigorov
>Priority: Major
> Fix For: 3.0.0, 2.2.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> The build of current master branch fails - 
> [https://travis-ci.com/github/apache/ranger/builds/223139469]
> There are several issues:
> [Issue 1|https://reviews.apache.org/r/73281/bugs/1/]) 
> org.apache.ranger.authorization.presto.authorizer.RangerSystemAccessControlFactory
>  was not able to import com.google.common.base.Throwables.throwIfUnchecked 
> because it was coming from an old copy of Guava's Throwables shaded in 
> hive-exec.
> By replacing hive-exec with orc-core in agents-audit module all depending 
> modules use their preferred version of Guava (26.0-jre)
> [Issue 2|https://reviews.apache.org/r/73281/bugs/2/]) 
> RangerSafenetKeySecure.java uses directly sun.security.pkcs11.SunPKCS11 - a 
> class that is not available in Java 9+ and this breaks the compilation.
> This should use reflection to load SunPKCS11 class dynamically.
> [Issue 3|https://reviews.apache.org/r/73281/bugs/3/]) JAXB is no more part of 
> JDK 11+
> [Issue 4|https://reviews.apache.org/r/73281/bugs/4/]) JUnit 4 
> Assert.assertThat() is deprecated in favour of Hamcrest's 
> MatcherAssert.assertThat(). This fixes a compilation issue with JDK11.



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

[jira] [Updated] (RANGER-3243) Build fails on JDK 8 and 11

[Ramesh Mani (Jira)]

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

Ramesh Mani updated RANGER-3243:

Affects Version/s: 2.2.0
   3.0.0

> Build fails on JDK 8 and 11
> ---
>
> Key: RANGER-3243
> URL: https://issues.apache.org/jira/browse/RANGER-3243
> Project: Ranger
>  Issue Type: Task
>  Components: build-infra
>Affects Versions: 3.0.0, 2.2.0
>Reporter: Martin Tzvetanov Grigorov
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> The build of current master branch fails - 
> [https://travis-ci.com/github/apache/ranger/builds/223139469]
> There are several issues:
> [Issue 1|https://reviews.apache.org/r/73281/bugs/1/]) 
> org.apache.ranger.authorization.presto.authorizer.RangerSystemAccessControlFactory
>  was not able to import com.google.common.base.Throwables.throwIfUnchecked 
> because it was coming from an old copy of Guava's Throwables shaded in 
> hive-exec.
> By replacing hive-exec with orc-core in agents-audit module all depending 
> modules use their preferred version of Guava (26.0-jre)
> [Issue 2|https://reviews.apache.org/r/73281/bugs/2/]) 
> RangerSafenetKeySecure.java uses directly sun.security.pkcs11.SunPKCS11 - a 
> class that is not available in Java 9+ and this breaks the compilation.
> This should use reflection to load SunPKCS11 class dynamically.
> [Issue 3|https://reviews.apache.org/r/73281/bugs/3/]) JAXB is no more part of 
> JDK 11+
> [Issue 4|https://reviews.apache.org/r/73281/bugs/4/]) JUnit 4 
> Assert.assertThat() is deprecated in favour of Hamcrest's 
> MatcherAssert.assertThat(). This fixes a compilation issue with JDK11.



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

Re: Review Request 73281: Fix compilation problems for Java 8 and Java 11.

[Ramesh Mani]

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


Ship it!




Ship It!

- Ramesh Mani


On Sept. 21, 2021, 7:18 a.m., Martin Grigorov wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/73281/
> ---
> 
> (Updated Sept. 21, 2021, 7:18 a.m.)
> 
> 
> Review request for ranger.
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> Fix build due to hive exec and JDK 8 specific class
> 
> 
> Diffs
> -
> 
>   kms/src/main/java/org/apache/hadoop/crypto/key/RangerSafenetKeySecure.java 
> 371e367c1 
>   pom.xml 36036a6ad 
>   ugsync-util/pom.xml aa992cabf 
>   ugsync/pom.xml 07e0c5872 
>   
> ugsync/src/test/java/org/apache/ranger/unixusersync/process/TestUnixUserGroupBuilder.java
>  30820ce33 
> 
> 
> Diff: https://reviews.apache.org/r/73281/diff/4/
> 
> 
> Testing
> ---
> 
> Issue 1) 
> org.apache.ranger.authorization.presto.authorizer.RangerSystemAccessControlFactory
>  was not able to import com.google.common.base.Throwables.throwIfUnchecked 
> because it was coming from an old copy of Guava's Throwables shaded in 
> hive-exec.
> By replacing hive-exec with orc-core in agents-audit module all depending 
> modules use their preferred version of Guava (26.0-jre)
> 
> Issue 2) RangerSafenetKeySecure.java uses directly 
> sun.security.pkcs11.SunPKCS11 - a class that is not available in Java 9+ and 
> this breaks the compilation.
> This should use reflection to load SunPKCS11 class dynamically.
> 
> Issue 3) JAXB is no more part of JDK 11+
> 
> Issue 4) JUnit 4 Assert.assertThat() is deprecated in favour of Hamcrest's 
> MatcherAssert.assertThat(). This fixes a compilation issue with JDK11.
> 
> 
> Thanks,
> 
> Martin Grigorov
> 
>

[jira] [Updated] (RANGER-3444) request in the result returned from isAccessAllowed() is not same as the parameter

[Madhan Neethiraj (Jira)]

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

Madhan Neethiraj updated RANGER-3444:
-
Fix Version/s: 2.2.0

> request in the result returned from isAccessAllowed() is not same as the 
> parameter
> --
>
> Key: RANGER-3444
> URL: https://issues.apache.org/jira/browse/RANGER-3444
> Project: Ranger
>  Issue Type: Bug
>  Components: plugins
>Affects Versions: 2.2.0
>Reporter: Madhan Neethiraj
>Assignee: Madhan Neethiraj
>Priority: Major
> Fix For: 3.0.0, 2.2.0
>
> Attachments: RANGER-3444.patch
>
>
> RangerAccessResult includes the RangerAccessRequest object given by the 
> caller. However, while evaluating policies for _any access-type, the returned 
> result has a different request object - created internally by the policy 
> engine. This is a regression from the enhancements in RANGER-3329. This 
> should be fixed to retain the earlier behavior.



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

[jira] [Updated] (RANGER-3444) request in the result returned from isAccessAllowed() is not same as the parameter

[Madhan Neethiraj (Jira)]

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

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

> request in the result returned from isAccessAllowed() is not same as the 
> parameter
> --
>
> Key: RANGER-3444
> URL: https://issues.apache.org/jira/browse/RANGER-3444
> Project: Ranger
>  Issue Type: Bug
>  Components: plugins
>Affects Versions: 2.2.0
>Reporter: Madhan Neethiraj
>Assignee: Madhan Neethiraj
>Priority: Major
> Attachments: RANGER-3444.patch
>
>
> RangerAccessResult includes the RangerAccessRequest object given by the 
> caller. However, while evaluating policies for _any access-type, the returned 
> result has a different request object - created internally by the policy 
> engine. This is a regression from the enhancements in RANGER-3329. This 
> should be fixed to retain the earlier behavior.



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

Review Request 73604: RANGER-3444: fixed isAccessAllowed() return to reference the same request object given by the caller

[Madhan Neethiraj]

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

Review request for ranger, Don Bosco Durai, Abhay Kulkarni, Mehul Parikh, 
Pradeep Agrawal, Ramesh Mani, Selvamohan Neethiraj, Sailaja Polavarapu, and 
Velmurugan Periasamy.


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


Repository: ranger


Description
---

updated _any access-type processing to copy result from individual access-type 
evaluation, instead of directly returning it


Diffs
-

  
agents-common/src/main/java/org/apache/ranger/plugin/policyengine/RangerPolicyEngineImpl.java
 b6ab72c05 


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


Testing
---

verified that all unit tests pass successfully


Thanks,

Madhan Neethiraj

[jira] [Created] (RANGER-3444) request in the result returned from isAccessAllowed() is not same as the parameter

[Madhan Neethiraj (Jira)]

Madhan Neethiraj created RANGER-3444:


 Summary: request in the result returned from isAccessAllowed() is 
not same as the parameter
 Key: RANGER-3444
 URL: https://issues.apache.org/jira/browse/RANGER-3444
 Project: Ranger
  Issue Type: Bug
  Components: plugins
Affects Versions: 2.2.0
Reporter: Madhan Neethiraj
Assignee: Madhan Neethiraj


RangerAccessResult includes the RangerAccessRequest object given by the caller. 
However, while evaluating policies for _any access-type, the returned result 
has a different request object - created internally by the policy engine. This 
is a regression from the enhancements in RANGER-3329. This should be fixed to 
retain the earlier behavior.



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

Re: Review Request 73281: Fix compilation problems for Java 8 and Java 11.

[Martin Grigorov]

> On Sept. 23, 2021, 10:11 a.m., Dhaval Shah wrote:
> > Build succeeded with patch on java 8 and java 11.

Thanks for the review, Dhaval Shah!


- Martin


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


On Sept. 21, 2021, 7:18 a.m., Martin Grigorov wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/73281/
> ---
> 
> (Updated Sept. 21, 2021, 7:18 a.m.)
> 
> 
> Review request for ranger.
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> Fix build due to hive exec and JDK 8 specific class
> 
> 
> Diffs
> -
> 
>   kms/src/main/java/org/apache/hadoop/crypto/key/RangerSafenetKeySecure.java 
> 371e367c1 
>   pom.xml 36036a6ad 
>   ugsync-util/pom.xml aa992cabf 
>   ugsync/pom.xml 07e0c5872 
>   
> ugsync/src/test/java/org/apache/ranger/unixusersync/process/TestUnixUserGroupBuilder.java
>  30820ce33 
> 
> 
> Diff: https://reviews.apache.org/r/73281/diff/4/
> 
> 
> Testing
> ---
> 
> Issue 1) 
> org.apache.ranger.authorization.presto.authorizer.RangerSystemAccessControlFactory
>  was not able to import com.google.common.base.Throwables.throwIfUnchecked 
> because it was coming from an old copy of Guava's Throwables shaded in 
> hive-exec.
> By replacing hive-exec with orc-core in agents-audit module all depending 
> modules use their preferred version of Guava (26.0-jre)
> 
> Issue 2) RangerSafenetKeySecure.java uses directly 
> sun.security.pkcs11.SunPKCS11 - a class that is not available in Java 9+ and 
> this breaks the compilation.
> This should use reflection to load SunPKCS11 class dynamically.
> 
> Issue 3) JAXB is no more part of JDK 11+
> 
> Issue 4) JUnit 4 Assert.assertThat() is deprecated in favour of Hamcrest's 
> MatcherAssert.assertThat(). This fixes a compilation issue with JDK11.
> 
> 
> Thanks,
> 
> Martin Grigorov
> 
>

Re: Review Request 73281: Fix compilation problems for Java 8 and Java 11.

[Dhaval Shah]

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


Ship it!




Build succeeded with patch on java 8 and java 11.

- Dhaval Shah


On Sept. 21, 2021, 7:18 a.m., Martin Grigorov wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/73281/
> ---
> 
> (Updated Sept. 21, 2021, 7:18 a.m.)
> 
> 
> Review request for ranger.
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> Fix build due to hive exec and JDK 8 specific class
> 
> 
> Diffs
> -
> 
>   kms/src/main/java/org/apache/hadoop/crypto/key/RangerSafenetKeySecure.java 
> 371e367c1 
>   pom.xml 36036a6ad 
>   ugsync-util/pom.xml aa992cabf 
>   ugsync/pom.xml 07e0c5872 
>   
> ugsync/src/test/java/org/apache/ranger/unixusersync/process/TestUnixUserGroupBuilder.java
>  30820ce33 
> 
> 
> Diff: https://reviews.apache.org/r/73281/diff/4/
> 
> 
> Testing
> ---
> 
> Issue 1) 
> org.apache.ranger.authorization.presto.authorizer.RangerSystemAccessControlFactory
>  was not able to import com.google.common.base.Throwables.throwIfUnchecked 
> because it was coming from an old copy of Guava's Throwables shaded in 
> hive-exec.
> By replacing hive-exec with orc-core in agents-audit module all depending 
> modules use their preferred version of Guava (26.0-jre)
> 
> Issue 2) RangerSafenetKeySecure.java uses directly 
> sun.security.pkcs11.SunPKCS11 - a class that is not available in Java 9+ and 
> this breaks the compilation.
> This should use reflection to load SunPKCS11 class dynamically.
> 
> Issue 3) JAXB is no more part of JDK 11+
> 
> Issue 4) JUnit 4 Assert.assertThat() is deprecated in favour of Hamcrest's 
> MatcherAssert.assertThat(). This fixes a compilation issue with JDK11.
> 
> 
> Thanks,
> 
> Martin Grigorov
> 
>

Re: Review Request 73601: RANGER-3439: REST api to get or delete ranger policy based on guid and service name

[Pradeep Agrawal]

> On Sept. 22, 2021, 3:29 p.m., Madhan Neethiraj wrote:
> > security-admin/src/main/java/org/apache/ranger/biz/ServiceDBStore.java
> > Lines 2301 (patched)
> > 
> >
> > Can there be multiple policies for a given guid? If yes, a policy can 
> > be identified/retrieved only with its guid; serviceName is not necessary 
> > here. Please review.

Yes, there is a case with that more than one policy can exist with same guid. 

**Use Case:** Currently Ranger-admin allows user's to export ranger policies 
from one ranger service and import into another ranger service. If same 
ranger-admin instance is used for source/export and target/import then policy 
exported from one service can be imported into the another service. In this 
import process ranger keeps the same guid which was provided as input(received 
from export output). 
Currently there is no uniqueness restriction on the guid column of x_policy 
table and at the server side also there are no such restrictions so duplicate 
guid may exist in x_policy table as per this use case. There is possibility 
that user might have tried this use case and might be having duplicate guid 
entries.
However, Within the same service duplicate guid chances are not there so using 
RANGER-3435 patch we can create uniqueness restriction.

Please let me know if above analysis is correct and advice if this can be 
handled some others ways.


- Pradeep


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


On Sept. 22, 2021, 11:03 a.m., Pradeep Agrawal wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/73601/
> ---
> 
> (Updated Sept. 22, 2021, 11:03 a.m.)
> 
> 
> Review request for ranger, Dineshkumar Yadav, Abhay Kulkarni, Madhan 
> Neethiraj, Mehul Parikh, Ramesh Mani, Sailaja Polavarapu, and Velmurugan 
> Periasamy.
> 
> 
> Bugs: RANGER-3439
> https://issues.apache.org/jira/browse/RANGER-3439
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> **Problem Statmeent: **  This is required after the analysys of RANGER-3401, 
> as there could be request on x_policy table to find a policy by guid and 
> service id. There is no workaround to this problem however its recommended 
> that similar option should be provided through a REST url.
> 
> 
> **Proposed solution:** A New API can be introduced which shall accept the 
> guid and service name as request parameter input and either provide the 
> respective policy or delete the same.
> API:
> a) getPolicyByGUIDAndServiceName(guid, service): reads the input values and 
> returns the policy object.
> b) deletePolicyByGUIDAndServiceName(guid, service) : reads the input values 
> and deletes the respective policy object.
> 
> 
> Diffs
> -
> 
>   security-admin/src/main/java/org/apache/ranger/biz/ServiceDBStore.java 
> 3cd289cc2 
>   security-admin/src/main/java/org/apache/ranger/db/XXPolicyDao.java 
> 865926706 
>   security-admin/src/main/java/org/apache/ranger/rest/ServiceREST.java 
> f1123d19c 
>   security-admin/src/main/resources/META-INF/jpa_named_queries.xml 8eff33643 
> 
> 
> Diff: https://reviews.apache.org/r/73601/diff/1/
> 
> 
> Testing
> ---
> 
> Tested getPolicyByGUIDAndServiceName() API and was able to recieve the 
> matching policy object.
> Tested deletePolicyByGUIDAndServiceName() API and was able to delete the 
> respective policy object.
> 
> 
> Thanks,
> 
> Pradeep Agrawal
> 
>

[jira] [Created] (RANGER-3443) "X-Permitted-Cross-Domain-Policies" header not set by Ranger UI

[Nitin Galave (Jira)]

Nitin Galave created RANGER-3443:


 Summary: "X-Permitted-Cross-Domain-Policies" header not set by 
Ranger UI
 Key: RANGER-3443
 URL: https://issues.apache.org/jira/browse/RANGER-3443
 Project: Ranger
  Issue Type: Improvement
  Components: Ranger
Reporter: Nitin Galave
Assignee: Nitin Galave


Ranger does not return "X-Permitted-Cross-Domain-Policies" response header. 
OWASP best practices suggest explicitly setting this header to "none":
{code:java}
X-Permitted-Cross-Domain-Policies: none{code}



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

[jira] [Assigned] (RANGER-3417) Publish Apache Ranger release 2.2.0 artifacts

[Ramesh Mani (Jira)]

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

Ramesh Mani reassigned RANGER-3417:
---

Assignee: Ramesh Mani

> Publish Apache Ranger release 2.2.0 artifacts
> -
>
> Key: RANGER-3417
> URL: https://issues.apache.org/jira/browse/RANGER-3417
> Project: Ranger
>  Issue Type: Sub-task
>  Components: Ranger
>Affects Versions: 2.2.0
>Reporter: Ramesh Mani
>Assignee: Ramesh Mani
>Priority: Major
>
> Publish Apache Ranger release 2.2.0 artifacts



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

[jira] [Assigned] (RANGER-3415) Change pom version from 2.2.0-SNAPSHOT to 2.2.0

[Ramesh Mani (Jira)]

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

Ramesh Mani reassigned RANGER-3415:
---

Assignee: Ramesh Mani

> Change pom version from 2.2.0-SNAPSHOT to 2.2.0
> ---
>
> Key: RANGER-3415
> URL: https://issues.apache.org/jira/browse/RANGER-3415
> Project: Ranger
>  Issue Type: Sub-task
>  Components: Ranger
>Affects Versions: 2.2.0
>Reporter: Ramesh Mani
>Assignee: Ramesh Mani
>Priority: Major
>
> Change pom version from 2.2.0-SNAPSHOT to 2.2.0



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