[jira] [Commented] (RANGER-1484) RangerUI: Escape of policy condition text entered in the policy form.

2017-04-03 Thread Gautam Borad (JIRA)

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

Gautam Borad commented on RANGER-1484:
--

Committed to master: bdf0b61c0f6e109c2f4e0459676dda71f0265aeb
Committed to ranger-0.7 : ba664e1b310ae65b674ff28e0772d208d3b20464

> RangerUI: Escape of policy condition text entered in the policy form.
> -
>
> Key: RANGER-1484
> URL: https://issues.apache.org/jira/browse/RANGER-1484
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Affects Versions: 0.7.0
>Reporter: Madhan Neethiraj
>Assignee: Nitin Galave
> Fix For: 1.0.0, 0.7.1
>
> Attachments: image001.png, image002.png, RANGER-1484.patch
>
>
> The text entered in policy condition UI comes back with escape characters 
> after saving the policy.
> {code}
> For example: 
> 1.create policy with policy condition as “tag.attributes['type']=='ccn'” .
> 2.Now open that policy in edit mode you will see policy condition 
> becomes "tag.attributes['type']=='ccn'".
> {code}
> Another issue is that UI displays policy conditions that don’t have any 
> value.Only the condition edit popup would list all the conditions; the policy 
> view would only list the conditions that have non-empty value.
> See attachments for more info: image001.png, image002.png.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


Re: Review Request 58104: RangerUI: Escape of policy condition text entered in the policy form.

2017-04-03 Thread Gautam Borad

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


Ship it!




Ship It!

- Gautam Borad


