Re: Review Request 62662: Fix invalid code and error logic for the BaseDao class

2017-09-28 Thread pengjianhua 


> On 九月 28, 2017, 6:31 p.m., Alejandro Fernandez wrote:
> > Any testing done on this?

Yes. I tested this issue. Thanks!


- pengjianhua


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


On 九月 28, 2017, 12:38 p.m., pengjianhua wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/62662/
> ---
> 
> (Updated 九月 28, 2017, 12:38 p.m.)
> 
> 
> Review request for ranger, Alok Lal, Ankita Sinha, Don Bosco Durai, Colm O 
> hEigeartaigh, Gautam Borad, Madhan Neethiraj, Ramesh Mani, Selvamohan 
> Neethiraj, Velmurugan Periasamy, and Qiang Zhang.
> 
> 
> Bugs: RANGER-1815
> https://issues.apache.org/jira/browse/RANGER-1815
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> Fix invalid code and error logic for the BaseDao class
> 
> 
> Diffs
> -
> 
>   agents-audit/src/main/java/org/apache/ranger/audit/dao/BaseDao.java 
> 75593d2f 
> 
> 
> Diff: https://reviews.apache.org/r/62662/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> pengjianhua
> 
>

Re: Review Request 62657: The drop-down box name "database" is not showing full when edit hive policy

2017-09-28 Thread Alejandro Fernandez 

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


Ship it!




Ship It!

- Alejandro Fernandez


On Sept. 28, 2017, 11:50 a.m., Qiang Zhang wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/62657/
> ---
> 
> (Updated Sept. 28, 2017, 11:50 a.m.)
> 
> 
> Review request for ranger, Alok Lal, Ankita Sinha, Don Bosco Durai, Colm O 
> hEigeartaigh, Gautam Borad, Madhan Neethiraj, pengjianhua, Ramesh Mani, 
> Selvamohan Neethiraj, and Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-1813
> https://issues.apache.org/jira/browse/RANGER-1813
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> The drop-down box name "database" is not showing full when edit hive policy.
> Please see picture (database.PNG)
> 
> 
> Diffs
> -
> 
>   security-admin/src/main/webapp/styles/xa.css 9751d90b 
> 
> 
> Diff: https://reviews.apache.org/r/62657/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Qiang Zhang
> 
>

Re: Review Request 62657: The drop-down box name "database" is not showing full when edit hive policy

2017-09-28 Thread Alejandro Fernandez 

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



Which browsers was this tested on?

- Alejandro Fernandez


On Sept. 28, 2017, 11:50 a.m., Qiang Zhang wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/62657/
> ---
> 
> (Updated Sept. 28, 2017, 11:50 a.m.)
> 
> 
> Review request for ranger, Alok Lal, Ankita Sinha, Don Bosco Durai, Colm O 
> hEigeartaigh, Gautam Borad, Madhan Neethiraj, pengjianhua, Ramesh Mani, 
> Selvamohan Neethiraj, and Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-1813
> https://issues.apache.org/jira/browse/RANGER-1813
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> The drop-down box name "database" is not showing full when edit hive policy.
> Please see picture (database.PNG)
> 
> 
> Diffs
> -
> 
>   security-admin/src/main/webapp/styles/xa.css 9751d90b 
> 
> 
> Diff: https://reviews.apache.org/r/62657/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Qiang Zhang
> 
>

Re: Review Request 62662: Fix invalid code and error logic for the BaseDao class

2017-09-28 Thread Alejandro Fernandez 

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



Any testing done on this?

- Alejandro Fernandez


On Sept. 28, 2017, 12:38 p.m., pengjianhua wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/62662/
> ---
> 
> (Updated Sept. 28, 2017, 12:38 p.m.)
> 
> 
> Review request for ranger, Alok Lal, Ankita Sinha, Don Bosco Durai, Colm O 
> hEigeartaigh, Gautam Borad, Madhan Neethiraj, Ramesh Mani, Selvamohan 
> Neethiraj, Velmurugan Periasamy, and Qiang Zhang.
> 
> 
> Bugs: RANGER-1815
> https://issues.apache.org/jira/browse/RANGER-1815
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> Fix invalid code and error logic for the BaseDao class
> 
> 
> Diffs
> -
> 
>   agents-audit/src/main/java/org/apache/ranger/audit/dao/BaseDao.java 
> 75593d2f 
> 
> 
> Diff: https://reviews.apache.org/r/62662/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> pengjianhua
> 
>

Re: Review Request 62659: RANGER-1814 : Move the reader into a local variable in LocalFileLogBuffer

2017-09-28 Thread Alejandro Fernandez 

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


Ship it!




Ship It!

- Alejandro Fernandez


On Sept. 28, 2017, 11:27 a.m., Zsombor Gegesy wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/62659/
> ---
> 
> (Updated Sept. 28, 2017, 11:27 a.m.)
> 
> 
> Review request for ranger.
> 
> 
> Bugs: RANGER-1814
> https://issues.apache.org/jira/browse/RANGER-1814
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> Static code analyser flagged sendCurrentFile in LogFileLogBuffer as dubious 
> BufferedReader usage - because it's not clear if that reader is closed 
> properly. Suggested to move from instance variable to method local variable
> 
> 
> Diffs
> -
> 
>   
> agents-audit/src/main/java/org/apache/ranger/audit/provider/LocalFileLogBuffer.java
>  56a24ed 
> 
> 
> Diff: https://reviews.apache.org/r/62659/diff/1/
> 
> 
> Testing
> ---
> 
> Tested locally, travis build: 
> https://travis-ci.org/gzsombor/ranger/builds/280822647
> 
> 
> Thanks,
> 
> Zsombor Gegesy
> 
>

Re: FW: New Defects reported by Coverity Scan for Apache Ranger

2017-09-28 Thread Fatima Khan 
Hi Abhay,
 I will look into it.


On 28-Sep-2017 8:48 pm, "Abhay Kulkarni"  wrote:

Contributors/Committers,

Please review and fix as appropriate.

Thanks!
-Abhay

On 9/28/17, 12:43 AM, "scan-ad...@coverity.com" 
wrote:

>
>Hi,
>
>Please find the latest report on new defect(s) introduced to Apache
>Ranger found with Coverity Scan.
>
>1 new defect(s) introduced to Apache Ranger found with Coverity Scan.
>6 defect(s), reported by Coverity Scan earlier, were marked fixed in the
>recent build analyzed by Coverity Scan.
>
>New defect(s) Reported-by: Coverity Scan
>Showing 1 of 1 defect(s)
>
>
>** CID 95505:(FORWARD_NULL)
>/security-admin/src/main/java/org/apache/ranger/biz/XUserMgr.java: 391 in
>org.apache.ranger.biz.XUserMgr.updateXUser(org.apache.ranger.view.VXUser)(
>)
>/security-admin/src/main/java/org/apache/ranger/biz/XUserMgr.java: 450 in
>org.apache.ranger.biz.XUserMgr.updateXUser(org.apache.ranger.view.VXUser)(
>)
>
>
>__
>__
>*** CID 95505:(FORWARD_NULL)
>/security-admin/src/main/java/org/apache/ranger/biz/XUserMgr.java: 391 in
>org.apache.ranger.biz.XUserMgr.updateXUser(org.apache.ranger.view.VXUser)(
>)
>385if (oldUserProfile != null && password != null
>386&& 
>password.equals(hiddenPasswordString))
{
>387vXPortalUser.setPassword(
oldUserProfile.getPassword());
>388}
>389 else if(password != null){
>390 validatePassword(vXUser);
 CID 95505:(FORWARD_NULL)
 Calling a method on null object "oldUserProfile".
>391 if (oldUserProfile.getUserSource() ==
>RangerCommonEnums.USER_EXTERNAL) {
>392
>vXPortalUser.setPassword(oldUserProfile.getPassword());
>393 }
>394 else if(oldUserProfile.getUserSource() ==
>RangerCommonEnums.USER_APP)
>395 {
>396vXPortalUser.setPassword(password);
>/security-admin/src/main/java/org/apache/ranger/biz/XUserMgr.java: 450 in
>org.apache.ranger.biz.XUserMgr.updateXUser(org.apache.ranger.view.VXUser)(
>)
>444}
>445
>446// TODO I've to get the transaction log from here.
>447// There is nothing to log anything in XXUser so
far.
>448vXUser = xUserService.updateResource(vXUser);
>449vXUser.setUserRoleList(roleList);
 CID 95505:(FORWARD_NULL)
 Calling a method on null object "oldUserProfile".
>450 if (oldUserProfile.getUserSource() ==
>RangerCommonEnums.USER_APP) {
>451vXUser.setPassword(password);
>452 }
>453 else if (oldUserProfile.getUserSource() ==
>RangerCommonEnums.USER_EXTERNAL) {
>454 vXUser.setPassword(oldUserProfile.getPassword());
>455 }
>
>
>__
>__
>To view the defects in Coverity Scan visit,
>https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V
>05UPxvVjWch-2Bd2MGckcRZSbhom32dlDl11LWEm9nX11zsOWMf5dv3Q9Mogo-2FGua3FsLRTF
>ft2V-2FOFC9o0P2e0-3D_eYGgfjRVvnymu7-2Fg39LOcg-2Fwh01uR5A1l1-2BVcR3oH7qLxXG
>asFbgN1kDBPIpGYM3rLSYzmeG-2BYa7G8XDIAVjfLvpuAxZDAekPb7Ge-2BSV0V3UOxGH6fq7t
>e-2FBz9K3J-2BgMSVG-2FL-2B3b8wmTbrE5RlAh1Wx7Yj2PrpxopzDpFQBM6X-2BEGeMejc-2B
>gFYqieFfxz45obau1ECnoL6Zgv3JRtmS4o-2FC5Jl5P5hM89piOfkcF6zo-3D
>
>To manage Coverity Scan email notifications for
>"akulka...@hortonworks.com", click
>https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V
>05UPxvVjWch-2Bd2MGckcRbVDbis712qZDP-2FA8y06Nq4rq896qxTW4IjcOjjCxcjhdwy7bkx
>0GaYF4jcZRTENcC8UedPeL4l2t0VBzV197ihjH14Ve5jAkEZTKufdAcDuKGDIx74O-2BWzK0Pb
>pXpwQLY-3D_eYGgfjRVvnymu7-2Fg39LOcg-2Fwh01uR5A1l1-2BVcR3oH7qLxXGasFbgN1kDB
>PIpGYM3rLSYzmeG-2BYa7G8XDIAVjfHlwaVB9Raguih-2FwkcLjJA0mCtUkkDoj8F4HwxV4ZpC
>D-2FQeY7ix0A8aSjSvg-2FysIlBGXiCWYBVwryh4hjK562Q20-2BIvhXOzSXbKxEVV5aZLnfzJ
>KG64wXkL21sShFYAI7NY6s7J5F6xWpOzCARUum7g-3D
>

[jira] [Commented] (RANGER-1796) Updated masking policy for hive to support for deny/allowException/denyExceptions

2017-09-28 Thread Madhan Neethiraj (JIRA) 

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

Madhan Neethiraj commented on RANGER-1796:
--

[~peng.jianhua] - I think the following approach will be a simpler and 
intuitive way to address your use case:
 - add a policy-item for user=USER1 with desired masking for this user
 - add a policy-item for group={GROUPA, GROUPB}, with maskType set to 'No Mask'
 - add a policy-item for group=public, with desired masking for every one else

I think specifying masking in terms of deny and exceptions is very difficult to 
understand and use. Can you review and try the above approach and let me know 
if this doesn't work or if this is not easy to understand.

> Updated masking policy for hive  to support for 
> deny/allowException/denyExceptions
> --
>
> Key: RANGER-1796
> URL: https://issues.apache.org/jira/browse/RANGER-1796
> Project: Ranger
>  Issue Type: New Feature
>  Components: plugins
>Affects Versions: 1.0.0, master
>Reporter: peng.jianhua
>Assignee: peng.jianhua
>  Labels: newbie, patch
> Attachments: 
> 0001-RANGER-1796-Updated-masking-policy-for-hive-to-suppo.patch, 
> masking-03.png, masking2.png, usecase-01.png, usecase-02.png
>
>
> Masking policy for hive  should support for 
> deny/allowException/denyExceptions to meet further business needs. Such as 
> masking policy for hive should support as following scene and so on:
> USER1, USER2 and USER3 belong to the user group GROUPA. Select GROUPA group 
> when created masking policy. The USER1 does not use masking and USER2, USER3 
> need masking.
> We rigorously tested this issue. The test result shows that the feature is ok.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

FW: New Defects reported by Coverity Scan for Apache Ranger

2017-09-28 Thread Abhay Kulkarni 
Contributors/Committers,

Please review and fix as appropriate.

Thanks!
-Abhay

On 9/28/17, 12:43 AM, "scan-ad...@coverity.com" 
wrote:

>
>Hi,
>
>Please find the latest report on new defect(s) introduced to Apache
>Ranger found with Coverity Scan.
>
>1 new defect(s) introduced to Apache Ranger found with Coverity Scan.
>6 defect(s), reported by Coverity Scan earlier, were marked fixed in the
>recent build analyzed by Coverity Scan.
>
>New defect(s) Reported-by: Coverity Scan
>Showing 1 of 1 defect(s)
>
>
>** CID 95505:(FORWARD_NULL)
>/security-admin/src/main/java/org/apache/ranger/biz/XUserMgr.java: 391 in
>org.apache.ranger.biz.XUserMgr.updateXUser(org.apache.ranger.view.VXUser)(
>)
>/security-admin/src/main/java/org/apache/ranger/biz/XUserMgr.java: 450 in
>org.apache.ranger.biz.XUserMgr.updateXUser(org.apache.ranger.view.VXUser)(
>)
>
>
>__
>__
>*** CID 95505:(FORWARD_NULL)
>/security-admin/src/main/java/org/apache/ranger/biz/XUserMgr.java: 391 in
>org.apache.ranger.biz.XUserMgr.updateXUser(org.apache.ranger.view.VXUser)(
>)
>385if (oldUserProfile != null && password != null
>386&& 
>password.equals(hiddenPasswordString)) {
>387
>vXPortalUser.setPassword(oldUserProfile.getPassword());
>388}
>389 else if(password != null){
>390 validatePassword(vXUser);
 CID 95505:(FORWARD_NULL)
 Calling a method on null object "oldUserProfile".
>391 if (oldUserProfile.getUserSource() ==
>RangerCommonEnums.USER_EXTERNAL) {
>392   
>vXPortalUser.setPassword(oldUserProfile.getPassword());
>393 }
>394 else if(oldUserProfile.getUserSource() ==
>RangerCommonEnums.USER_APP)
>395 {
>396vXPortalUser.setPassword(password);
>/security-admin/src/main/java/org/apache/ranger/biz/XUserMgr.java: 450 in
>org.apache.ranger.biz.XUserMgr.updateXUser(org.apache.ranger.view.VXUser)(
>)
>444}
>445 
>446// TODO I've to get the transaction log from here.
>447// There is nothing to log anything in XXUser so far.
>448vXUser = xUserService.updateResource(vXUser);
>449vXUser.setUserRoleList(roleList);
 CID 95505:(FORWARD_NULL)
 Calling a method on null object "oldUserProfile".
>450 if (oldUserProfile.getUserSource() ==
>RangerCommonEnums.USER_APP) {
>451vXUser.setPassword(password);
>452 }
>453 else if (oldUserProfile.getUserSource() ==
>RangerCommonEnums.USER_EXTERNAL) {
>454 vXUser.setPassword(oldUserProfile.getPassword());
>455 }
>
>
>__
>__
>To view the defects in Coverity Scan visit,
>https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V
>05UPxvVjWch-2Bd2MGckcRZSbhom32dlDl11LWEm9nX11zsOWMf5dv3Q9Mogo-2FGua3FsLRTF
>ft2V-2FOFC9o0P2e0-3D_eYGgfjRVvnymu7-2Fg39LOcg-2Fwh01uR5A1l1-2BVcR3oH7qLxXG
>asFbgN1kDBPIpGYM3rLSYzmeG-2BYa7G8XDIAVjfLvpuAxZDAekPb7Ge-2BSV0V3UOxGH6fq7t
>e-2FBz9K3J-2BgMSVG-2FL-2B3b8wmTbrE5RlAh1Wx7Yj2PrpxopzDpFQBM6X-2BEGeMejc-2B
>gFYqieFfxz45obau1ECnoL6Zgv3JRtmS4o-2FC5Jl5P5hM89piOfkcF6zo-3D
>
>To manage Coverity Scan email notifications for
>"akulka...@hortonworks.com", click
>https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V
>05UPxvVjWch-2Bd2MGckcRbVDbis712qZDP-2FA8y06Nq4rq896qxTW4IjcOjjCxcjhdwy7bkx
>0GaYF4jcZRTENcC8UedPeL4l2t0VBzV197ihjH14Ve5jAkEZTKufdAcDuKGDIx74O-2BWzK0Pb
>pXpwQLY-3D_eYGgfjRVvnymu7-2Fg39LOcg-2Fwh01uR5A1l1-2BVcR3oH7qLxXGasFbgN1kDB
>PIpGYM3rLSYzmeG-2BYa7G8XDIAVjfHlwaVB9Raguih-2FwkcLjJA0mCtUkkDoj8F4HwxV4ZpC
>D-2FQeY7ix0A8aSjSvg-2FysIlBGXiCWYBVwryh4hjK562Q20-2BIvhXOzSXbKxEVV5aZLnfzJ
>KG64wXkL21sShFYAI7NY6s7J5F6xWpOzCARUum7g-3D
>

[jira] [Commented] (RANGER-1779) last resource gets duplicated during update policy if policy is created through public api rest call

2017-09-28 Thread Nikhil Purbhe (JIRA) 

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

Nikhil Purbhe commented on RANGER-1779:
---

Patch commited on
master : 
https://github.com/apache/ranger/commit/a30c43db31bc0c6b69594e2fba0f243a94a789c6
Ranger-0.7 : 
https://github.com/apache/ranger/commit/997d7c3d0c87b842b77eead7ca32dd382fe24150

> last resource gets duplicated during update policy if policy is created 
> through public api rest call
> 
>
> Key: RANGER-1779
> URL: https://issues.apache.org/jira/browse/RANGER-1779
> Project: Ranger
>  Issue Type: Bug
>  Components: admin
>Affects Versions: master
>Reporter: Deepak Sharma
>Assignee: Nikhil Purbhe
> Fix For: 1.0.0, 0.7.2
>
> Attachments: RANGER-1779-0.7.patch, RANGER-1779_3 _0.7.patch, 
> RANGER-1779_3.patch, RANGER-1779.patch
>
>
> scenario:
> 1) create a policy with multiple resource *,default using public api
> 2) go to ranger admin ui and update the policy without any change
> 3) again view the policy.
> Issue:
> default gets duplicated as resource in the policy.
> and even new entry is added in resource map table for the last resource.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: Review Request 62657: The drop-down box name "database" is not showing full when edit hive policy