On March 31, 2017, 11:15 a.m., Nitin Galave wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58104/
> ---
> 
> (Updated March 31, 2017, 11:15 a.m.)
> 
> 
> Review request for ranger, Gautam Borad, Madhan Neethiraj, Mehul Parikh, 
> Pradeep Agrawal, and Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-1484
> https://issues.apache.org/jira/browse/RANGER-1484
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> The text entered in policy condition UI comes back with escape characters 
> after saving the policy.
> 
> For example: 
> 1.create policy with policy condition as “tag.attributes['type']=='ccn'” .
> 2.Now open that policy in edit mode you will see policy condition 
> becomes "tag.attributes['type']=='ccn'".
> 
> Another issue is that UI displays policy conditions that don’t have any 
> value.Only the condition edit popup would list all the conditions; the policy 
> view would only list the conditions that have non-empty value.
> 
> 
> Diffs
> -
> 
>   security-admin/src/main/webapp/scripts/modules/XAOverrides.js 1e2b553 
>   security-admin/src/main/webapp/scripts/views/policies/PermissionList.js 
> 2ac494e 
> 
> 
> Diff: https://reviews.apache.org/r/58104/diff/1/
> 
> 
> Testing
> ---
> 
> Verified : Text entered in policy condition come back as it is after saving 
> policy.
> Tested with following characters : ~`!@#$%^&*()-_+={}[]:;"'<,>.?/
> 
> Verified : UI only displays policy conditions name and value which has 
> non-empty values.
> 
> 
> Thanks,
> 
> Nitin Galave
> 
>



[jira] [Created] (RANGER-1496) Excel/csv exported file should have complete details of the policy

2017-04-03 Thread Mehul Parikh (JIRA)
Mehul Parikh created RANGER-1496:


 Summary: Excel/csv exported file should have complete details of 
the policy
 Key: RANGER-1496
 URL: https://issues.apache.org/jira/browse/RANGER-1496
 Project: Ranger
  Issue Type: Bug
  Components: admin
Affects Versions: 0.7.0
Reporter: Mehul Parikh
Priority: Minor
 Fix For: 0.7.1


If export of the policy is done from the Reports page in excel/csv format then 
we are not showing info like Isaudit enabled, delegate admin and row filter and 
masking condition etc .
Add following fields in exported excel / csv files : 

* policyType
* delegateAdmin
* isRecursiveValue
* isExcludesValue
* serviceName
* description
* isAuditEnabled
* conditionKeyValue
* policyConditionTypeValue
* maskingInfo
* filterExpr




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (RANGER-1492) UI updates to support tag-based masking policies

2017-04-03 Thread Nitin Galave (JIRA)

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

Nitin Galave updated RANGER-1492:
-
Attachment: RANGER-1492.patch

> UI updates to support tag-based masking policies
> 
>
> Key: RANGER-1492
> URL: https://issues.apache.org/jira/browse/RANGER-1492
> Project: Ranger
>  Issue Type: Sub-task
>  Components: admin
>Reporter: Madhan Neethiraj
>Assignee: Nitin Galave
> Attachments: RANGER-1492.patch
>
>
> UI should be updated to support tag-based masking policies, in addition to 
> existing tag-based access policies. Similar to Hive services, UI can show 
> 'Masking' tab for tag-services when tag serviceDef has non-empty dataMaskDef.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (RANGER-1495) Good coding practices recommendation by static code analysis

2017-04-03 Thread Ramesh Mani (JIRA)

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

Ramesh Mani updated RANGER-1495:

Summary: Good coding practices recommendation by static code analysis  
(was: Good coding practices recommedation by static code analysis)

> Good coding practices recommendation by static code analysis
> 
>
> Key: RANGER-1495
> URL: https://issues.apache.org/jira/browse/RANGER-1495
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Affects Versions: 0.7.1
>Reporter: Ramesh Mani
>Assignee: Ramesh Mani
> Fix For: 0.7.1
>
>
> Good coding practices recommendation by static code analysis



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (RANGER-1495) Good coding practices recommedation by static code analysis

2017-04-03 Thread Ramesh Mani (JIRA)

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

Ramesh Mani updated RANGER-1495:

Description: Good coding practices recommendation by static code analysis  
(was: Good coding practices recommedation by static code analysis)

> Good coding practices recommedation by static code analysis
> ---
>
> Key: RANGER-1495
> URL: https://issues.apache.org/jira/browse/RANGER-1495
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Affects Versions: 0.7.1
>Reporter: Ramesh Mani
>Assignee: Ramesh Mani
> Fix For: 0.7.1
>
>
> Good coding practices recommendation by static code analysis



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (RANGER-1495) Good coding practices recommendation by static code analysis

2017-04-03 Thread Ramesh Mani (JIRA)

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

Ramesh Mani commented on RANGER-1495:
-

Review link https://reviews.apache.org/r/58165/

> Good coding practices recommendation by static code analysis
> 
>
> Key: RANGER-1495
> URL: https://issues.apache.org/jira/browse/RANGER-1495
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Affects Versions: 0.7.1
>Reporter: Ramesh Mani
>Assignee: Ramesh Mani
> Fix For: 0.7.1
>
>
> Good coding practices recommendation by static code analysis



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


Review Request 58165: RANGER-1495: Good coding practices recommendation by static code analysis

2017-04-03 Thread Ramesh Mani

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

Review request for ranger, Abhay Kulkarni, Madhan Neethiraj, and Velmurugan 
Periasamy.


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


Repository: ranger


Description
---

RANGER-1495: Good coding practices recommendation by static code analysis


Diffs
-

  
hive-agent/src/main/java/org/apache/ranger/services/hive/client/HiveClient.java 
6cc62a7 


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


Testing
---

Testing done in VM


Thanks,

Ramesh Mani



[jira] [Created] (RANGER-1495) Good coding practices recommedation by static code analysis

2017-04-03 Thread Ramesh Mani (JIRA)
Ramesh Mani created RANGER-1495:
---

 Summary: Good coding practices recommedation by static code 
analysis
 Key: RANGER-1495
 URL: https://issues.apache.org/jira/browse/RANGER-1495
 Project: Ranger
  Issue Type: Bug
  Components: Ranger
Affects Versions: 0.7.1
Reporter: Ramesh Mani
Assignee: Ramesh Mani
 Fix For: 0.7.1


Good coding practices recommedation by static code analysis



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


Re: Review Request 58034: 'Ranger KMS' repo is not getting created in manual installation

2017-04-03 Thread Abhay Kulkarni

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

(Updated April 3, 2017, 9:11 p.m.)


Review request for ranger and Madhan Neethiraj.


Changes
---

Addressed review comments


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


Repository: ranger


Description
---

When KMS default policies are created as part of KMS repo creation, two service 
users (defined by Ranger-Admin configuration variables in 
ranger-admin-site.xml, viz ranger.kms.service.user.hdfs and 
ranger.kms.service.user.hive) are expected to be pre-created. They are 
precreated when Ranger is installed with Ambari. For manual installation of 
Ranger, they may not have been pre-created before KMS repo is created. 

The fix is to parse default policies that need to be created to find any 
users/groups that do not exist in Ranger, and create them before attempting to 
create default policies.


Diffs (updated)
-

  
agents-common/src/main/java/org/apache/ranger/services/tag/RangerServiceTag.java
 4d6acda 
  security-admin/src/main/java/org/apache/ranger/biz/ServiceDBStore.java 
2a9c003 


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

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


Testing
---

Provided non-existent user-names as values of ranger.kms.service.user.hdfs and 
ranger.kms.service.user.hive configuration variables, and successfully created 
a KMS repo. The users configured as ranger.kms.service.user.hdfs and 
ranger.kms.service.user.hive were created in Ranger.


Thanks,

Abhay Kulkarni



Review Request 58154: Policy engine updates to support tag-based masking policies

2017-04-03 Thread Abhay Kulkarni

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

Review request for ranger and Madhan Neethiraj.


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


Repository: ranger


Description
---

The policy engine is enhanced to support tag-based policies for masking as well 
i.e. evalDataMaskPolicies()


Diffs
-

  
agents-common/src/main/java/org/apache/ranger/plugin/policyengine/RangerAccessResourceImpl.java
 9d8a651 
  
agents-common/src/main/java/org/apache/ranger/plugin/policyengine/RangerPolicyEngine.java
 06c7d16 
  
agents-common/src/main/java/org/apache/ranger/plugin/policyengine/RangerPolicyEngineImpl.java
 508ef93 


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


Testing
---

Updated Tag-Service-Definition with dataMaskDef section for hive component, 
created a tag policy for data-masking; tagged a hive column with a tag and used 
beeline to test data-masking for that column.


Thanks,

Abhay Kulkarni



[jira] [Assigned] (RANGER-1493) Policy engine updates to support tag-based masking policies

2017-04-03 Thread Abhay Kulkarni (JIRA)

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

Abhay Kulkarni reassigned RANGER-1493:
--

Assignee: Abhay Kulkarni

> Policy engine updates to support tag-based masking policies
> ---
>
> Key: RANGER-1493
> URL: https://issues.apache.org/jira/browse/RANGER-1493
> Project: Ranger
>  Issue Type: Sub-task
>  Components: plugins
>Reporter: Madhan Neethiraj
>Assignee: Abhay Kulkarni
>
> Currently, Ranger policy engine evaluates tag-based policies for authorizing 
> accesses i.e. isAccessAllowed() methods. The policy engine should be enhanced 
> to support tag-based policies for masking as well i.e. evalDataMaskPolicies()



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Assigned] (RANGER-1494) Tag service-def updates to support masking policies

2017-04-03 Thread Abhay Kulkarni (JIRA)

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

Abhay Kulkarni reassigned RANGER-1494:
--

Assignee: Abhay Kulkarni

> Tag service-def updates to support masking policies
> ---
>
> Key: RANGER-1494
> URL: https://issues.apache.org/jira/browse/RANGER-1494
> Project: Ranger
>  Issue Type: Sub-task
>  Components: admin
>Reporter: Madhan Neethiraj
>Assignee: Abhay Kulkarni
>
> Currently Ranger admin updates tag service-def for the addition/update of 
> other service-def, so that the accessTypes in these service-defs will be 
> available in tag service-def as well. This should be extended to sync 
> dataMaskDef as well to tag service-def.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Assigned] (RANGER-1492) UI updates to support tag-based masking policies

2017-04-03 Thread Nitin Galave (JIRA)

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

Nitin Galave reassigned RANGER-1492:


Assignee: Nitin Galave

> UI updates to support tag-based masking policies
> 
>
> Key: RANGER-1492
> URL: https://issues.apache.org/jira/browse/RANGER-1492
> Project: Ranger
>  Issue Type: Sub-task
>  Components: admin
>Reporter: Madhan Neethiraj
>Assignee: Nitin Galave
>
> UI should be updated to support tag-based masking policies, in addition to 
> existing tag-based access policies. Similar to Hive services, UI can show 
> 'Masking' tab for tag-services when tag serviceDef has non-empty dataMaskDef.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Created] (RANGER-1494) Tag service-def updates to support masking policies

2017-04-03 Thread Madhan Neethiraj (JIRA)
Madhan Neethiraj created RANGER-1494:


 Summary: Tag service-def updates to support masking policies
 Key: RANGER-1494
 URL: https://issues.apache.org/jira/browse/RANGER-1494
 Project: Ranger
  Issue Type: Sub-task
  Components: admin
Reporter: Madhan Neethiraj


Currently Ranger admin updates tag service-def for the addition/update of other 
service-def, so that the accessTypes in these service-defs will be available in 
tag service-def as well. This should be extended to sync dataMaskDef as well to 
tag service-def.





--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Created] (RANGER-1493) Policy engine updates to support tag-based masking policies

2017-04-03 Thread Madhan Neethiraj (JIRA)
Madhan Neethiraj created RANGER-1493:


 Summary: Policy engine updates to support tag-based masking 
policies
 Key: RANGER-1493
 URL: https://issues.apache.org/jira/browse/RANGER-1493
 Project: Ranger
  Issue Type: Sub-task
  Components: plugins
Reporter: Madhan Neethiraj


Currently, Ranger policy engine evaluates tag-based policies for authorizing 
accesses i.e. isAccessAllowed() methods. The policy engine should be enhanced 
to support tag-based policies for masking as well i.e. evalDataMaskPolicies()



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Created] (RANGER-1492) UI updates to support tag-based masking policies

2017-04-03 Thread Madhan Neethiraj (JIRA)
Madhan Neethiraj created RANGER-1492:


 Summary: UI updates to support tag-based masking policies
 Key: RANGER-1492
 URL: https://issues.apache.org/jira/browse/RANGER-1492
 Project: Ranger
  Issue Type: Sub-task
  Components: admin
Reporter: Madhan Neethiraj


UI should be updated to support tag-based masking policies, in addition to 
existing tag-based access policies. Similar to Hive services, UI can show 
'Masking' tab for tag-services when tag serviceDef has non-empty dataMaskDef.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Comment Edited] (RANGER-1168) Add data masking for tag based policies

2017-04-03 Thread Madhan Neethiraj (JIRA)

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

Madhan Neethiraj edited comment on RANGER-1168 at 4/3/17 5:27 PM:
--

+1 for the enhancement to support tag-based masking policy.

However, I am sure how useful it would be to support row-filtering based on 
tags - given the filter expression would most likely to be dependent on the 
schema of the table. I would suggest we study this in more detail with few 
usecases and track it via a separate JIRA.


was (Author: madhan.neethiraj):
+1 for the enhancement to support tag-based masking policy

> Add data masking for tag based policies
> ---
>
> Key: RANGER-1168
> URL: https://issues.apache.org/jira/browse/RANGER-1168
> Project: Ranger
>  Issue Type: New Feature
>  Components: plugins
>Reporter: Nigel Jones
>  Labels: VirtualDataConnector
>
> Currently in Hive its possible to create tag based policies. For example a 
> policy can prevent a user from accessing data in a column tagged as sensitive 
> - with that classification likely coming from Apache Atlas.
> In order to support the principle of applying a policy to a classification 
> rather than an actual resort, we should extend Ranger & in particular the 
> plugins such as hive to allow tag based policies to support
>  - data masking
>  - row filtering
> I believe this is important to support the principle of Apache Atlas being 
> used to centrally manage metadata & the classification of resources



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Comment Edited] (RANGER-1168) Add data masking for tag based policies

2017-04-03 Thread Madhan Neethiraj (JIRA)

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

Madhan Neethiraj edited comment on RANGER-1168 at 4/3/17 5:28 PM:
--

+1 for the enhancement to support tag-based masking policy.

However, I am not sure how useful it would be to support row-filtering based on 
tags - given the filter expression would most likely to be dependent on the 
schema of the table. I would suggest we study this in more detail with few 
usecases and track it via a separate JIRA.


was (Author: madhan.neethiraj):
+1 for the enhancement to support tag-based masking policy.

However, I am sure how useful it would be to support row-filtering based on 
tags - given the filter expression would most likely to be dependent on the 
schema of the table. I would suggest we study this in more detail with few 
usecases and track it via a separate JIRA.

> Add data masking for tag based policies
> ---
>
> Key: RANGER-1168
> URL: https://issues.apache.org/jira/browse/RANGER-1168
> Project: Ranger
>  Issue Type: New Feature
>  Components: plugins
>Reporter: Nigel Jones
>  Labels: VirtualDataConnector
>
> Currently in Hive its possible to create tag based policies. For example a 
> policy can prevent a user from accessing data in a column tagged as sensitive 
> - with that classification likely coming from Apache Atlas.
> In order to support the principle of applying a policy to a classification 
> rather than an actual resort, we should extend Ranger & in particular the 
> plugins such as hive to allow tag based policies to support
>  - data masking
>  - row filtering
> I believe this is important to support the principle of Apache Atlas being 
> used to centrally manage metadata & the classification of resources



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (RANGER-1168) Add data masking for tag based policies

2017-04-03 Thread Madhan Neethiraj (JIRA)

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

Madhan Neethiraj commented on RANGER-1168:
--

+1 for the enhancement to support tag-based masking policy

> Add data masking for tag based policies
> ---
>
> Key: RANGER-1168
> URL: https://issues.apache.org/jira/browse/RANGER-1168
> Project: Ranger
>  Issue Type: New Feature
>  Components: plugins
>Reporter: Nigel Jones
>  Labels: VirtualDataConnector
>
> Currently in Hive its possible to create tag based policies. For example a 
> policy can prevent a user from accessing data in a column tagged as sensitive 
> - with that classification likely coming from Apache Atlas.
> In order to support the principle of applying a policy to a classification 
> rather than an actual resort, we should extend Ranger & in particular the 
> plugins such as hive to allow tag based policies to support
>  - data masking
>  - row filtering
> I believe this is important to support the principle of Apache Atlas being 
> used to centrally manage metadata & the classification of resources



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Resolved] (RANGER-1489) Solr plugin fails to get client address

2017-04-03 Thread Ramesh Mani (JIRA)

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

Ramesh Mani resolved RANGER-1489.
-
Resolution: Fixed

> Solr plugin fails to get client address
> ---
>
> Key: RANGER-1489
> URL: https://issues.apache.org/jira/browse/RANGER-1489
> Project: Ranger
>  Issue Type: Bug
>  Components: plugins
>Affects Versions: 0.6.3, 1.0.0
>Reporter: Yan
>Assignee: Yan
>Priority: Minor
>
> A immediate consequence is that IP-range conditions all fail for Solr 
> authorizations.
> context.getHttpHeader("REMOTE_ADDR") is used; instead context.getRemoteAddr() 
> is more appropriate.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


Re: Review Request 58115: Ranger-1489: Solr plugin fails to get client address

2017-04-03 Thread Madhan Neethiraj

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


Ship it!




Ship It!

- Madhan Neethiraj


On March 31, 2017, 6:20 p.m., Yan Zhou wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58115/
> ---
> 
> (Updated March 31, 2017, 6:20 p.m.)
> 
> 
> Review request for ranger.
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> An immediate consequence is that IP-range conditions all fail for Solr 
> authorizations.
> 
> 
> Diffs
> -
> 
>   
> plugin-solr/src/main/java/org/apache/ranger/authorization/solr/authorizer/RangerSolrAuthorizer.java
>  832302c 
> 
> 
> Diff: https://reviews.apache.org/r/58115/diff/1/
> 
> 
> Testing
> ---
> 
> auto and manual
> 
> 
> Thanks,
> 
> Yan Zhou
> 
>



[jira] [Commented] (RANGER-1489) Solr plugin fails to get client address

2017-04-03 Thread Ramesh Mani (JIRA)

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

Ramesh Mani commented on RANGER-1489:
-

Commit link http://git-wip-us.apache.org/repos/asf/ranger/commit/f2ab4279

> Solr plugin fails to get client address
> ---
>
> Key: RANGER-1489
> URL: https://issues.apache.org/jira/browse/RANGER-1489
> Project: Ranger
>  Issue Type: Bug
>  Components: plugins
>Affects Versions: 0.6.3, 1.0.0
>Reporter: Yan
>Assignee: Yan
>Priority: Minor
>
> A immediate consequence is that IP-range conditions all fail for Solr 
> authorizations.
> context.getHttpHeader("REMOTE_ADDR") is used; instead context.getRemoteAddr() 
> is more appropriate.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


Re: Review Request 58034: 'Ranger KMS' repo is not getting created in manual installation

2017-04-03 Thread Madhan Neethiraj

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


Fix it, then Ship it!





agents-common/src/main/java/org/apache/ranger/services/tag/RangerServiceTag.java
Lines 163 (patched)


I think just the tag-name for the policy would be better - "EXPIRES_ON", 
instead of "expires_on-tag_policy"



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


Consider excluding user names like {OWNER}, {USER} from here.


- Madhan Neethiraj


On March 31, 2017, 7:31 p.m., Abhay Kulkarni wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58034/
> ---
> 
> (Updated March 31, 2017, 7:31 p.m.)
> 
> 
> Review request for ranger and Madhan Neethiraj.
> 
> 
> Bugs: RANGER-1482
> https://issues.apache.org/jira/browse/RANGER-1482
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> When KMS default policies are created as part of KMS repo creation, two 
> service users (defined by Ranger-Admin configuration variables in 
> ranger-admin-site.xml, viz ranger.kms.service.user.hdfs and 
> ranger.kms.service.user.hive) are expected to be pre-created. They are 
> precreated when Ranger is installed with Ambari. For manual installation of 
> Ranger, they may not have been pre-created before KMS repo is created. 
> 
> The fix is to parse default policies that need to be created to find any 
> users/groups that do not exist in Ranger, and create them before attempting 
> to create default policies.
> 
> 
> Diffs
> -
> 
>   
> agents-common/src/main/java/org/apache/ranger/services/tag/RangerServiceTag.java
>  4d6acda 
>   security-admin/src/main/java/org/apache/ranger/biz/ServiceDBStore.java 
> 2a9c003 
> 
> 
> Diff: https://reviews.apache.org/r/58034/diff/2/
> 
> 
> Testing
> ---
> 
> Provided non-existent user-names as values of ranger.kms.service.user.hdfs 
> and ranger.kms.service.user.hive configuration variables, and successfully 
> created a KMS repo. The users configured as ranger.kms.service.user.hdfs and 
> ranger.kms.service.user.hive were created in Ranger.
> 
> 
> Thanks,
> 
> Abhay Kulkarni
> 
>



[jira] [Resolved] (RANGER-1479) Plugins couldnt load settings xml files from the classpath, if they are inside a jar

2017-04-03 Thread Colm O hEigeartaigh (JIRA)

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

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

> Plugins couldnt load settings xml files from the classpath, if they are 
> inside a jar
> 
>
> Key: RANGER-1479
> URL: https://issues.apache.org/jira/browse/RANGER-1479
> Project: Ranger
>  Issue Type: Bug
>  Components: plugins
>Affects Versions: 0.7.0
>Reporter: Zsombor Gegesy
>Assignee: Zsombor Gegesy
>  Labels: configuration, plugins
> Fix For: 1.0.0
>
> Attachments: 
> 0001-RANGER-1479-Fix-bug-in-ranger-security-audit-.xml-lo.patch
>
>
> RangerConfiguration first checks, if the necessary xml files are on the 
> classpath, and after it tries to convert it to a file path, check that file 
> is on the filesystem, and convert that path to back to URL. If the 
> configurations are inside a jar, then this will fail very badly  (the 
> resource url will be something file://config.jar!/ranger-services.xml )
> If the conversion is removed, it would work pretty nicely



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


Re: Review Request 57987: RANGER-1478 : Small refactor in RangerPolicyEngineCache and RangerPolicyEngineOptions, to avoid looking up RangerConfiguration everytime, and try to write the RPEO fields onl

2017-04-03 Thread Zsombor Gegesy


> On March 31, 2017, 3:31 p.m., Colm O hEigeartaigh wrote:
> > I'm wondering if it makes sense to make the default 
> > getPolicyEngineOptions() configured via "configureDelegateAdmin"? Why not 
> > just let ServiceREST do that part?

I thought about creating a constructor with all the fields, and using that in 
various places, but it seemed a bit harder to follow the logic with one string 
field, and 6 booleans in the arguments of the constructor.


- Zsombor


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


On March 31, 2017, 12:50 p.m., Zsombor Gegesy wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57987/
> ---
> 
> (Updated March 31, 2017, 12:50 p.m.)
> 
> 
> Review request for ranger.
> 
> 
> Bugs: RANGER-1478
> https://issues.apache.org/jira/browse/RANGER-1478
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> RangerPolicyEngineOptions has a lot of public fields, which is written from 
> various places from the code base, which should be avoided. That object is 
> configured from RangerConfiguration, but in the middle of the plugin 
> initialization code, which makes this a bit more complex, than it should be.
> Suggestions:
> 
> RangerConfiguration should be treated as an object, not a static facade 
> for a couple of config values
> RangerPolicyEngineOptions should get his configuration from directly the 
> RangerConfiguration, in an explicit, encapsulated way.
> 
> 
> Diffs
> -
> 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/policyengine/RangerPolicyEngineCache.java
>  5376b52 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/policyengine/RangerPolicyEngineOptions.java
>  a9027bc 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/service/RangerBasePlugin.java
>  acf8d15 
>   security-admin/src/main/java/org/apache/ranger/rest/ServiceREST.java 
> 6176319 
> 
> 
> Diff: https://reviews.apache.org/r/57987/diff/2/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Zsombor Gegesy
> 
>



Re: Review Request 58104: RangerUI: Escape of policy condition text entered in the policy form.

2017-04-03 Thread Mehul Parikh

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


Ship it!




Ship It!

- Mehul Parikh


On March 31, 2017, 11:15 a.m., Nitin Galave wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58104/
> ---
> 
> (Updated March 31, 2017, 11:15 a.m.)
> 
> 
> Review request for ranger, Gautam Borad, Madhan Neethiraj, Mehul Parikh, 
> Pradeep Agrawal, and Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-1484
> https://issues.apache.org/jira/browse/RANGER-1484
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> The text entered in policy condition UI comes back with escape characters 
> after saving the policy.
> 
> For example: 
> 1.create policy with policy condition as “tag.attributes['type']=='ccn'” .
> 2.Now open that policy in edit mode you will see policy condition 
> becomes "tag.attributes['type']=='ccn'".
> 
> Another issue is that UI displays policy conditions that don’t have any 
> value.Only the condition edit popup would list all the conditions; the policy 
> view would only list the conditions that have non-empty value.
> 
> 
> Diffs
> -
> 
>   security-admin/src/main/webapp/scripts/modules/XAOverrides.js 1e2b553 
>   security-admin/src/main/webapp/scripts/views/policies/PermissionList.js 
> 2ac494e 
> 
> 
> Diff: https://reviews.apache.org/r/58104/diff/1/
> 
> 
> Testing
> ---
> 
> Verified : Text entered in policy condition come back as it is after saving 
> policy.
> Tested with following characters : ~`!@#$%^&*()-_+={}[]:;"'<,>.?/
> 
> Verified : UI only displays policy conditions name and value which has 
> non-empty values.
> 
> 
> Thanks,
> 
> Nitin Galave
> 
>