2017-09-28 Thread pengjianhua 

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


Ship it!




Ship It!

- pengjianhua


On 九月 28, 2017, 11:50 a.m., Qiang Zhang wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/62657/
> ---
> 
> (Updated 九月 28, 2017, 11:50 a.m.)
> 
> 
> Review request for ranger, Alok Lal, Ankita Sinha, Don Bosco Durai, Colm O 
> hEigeartaigh, Gautam Borad, Madhan Neethiraj, pengjianhua, Ramesh Mani, 
> Selvamohan Neethiraj, and Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-1813
> https://issues.apache.org/jira/browse/RANGER-1813
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> The drop-down box name "database" is not showing full when edit hive policy.
> Please see picture (database.PNG)
> 
> 
> Diffs
> -
> 
>   security-admin/src/main/webapp/styles/xa.css 9751d90b 
> 
> 
> Diff: https://reviews.apache.org/r/62657/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Qiang Zhang
> 
>

Re: Review Request 62662: Fix invalid code and error logic for the BaseDao class

2017-09-28 Thread pengjianhua 

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

(Updated 九月 28, 2017, 12:38 p.m.)


Review request for ranger, Alok Lal, Ankita Sinha, Don Bosco Durai, Colm O 
hEigeartaigh, Gautam Borad, Madhan Neethiraj, Ramesh Mani, Selvamohan 
Neethiraj, Velmurugan Periasamy, and Qiang Zhang.


Summary (updated)
-

Fix invalid code and error logic for the BaseDao class


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


Repository: ranger


Description (updated)
---

Fix invalid code and error logic for the BaseDao class


Diffs
-

  agents-audit/src/main/java/org/apache/ranger/audit/dao/BaseDao.java 75593d2f 


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


Testing
---


Thanks,

pengjianhua

[jira] [Updated] (RANGER-1815) Fix invalid code and error logic for the BaseDao class

2017-09-28 Thread peng.jianhua (JIRA) 

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

peng.jianhua updated RANGER-1815:
-
Description: Fix invalid code and error logic for the BaseDao class  (was: 
Fix invalid code and logic for BaseDao class)
Summary: Fix invalid code and error logic for the BaseDao class  (was: 
Fix invalid code and logic for BaseDao class)

> Fix invalid code and error logic for the BaseDao class
> --
>
> Key: RANGER-1815
> URL: https://issues.apache.org/jira/browse/RANGER-1815
> Project: Ranger
>  Issue Type: Bug
>  Components: audit
>Affects Versions: 1.0.0, master
>Reporter: peng.jianhua
>Assignee: peng.jianhua
>Priority: Minor
>  Labels: patch
> Attachments: 
> 0001-RANGER-1815-Fix-invalid-code-and-logic-for-BaseDao-c.patch
>
>
> Fix invalid code and error logic for the BaseDao class



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Review Request 62662: Fix invalid code and logic for BaseDao class

2017-09-28 Thread pengjianhua 

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

Review request for ranger, Alok Lal, Ankita Sinha, Don Bosco Durai, Colm O 
hEigeartaigh, Gautam Borad, Madhan Neethiraj, Ramesh Mani, Selvamohan 
Neethiraj, Velmurugan Periasamy, and Qiang Zhang.


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


Repository: ranger


Description
---

Fix invalid code and logic for BaseDao class


Diffs
-

  agents-audit/src/main/java/org/apache/ranger/audit/dao/BaseDao.java 75593d2f 


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


Testing
---


Thanks,

pengjianhua

[jira] [Updated] (RANGER-1815) Fix invalid code and logic for BaseDao class

2017-09-28 Thread peng.jianhua (JIRA) 

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

peng.jianhua updated RANGER-1815:
-
Attachment: 0001-RANGER-1815-Fix-invalid-code-and-logic-for-BaseDao-c.patch

> Fix invalid code and logic for BaseDao class
> 
>
> Key: RANGER-1815
> URL: https://issues.apache.org/jira/browse/RANGER-1815
> Project: Ranger
>  Issue Type: Bug
>  Components: audit
>Affects Versions: 1.0.0, master
>Reporter: peng.jianhua
>Assignee: peng.jianhua
>Priority: Minor
>  Labels: patch
> Attachments: 
> 0001-RANGER-1815-Fix-invalid-code-and-logic-for-BaseDao-c.patch
>
>
> Fix invalid code and logic for BaseDao class



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (RANGER-1815) Fix invalid code and logic for BaseDao class