Re: Review Request 57837: Remember filters on all tabs of Ranger Audits page

2017-04-03 Thread bhavik patel

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

(Updated April 3, 2017, 8:55 a.m.)


Review request for ranger, Ankita Sinha, Don Bosco Durai, Gautam Borad, Abhay 
Kulkarni, Madhan Neethiraj, Pradeep Agrawal, Ramesh Mani, Selvamohan Neethiraj, 
Sailaja Polavarapu, and Velmurugan Periasamy.


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


Repository: ranger


Description
---

Currently, when we apply filter for anything in Ranger Audit page for any of 
the tabs. It resets the filter on change of tab or if we move to any other page 
in Ranger.
Planning to add feature of remembering latest filters on all Tabs of Audits 
page. That will help users to stay focused on what they are looking for in 
audits tab and users will not have to apply for filters again and again to 
check audit events of a particular service.


Diffs (updated)
-

  security-admin/src/main/java/org/apache/ranger/common/SearchUtil.java 0723ee9 
  security-admin/src/main/java/org/apache/ranger/rest/AssetREST.java f0d2401 
  security-admin/src/main/java/org/apache/ranger/rest/XUserREST.java 0776021 
  security-admin/src/main/java/org/apache/ranger/solr/SolrUtil.java 85f420d 
  security-admin/src/main/webapp/scripts/modules/globalize/message/en.js 