2017-09-28 Thread peng.jianhua (JIRA) 
peng.jianhua created RANGER-1815:


 Summary: Fix invalid code and logic for BaseDao class
 Key: RANGER-1815
 URL: https://issues.apache.org/jira/browse/RANGER-1815
 Project: Ranger
  Issue Type: Bug
  Components: audit
Affects Versions: 1.0.0, master
Reporter: peng.jianhua
Assignee: peng.jianhua
Priority: Minor


Fix invalid code and logic for BaseDao class



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Review Request 62657: The drop-down box name "database" is not showing full when edit hive policy

2017-09-28 Thread Qiang Zhang 

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

Review request for ranger, Alok Lal, Ankita Sinha, Don Bosco Durai, Colm O 
hEigeartaigh, Gautam Borad, Madhan Neethiraj, pengjianhua, Ramesh Mani, 
Selvamohan Neethiraj, and Velmurugan Periasamy.


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


Repository: ranger


Description
---

The drop-down box name "database" is not showing full when edit hive policy.
Please see picture (database.PNG)


Diffs
-

  security-admin/src/main/webapp/styles/xa.css 9751d90b 


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


Testing
---


Thanks,

Qiang Zhang

[jira] [Updated] (RANGER-1812) Object HTableDescriptor can be used directly at getTableList() method for HBaseClient class

2017-09-28 Thread Colm O hEigeartaigh (JIRA) 

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

Colm O hEigeartaigh updated RANGER-1812:

Fix Version/s: 1.0.0