8f7d5d9 
  security-admin/src/main/webapp/scripts/utils/XAUtils.js 7a35ce3 
  security-admin/src/main/webapp/scripts/views/reports/AuditLayout.js 8a0abb8 
  security-admin/src/main/webapp/scripts/views/reports/LoginSessionDetail.js 
6f1069d 
  security-admin/src/main/webapp/styles/xa.css 7a5ec2e 
  
security-admin/src/main/webapp/templates/common/ServiceManagerLayout_tmpl.html 
ea2f198 
  security-admin/src/main/webapp/templates/reports/AuditLayout_tmpl.html 
028fdbf 
  security-admin/src/main/webapp/templates/reports/LoginSessionDetail_tmpl.html 
ddd6e3d 
  security-admin/src/test/java/org/apache/ranger/rest/TestXUserREST.java 
c544832 


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

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


Testing
---

1. Tested multiple search is working correctly in "Audit" tab.
2. Tested search remains the same when we navigate from one tab to other.
3. Tested search is working correctly for different user role.


Thanks,

bhavik patel



[jira] [Updated] (RANGER-1471) Remember filters on all tabs of Ranger Audits page

2017-04-03 Thread bhavik patel (JIRA)

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

bhavik patel updated RANGER-1471:
-
Attachment: RANGER-1471-1.patch