> Object HTableDescriptor can be used directly at getTableList() method for 
> HBaseClient class
> ---
>
> Key: RANGER-1812
> URL: https://issues.apache.org/jira/browse/RANGER-1812
> Project: Ranger
>  Issue Type: Bug
>  Components: plugins, Ranger
>Affects Versions: master
>Reporter: WangYuan
>Assignee: WangYuan
>Priority: Minor
> Fix For: 1.0.0
>
> Attachments: 
> 0001-RANGER-1812-Object-HTableDescriptor-can-be-used-dire.patch
>
>
> Object HTableDescriptor can be used directly at getTableList() method for 
> HBaseClient class
> {code:title=HBaseClient.java}
> public List getTableList(final String tableNameMatching, final 
> List existingTableList ) throws HadoopException {
> ... ...
> HTableDescriptor [] htds = admin.listTables(tableNameMatching);
> if (htds != null) {
> for (HTableDescriptor htd : admin.listTables(tableNameMatching)) {
> // The object htds can be used directly inestead of listTables once 
> again 
> // for (HTableDescriptor htd : htds )  
> String tableName = htd.getNameAsString();
> if (existingTableList != null && 
> existingTableList.contains(tableName)) {
>   continue;
> } else {
>tableList.add(htd.getNameAsString());
> }
>}
>  }
> ... ...
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (RANGER-1812) Object HTableDescriptor can be used directly at getTableList() method for HBaseClient class

2017-09-28 Thread Colm O hEigeartaigh (JIRA) 

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

Colm O hEigeartaigh resolved RANGER-1812.
-
Resolution: Fixed

> Object HTableDescriptor can be used directly at getTableList() method for 
> HBaseClient class
> ---
>
> Key: RANGER-1812
> URL: https://issues.apache.org/jira/browse/RANGER-1812
> Project: Ranger
>  Issue Type: Bug
>  Components: plugins, Ranger
>Affects Versions: master
>Reporter: WangYuan
>Assignee: WangYuan
>Priority: Minor
> Fix For: 1.0.0
>
> Attachments: 
> 0001-RANGER-1812-Object-HTableDescriptor-can-be-used-dire.patch
>
>
> Object HTableDescriptor can be used directly at getTableList() method for 
> HBaseClient class
> {code:title=HBaseClient.java}
> public List getTableList(final String tableNameMatching, final 
> List existingTableList ) throws HadoopException {
> ... ...
> HTableDescriptor [] htds = admin.listTables(tableNameMatching);
> if (htds != null) {
> for (HTableDescriptor htd : admin.listTables(tableNameMatching)) {
> // The object htds can be used directly inestead of listTables once 
> again 
> // for (HTableDescriptor htd : htds )  
> String tableName = htd.getNameAsString();
> if (existingTableList != null && 
> existingTableList.contains(tableName)) {
>   continue;
> } else {
>tableList.add(htd.getNameAsString());
> }
>}
>  }
> ... ...
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: Review Request 62650: Object HTableDescriptor can be used directly at getTableList() method for HBaseClient class

2017-09-28 Thread Colm O hEigeartaigh 

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


Ship it!




Ship It!

- Colm O hEigeartaigh


On Sept. 28, 2017, 1:38 a.m., wang yuan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/62650/
> ---
> 
> (Updated Sept. 28, 2017, 1:38 a.m.)
> 
> 
> Review request for ranger, Alok Lal, Ankita Sinha, Don Bosco Durai, Colm O 
> hEigeartaigh, Gautam Borad, Madhan Neethiraj, Ramesh Mani, Selvamohan 
> Neethiraj, Velmurugan Periasamy, and Qiang Zhang.
> 
> 
> Bugs: RANGER-1812
> https://issues.apache.org/jira/browse/RANGER-1812
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> Object HTableDescriptor can be used directly at getTableList() method for 
> HBaseClient class
> 
> {code:title=HBaseClient.java}
> public List getTableList(final String tableNameMatching, final 
> List existingTableList ) throws HadoopException {
> ... ...
> HTableDescriptor [] htds = admin.listTables(tableNameMatching);
> if (htds != null) {
> for (HTableDescriptor htd : admin.listTables(tableNameMatching)) {
> // The object htds can be used directly inestead of listTables once 
> again 
> // for (HTableDescriptor htd : htds )  
> String tableName = htd.getNameAsString();
> if (existingTableList != null && 
> existingTableList.contains(tableName)) {
>   continue;
> } else {
>tableList.add(htd.getNameAsString());
> }
>}
>  }
> ... ...
> }
> {code}
> 
> 
> Diffs
> -
> 
>   
> hbase-agent/src/main/java/org/apache/ranger/services/hbase/client/HBaseClient.java
>  d9870e39 
> 
> 
> Diff: https://reviews.apache.org/r/62650/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> wang yuan
> 
>

Review Request 62659: RANGER-1814 : Move the reader into a local variable in LocalFileLogBuffer

2017-09-28 Thread Zsombor Gegesy 

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

Review request for ranger.


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


Repository: ranger


Description
---

Static code analyser flagged sendCurrentFile in LogFileLogBuffer as dubious 
BufferedReader usage - because it's not clear if that reader is closed 
properly. Suggested to move from instance variable to method local variable


Diffs
-

  
agents-audit/src/main/java/org/apache/ranger/audit/provider/LocalFileLogBuffer.java
 56a24ed 


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


Testing
---

Tested locally, travis build: 
https://travis-ci.org/gzsombor/ranger/builds/280822647


Thanks,

Zsombor Gegesy

[jira] [Updated] (RANGER-1814) Static code analyser suggest to ensure closing Reader

2017-09-28 Thread Zsombor Gegesy (JIRA) 

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

Zsombor Gegesy updated RANGER-1814:
---
Attachment: 0001-RANGER-1814-Move-the-reader-into-a-local-variable-an.patch

> Static code analyser suggest to ensure closing Reader
> -
>
> Key: RANGER-1814
> URL: https://issues.apache.org/jira/browse/RANGER-1814
> Project: Ranger
>  Issue Type: Bug
>  Components: plugins
>Affects Versions: 0.7.1
>Reporter: Zsombor Gegesy
>Assignee: Zsombor Gegesy
>Priority: Minor
>  Labels: code-cleanup
> Fix For: 1.0.0
>
> Attachments: 
> 0001-RANGER-1814-Move-the-reader-into-a-local-variable-an.patch
>
>
> Static code analyser flagged sendCurrentFile in LogFileLogBuffer as dubious 
> BufferedReader usage - because it's not clear if that reader is closed 
> properly. Suggested to move from instance variable to method local variable 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (RANGER-1814) Static code analyser suggest to ensure closing Reader

2017-09-28 Thread Zsombor Gegesy (JIRA) 
Zsombor Gegesy created RANGER-1814:
--

 Summary: Static code analyser suggest to ensure closing Reader
 Key: RANGER-1814
 URL: https://issues.apache.org/jira/browse/RANGER-1814
 Project: Ranger
  Issue Type: Bug
  Components: plugins
Affects Versions: 0.7.1
Reporter: Zsombor Gegesy
Assignee: Zsombor Gegesy
Priority: Minor
 Fix For: 1.0.0


Static code analyser flagged sendCurrentFile in LogFileLogBuffer as dubious 
BufferedReader usage - because it's not clear if that reader is closed 
properly. Suggested to move from instance variable to method local variable 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (RANGER-1796) Updated masking policy for hive to support for deny/allowException/denyExceptions

2017-09-28 Thread peng.jianhua (JIRA) 

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

peng.jianhua edited comment on RANGER-1796 at 9/28/17 9:53 AM:
---

Hi [~madhan.neethiraj],  I think that this change (to allow deny & exceptions 
for masking policies) is necessary. Because we have the following requirement 
in real business environment:
All groups are masked except for GROUPA and GROUPB group. At the same time I 
need also masked for USER1 user, which belong to the GROUPA group.

Now the ranger can not resolve above case. 

The above case can be resolved using this feature according to following steps:
a. Select 'public' group in 'Allow Conditions'. The 'public' group is a special 
group, it represents all the groups in Ranger.
b. Select 'GROUPB' group in "Exclude from Allow Conditions"
c. Select 'GROUPA' group in 'Deny Conditions'.
d. Select 'USER1' user in 'Exclude from Deny Conditions'. The 'USER1' belongs 
to 'GROUPA' group.
Please refer to usecase-02.png.

More complex logic can also be supported by this feature. The feature will not 
affect the existing function, it is the enhancement and improvement for the 
existing function.


was (Author: peng.jianhua):
Hi [~madhan.neethiraj],  I think that this change (to allow deny & exceptions 
for masking policies) is necessary. Because we have the following requirement 
in real business environment:
I masked for all groups except GROUPA and GROUPB group. At the same time I need 
also masked for USER1 user, which belong to the GROUPA group.

Now the ranger can not resolve above case. 

The above case can be resolved using this feature according to following steps:
a. Select 'public' group in 'Allow Conditions'. The 'public' group is a special 
group, it represents all the groups in Ranger.
b. Select 'GROUPB' group in "Exclude from Allow Conditions"
c. Select 'GROUPA' group in 'Deny Conditions'.
d. Select 'USER1' user in 'Exclude from Deny Conditions'. The 'USER1' belongs 
to 'GROUPA' group.
Please refer to usecase-02.png.

More complex logic can also be supported by this feature. The feature will not 
affect the existing function, it is the enhancement and improvement for the 
existing function.

> Updated masking policy for hive  to support for 
> deny/allowException/denyExceptions
> --
>
> Key: RANGER-1796
> URL: https://issues.apache.org/jira/browse/RANGER-1796
> Project: Ranger
>  Issue Type: New Feature
>  Components: plugins
>Affects Versions: 1.0.0, master
>Reporter: peng.jianhua
>Assignee: peng.jianhua
>  Labels: newbie, patch
> Attachments: 
> 0001-RANGER-1796-Updated-masking-policy-for-hive-to-suppo.patch, 
> masking-03.png, masking2.png, usecase-01.png, usecase-02.png
>
>
> Masking policy for hive  should support for 
> deny/allowException/denyExceptions to meet further business needs. Such as 
> masking policy for hive should support as following scene and so on:
> USER1, USER2 and USER3 belong to the user group GROUPA. Select GROUPA group 
> when created masking policy. The USER1 does not use masking and USER2, USER3 
> need masking.
> We rigorously tested this issue. The test result shows that the feature is ok.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (RANGER-1796) Updated masking policy for hive to support for deny/allowException/denyExceptions

2017-09-28 Thread peng.jianhua (JIRA) 

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

peng.jianhua updated RANGER-1796:
-
Attachment: usecase-02.png

> Updated masking policy for hive  to support for 
> deny/allowException/denyExceptions
> --
>
> Key: RANGER-1796
> URL: https://issues.apache.org/jira/browse/RANGER-1796
> Project: Ranger
>  Issue Type: New Feature
>  Components: plugins
>Affects Versions: 1.0.0, master
>Reporter: peng.jianhua
>Assignee: peng.jianhua
>  Labels: newbie, patch
> Attachments: 
> 0001-RANGER-1796-Updated-masking-policy-for-hive-to-suppo.patch, 
> masking-03.png, masking2.png, usecase-01.png, usecase-02.png
>
>
> Masking policy for hive  should support for 
> deny/allowException/denyExceptions to meet further business needs. Such as 
> masking policy for hive should support as following scene and so on:
> USER1, USER2 and USER3 belong to the user group GROUPA. Select GROUPA group 
> when created masking policy. The USER1 does not use masking and USER2, USER3 
> need masking.
> We rigorously tested this issue. The test result shows that the feature is ok.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (RANGER-1796) Updated masking policy for hive to support for deny/allowException/denyExceptions

2017-09-28 Thread peng.jianhua (JIRA) 

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

peng.jianhua commented on RANGER-1796:
--

Hi [~madhan.neethiraj],  I think that this change (to allow deny & exceptions 
for masking policies) is necessary. Because we have the following requirement 
in real business environment:
I masked for all groups except GROUPA and GROUPB group. At the same time I need 
also masked for USER1 user, which belong to the GROUPA group.

Now the ranger can not resolve above case. 

The above case can be resolved using this feature according to following steps:
a. Select 'public' group in 'Allow Conditions'. The 'public' group is a special 
group, it represents all the groups in Ranger.
b. Select 'GROUPB' group in "Exclude from Allow Conditions"
c. Select 'GROUPA' group in 'Deny Conditions'.
d. Select 'USER1' user in 'Exclude from Deny Conditions'. The 'USER1' belongs 
to 'GROUPA' group.
Please refer to usecase-02.png.

More complex logic can also be supported by this feature. The feature will not 
affect the existing function, it is the enhancement and improvement for the 
existing function.

> Updated masking policy for hive  to support for 
> deny/allowException/denyExceptions
> --
>
> Key: RANGER-1796
> URL: https://issues.apache.org/jira/browse/RANGER-1796
> Project: Ranger
>  Issue Type: New Feature
>  Components: plugins
>Affects Versions: 1.0.0, master
>Reporter: peng.jianhua
>Assignee: peng.jianhua
>  Labels: newbie, patch
> Attachments: 
> 0001-RANGER-1796-Updated-masking-policy-for-hive-to-suppo.patch, 
> masking-03.png, masking2.png, usecase-01.png
>
>
> Masking policy for hive  should support for 
> deny/allowException/denyExceptions to meet further business needs. Such as 
> masking policy for hive should support as following scene and so on:
> USER1, USER2 and USER3 belong to the user group GROUPA. Select GROUPA group 
> when created masking policy. The USER1 does not use masking and USER2, USER3 
> need masking.
> We rigorously tested this issue. The test result shows that the feature is ok.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (RANGER-1790) From the ease of use point of view, Select / Deselect All and other checkbox should be associated in add/edit permissions pop window.

2017-09-28 Thread Qiang Zhang (JIRA) 

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

Qiang Zhang resolved RANGER-1790.
-
   Resolution: Fixed
Fix Version/s: master
   1.0.0

> From the ease of use point of view, Select / Deselect All and other checkbox 
> should be associated in add/edit permissions pop window.
> -
>
> Key: RANGER-1790
> URL: https://issues.apache.org/jira/browse/RANGER-1790
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Affects Versions: 1.0.0, master
>Reporter: peng.jianhua
>Assignee: peng.jianhua
>Priority: Minor
>  Labels: patch
> Fix For: 1.0.0, master
>
> Attachments: 
> 0001-RANGER-1790-Select-Deselect-All-should-along-with-th.patch, 
> select-all-permissions-01.png, select-all-permissions.png
>
>
> The current logic is as following:
> 1. Other checkbox will be selected when the "Select checkbox" was selected.
> 2.  Other checkbox will be deselected when the "Deselect checkbox" was 
> selected.
> 3. The "Select / Deselect All" checkbox was not automatically selected when 
> all checkbox were Selected.
> 4. The "Select / Deselect All" checkbox was not automatically deselected when 
> all checkbox were deselected.
> The right logic should be as following:
> 1. Other checkbox will be selected when the "Select checkbox" was selected.
> 2.  Other checkbox will be deselected when the "Deselect checkbox" was 
> selected.
> 3. The "Select / Deselect All" checkbox was automatically selected when all 
> checkbox were Selected.
> 4. The "Select / Deselect All" checkbox was automatically deselected when all 
> checkbox were deselected.
> Please refer to select-all-permissions.png and select-all-permissions-01.png.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (RANGER-1813) The drop-down box name "database" is not showing full when edit hive policy

2017-09-28 Thread Qiang Zhang (JIRA) 

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

Qiang Zhang updated RANGER-1813:

Attachment: database.PNG

> The drop-down box name "database" is not showing full when edit hive policy
> ---
>
> Key: RANGER-1813
> URL: https://issues.apache.org/jira/browse/RANGER-1813
> Project: Ranger
>  Issue Type: Bug
>  Components: admin
>Reporter: Qiang Zhang
>Assignee: Qiang Zhang
>Priority: Minor
> Attachments: 
> 0001-RANGER-1813-The-drop-down-box-name-database-is-not-s.patch, database.PNG
>
>
> The drop-down box name "database" is not showing full when edit hive policy.
> Please see picture (database.PNG)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (RANGER-1802) Here is a error in getStatusResponse() when post data exception for AtlasClient class

2017-09-28 Thread peng.jianhua (JIRA) 

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

peng.jianhua resolved RANGER-1802.
--
   Resolution: Fixed
Fix Version/s: master
   1.0.0

> Here is a error in getStatusResponse() when post data exception for 
> AtlasClient class
> -
>
> Key: RANGER-1802
> URL: https://issues.apache.org/jira/browse/RANGER-1802
> Project: Ranger
>  Issue Type: Bug
>  Components: plugins
>Affects Versions: 1.0.0, master
>Reporter: Qiang Zhang
>Assignee: peng.jianhua
>Priority: Minor
> Fix For: 1.0.0, master
>
> Attachments: 
> 0001-RANGER-1802-Here-is-a-error-in-getStatusResponse-whe.patch
>
>
> Here is a error in getStatusResponse() when post data exception for 
> AtlasClient class
> {code}
> try {
>   statusResponse = 
> webResource.type("application/x-www-form-urlencoded").post(ClientResponse.class,
>   formData);
>   } catch (Exception e) {
>   String msgDesc = "Unable to get a valid 
> statusResponse for " + "expected mime type : ["
>   + EXPECTED_MIME_TYPE + "] URL : 
> " + statusUrl + " - got null response.";
>   LOG.error(msgDesc);
>   }
> {code}
> should be
> {code}
> try {
>   statusResponse = 
> webResource.type("application/x-www-form-urlencoded").post(ClientResponse.class,
>   formData);
>   } catch (Exception e) {
>   String msgDesc = "Unable to get a valid 
> statusResponse for " + "expected mime type : 
> [application/x-www-form-urlencoded] URL : " + statusUrl + " - got null 
> response.";
>   LOG.error(msgDesc);
>   }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: Review Request 62495: RANGER-1797:Tomcat Security Vulnerability Alert. The version of the tomcat for ranger should upgrade to 7.0.81.

2017-09-28 Thread pengjianhua 


> On 九月 22, 2017, 9:11 a.m., bhavik patel wrote:
> > pom.xml
> > Line 212 (original), 212 (patched)
> > 
> >
> > @pengjianhua : This change needs thorough testing of Ranger Admin as 
> > well as Ranger KMS in Simple,  Kerberos, SSL, KnoxSSO, KnoxProxy enabled 
> > environments.  
> > 
> > Also need to check all features on jdk 1.7 as well as 1.8. Also, 
> > atleast one plugin communication needs to be verified. 
> > 
> > Can you please confirm: all these cases are tested before commiting 
> > this patch. 
> > 
> > This is based on earlier experience of updating tomcat version.
> 
> pengjianhua wrote:
> Ok. We have a complete automated integration test environment for Ranger. 
> I had tested the functions of Ranger using our automated integration test 
> environment. The test results show that there is no problem. I will further 
> test the effect of this issue for ranger using our automated integration test 
> environment in tonight and tomorrow.
> 
> Qiang Zhang wrote:
> @bhavik patel: Do you have further suggestions? If not, I'll fix the 
> issue.
> 
> bhavik patel wrote:
> @Qiang Zhang: If Peng Jianhua can confirm that there integration test 
> covered all the above scenario which i mentioned above(especially on SSL 
> environment).

@bhavik patel: Thanks for your reminder, I lack this case for my automated 
integration test environment.?I will add this case to my automated integration 
test environment and test it again. Thanks.


- pengjianhua


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


On 九月 22, 2017, 8:35 a.m., pengjianhua wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/62495/
> ---
> 
> (Updated 九月 22, 2017, 8:35 a.m.)
> 
> 
> Review request for ranger, Alok Lal, Ankita Sinha, Don Bosco Durai, Colm O 
> hEigeartaigh, Gautam Borad, Madhan Neethiraj, Ramesh Mani, Selvamohan 
> Neethiraj, Velmurugan Periasamy, and Qiang Zhang.
> 
> 
> Bugs: RANGER-1797
> https://issues.apache.org/jira/browse/RANGER-1797
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> [Security Vulnerability Alert] Tomcat Information leakage and remote code 
> execution vulnerabilities.
> 
> CVE ID:
> CVE-2017-12615\CVE-2017-12616
> 
> Description
> CVE-2017-12615:When running Apache Tomcat 7.0.0 to 7.0.79 on Windows with 
> HTTP PUTs enabled, it was possible to upload a JSP file to the server via a 
> specially crafted request. This JSP could then be requested and any code it 
> contained would be executed by the server.
> CVE-2017-12616:When using a VirtualDirContext with Apache Tomcat 7.0.0 to 
> 7.0.80, it was possible to use a specially crafted request, bypass security 
> constraints, or get the source code of JSPs for resources served by the 
> VirtualDirContext, thereby cased code disclosure.
> 
> Scope
> CVE-2017-12615:Apache Tomcat 7.0.0 - 7.0.79
> CVE-2017-12616:Apache Tomcat 7.0.0 - 7.0.80
> 
> Solution
> The official release of the Apache Tomcat 7.0.81 version has fixed the two 
> vulnerabilities and recommends upgrading to the latest version.
> 
> Reference
> https://tomcat.apache.org/security-7.html
> http://tomcat.apache.org/security-7.html#Fixed_in_Apache_Tomcat_7.0.81
> 
> 
> Diffs
> -
> 
>   pom.xml 3958014c 
> 
> 
> Diff: https://reviews.apache.org/r/62495/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> pengjianhua
> 
>