> Remember filters on all tabs of Ranger Audits page
> --
>
> Key: RANGER-1471
> URL: https://issues.apache.org/jira/browse/RANGER-1471
> Project: Ranger
>  Issue Type: Improvement
>  Components: Ranger
>Affects Versions: 0.7.1
>Reporter: bhavik patel
>Assignee: bhavik patel
> Fix For: 0.7.1
>
> Attachments: RANGER-1471-1.patch, RANGER-1471.patch
>
>
> Currently, when we apply filter for anything in Ranger Audit page for any of 
> the tabs. It resets the filter on change of tab or if we move to any other 
> page in Ranger.
> Planning to add feature of remembering latest filters on all Tabs of Audits 
> page. That will help users to stay focused on what they are looking for in 
> audits tab and users will not have to apply for filters again and again to 
> check audit events of a particular service.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (RANGER-1471) Remember filters on all tabs of Ranger Audits page

2017-04-03 Thread bhavik patel (JIRA)

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

bhavik patel updated RANGER-1471:
-
Attachment: (was: 
0001-BUG-76849-Remember-filters-on-all-tabs-of-Ranger-Aud.patch)

> Remember filters on all tabs of Ranger Audits page
> --
>
> Key: RANGER-1471
> URL: https://issues.apache.org/jira/browse/RANGER-1471
> Project: Ranger
>  Issue Type: Improvement
>  Components: Ranger
>Affects Versions: 0.7.1
>Reporter: bhavik patel
>Assignee: bhavik patel
> Fix For: 0.7.1
>
> Attachments: RANGER-1471-1.patch, RANGER-1471.patch
>
>
> Currently, when we apply filter for anything in Ranger Audit page for any of 
> the tabs. It resets the filter on change of tab or if we move to any other 
> page in Ranger.
> Planning to add feature of remembering latest filters on all Tabs of Audits 
> page. That will help users to stay focused on what they are looking for in 
> audits tab and users will not have to apply for filters again and again to 
> check audit events of a particular service.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (RANGER-1471) Remember filters on all tabs of Ranger Audits page

2017-04-03 Thread bhavik patel (JIRA)

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

bhavik patel updated RANGER-1471:
-
Attachment: 0001-BUG-76849-Remember-filters-on-all-tabs-of-Ranger-Aud.patch

> Remember filters on all tabs of Ranger Audits page
> --
>
> Key: RANGER-1471
> URL: https://issues.apache.org/jira/browse/RANGER-1471
> Project: Ranger
>  Issue Type: Improvement
>  Components: Ranger
>Affects Versions: 0.7.1
>Reporter: bhavik patel
>Assignee: bhavik patel
> Fix For: 0.7.1
>
> Attachments: 
> 0001-BUG-76849-Remember-filters-on-all-tabs-of-Ranger-Aud.patch, 
> RANGER-1471.patch
>
>
> Currently, when we apply filter for anything in Ranger Audit page for any of 
> the tabs. It resets the filter on change of tab or if we move to any other 
> page in Ranger.
> Planning to add feature of remembering latest filters on all Tabs of Audits 
> page. That will help users to stay focused on what they are looking for in 
> audits tab and users will not have to apply for filters again and again to 
> check audit events of a particular service.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Created] (RANGER-1491) Automatically map group of external users to Administrator Role

2017-04-03 Thread Attila Kanto (JIRA)
Attila Kanto created RANGER-1491:


 Summary: Automatically map group of external users to 
Administrator Role
 Key: RANGER-1491
 URL: https://issues.apache.org/jira/browse/RANGER-1491
 Project: Ranger
  Issue Type: Wish
  Components: Ranger
Affects Versions: 0.6.3
Reporter: Attila Kanto


I have connected Ranger to external LDAP and users are synchronised form there 
with "User" role.
It would be a good feature to to introduce a mechanism to automatically map 
certain users (e.g. they are in a specific group) to "Administrator" role. 

Motivation:
If Knox gateway and Knox SSO are enabled for Ranger then only those users can 
authenticate and login through Knox SSO that are in the LDAP. Ranger's local 
administrator user is not in LDAP therefore it cannot authenticate and log in 
to Ranger UI through Knox SSO.






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)