date:20170710

Re: Review Request 60421: RANGER-1491 : Automatically map group of external users to Administrator Role

2017-07-10 Thread bhavik patel


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

(Updated July 11, 2017, 5:52 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-1491
https://issues.apache.org/jira/browse/RANGER-1491


Repository: ranger


Description
---

Currently when Ranger connect to external LDAP server than users are 
synchronised and they will get default as "User" role.

It would be a good feature to introduce a mechanism to automatically map 
certain users (e.g. they are in a specific group) to "Administrator" or 
"Keyadmin" role rather than setting as default "User" role.


Diffs (updated)
-

  security-admin/src/main/java/org/apache/ranger/biz/UserMgr.java 6f77832 
  security-admin/src/main/java/org/apache/ranger/biz/XUserMgr.java b973b9a 
  security-admin/src/main/java/org/apache/ranger/service/XUserService.java 
de95138 
  security-admin/src/test/java/org/apache/ranger/biz/TestUserMgr.java 5e0ca20 
  security-admin/src/test/java/org/apache/ranger/biz/TestXUserMgr.java 9846f67 
  
ugsync/src/main/java/org/apache/ranger/ldapusersync/process/LdapPolicyMgrUserGroupBuilder.java
 428ad30 
  
ugsync/src/main/java/org/apache/ranger/unixusersync/config/UserGroupSyncConfig.java
 19343b2 
  ugsync/src/main/java/org/apache/ranger/unixusersync/model/MUserInfo.java 
841bac6 
  ugsync/src/main/java/org/apache/ranger/unixusersync/model/XUserInfo.java 
7d636fd 
  unixauthservice/scripts/install.properties 13ae1e5 
  unixauthservice/scripts/setup.py bbc9226 
  unixauthservice/scripts/templates/installprop2xml.properties 1a9bf36 
  unixauthservice/scripts/templates/ranger-ugsync-template.xml 0025dc8 


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

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


Testing
---

1. Verified when ranger-admin connect to LDAP server than users are 
synchronised form there they got same role which is specified in usersync-side.
2. Verified unix authentication and usersync.


Thanks,

bhavik patel

[jira] [Created] (RANGER-1685) Utility script that will list the users with a given role

2017-07-10 Thread Fatima Amjad Khan (JIRA)

Fatima Amjad Khan created RANGER-1685:
-

 Summary: Utility script that will list the users with a given role
 Key: RANGER-1685
 URL: https://issues.apache.org/jira/browse/RANGER-1685
 Project: Ranger
  Issue Type: Bug
  Components: Ranger
Reporter: Fatima Amjad Khan
Assignee: Fatima Amjad Khan


Write a utility to display the list of users based on the given role 
1.List the users based on the role .
2.Allow Authorized users to view the list



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

[jira] [Updated] (RANGER-1678) In different places to achieve the same function using repeat codes, new issue is perhaps generated when these functions are modified.

2017-07-10 Thread peng.jianhua (JIRA)


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

peng.jianhua updated RANGER-1678:
-
Attachment: 0001-RANGER-1678-In-different-places-to-achieve-the-same-.patch

> In different places to achieve the same function using repeat codes, new 
> issue is perhaps generated when these functions are modified.
> --
>
> Key: RANGER-1678
> URL: https://issues.apache.org/jira/browse/RANGER-1678
> Project: Ranger
>  Issue Type: Bug
>  Components: plugins
>Reporter: peng.jianhua
>Assignee: peng.jianhua
>  Labels: newbie, patch
> Fix For: master
>
> Attachments: 
> 0001-RANGER-1678-In-different-places-to-achieve-the-same-.patch
>
>
> In agents-audit module, there are following two places of writing audit logs 
> to solr: 
> 1. org.apache.ranger.audit.provider.solr.SolrAuditProvider.
> 2. org.apache.ranger.audit.destination.SolrAuditDestination.
> Above classes use the same method( "MiscUtil.executePrivilegedAction") to 
> send the audit logs to solr. Codes is as following
> final UpdateResponse response = MiscUtil.executePrivilegedAction(new 
> PrivilegedExceptionAction() {
> @Override
> public UpdateResponse run() throws Exception {
> return solrClient.add(docs);
> }
>  }); 
> We should extract the common method to let our codes more cleaner and reduce 
> the possibility of new issue.



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

Re: Review Request 60696: In different places to achieve the same function using repeat codes, new issue is perhaps generated when these functions are modified.

2017-07-10 Thread pengjianhua


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

(Updated 七月 11, 2017, 2:41 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-1678
https://issues.apache.org/jira/browse/RANGER-1678


Repository: ranger


Description
---

In agents-audit module, there are following two places of writing audit logs to 
solr: 
1. org.apache.ranger.audit.provider.solr.SolrAuditProvider.
2. org.apache.ranger.audit.destination.SolrAuditDestination.
Above classes use the same method( "MiscUtil.executePrivilegedAction") to send 
the audit logs to solr. Codes is as following
final UpdateResponse response = MiscUtil.executePrivilegedAction(new 
PrivilegedExceptionAction() {
@Override
public UpdateResponse run() throws Exception {
return solrClient.add(docs);
}
 }); 

We should extract the common method to let our codes more cleaner and reduce 
the possibility of new issue.


Diffs (updated)
-

  
agents-audit/src/main/java/org/apache/ranger/audit/destination/SolrAuditDestination.java
 14ad791 
  
agents-audit/src/main/java/org/apache/ranger/audit/provider/solr/SolrAuditProvider.java
 e0c192c 
  agents-audit/src/main/java/org/apache/ranger/audit/utils/SolrAppUtil.java 
PRE-CREATION 


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

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


Testing
---


Thanks,

pengjianhua

[jira] [Updated] (RANGER-1678) In different places to achieve the same function using repeat codes, new issue is perhaps generated when these functions are modified.

2017-07-10 Thread peng.jianhua (JIRA)


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

peng.jianhua updated RANGER-1678:
-
Attachment: 0001-RANGER-1678-In-different-places-to-achieve-the-same-.patch

> In different places to achieve the same function using repeat codes, new 
> issue is perhaps generated when these functions are modified.
> --
>
> Key: RANGER-1678
> URL: https://issues.apache.org/jira/browse/RANGER-1678
> Project: Ranger
>  Issue Type: Bug
>  Components: plugins
>Reporter: peng.jianhua
>Assignee: peng.jianhua
>  Labels: newbie, patch
> Fix For: master
>
> Attachments: 
> 0001-RANGER-1678-In-different-places-to-achieve-the-same-.patch
>
>
> In agents-audit module, there are following two places of writing audit logs 
> to solr: 
> 1. org.apache.ranger.audit.provider.solr.SolrAuditProvider.
> 2. org.apache.ranger.audit.destination.SolrAuditDestination.
> Above classes use the same method( "MiscUtil.executePrivilegedAction") to 
> send the audit logs to solr. Codes is as following
> final UpdateResponse response = MiscUtil.executePrivilegedAction(new 
> PrivilegedExceptionAction() {
> @Override
> public UpdateResponse run() throws Exception {
> return solrClient.add(docs);
> }
>  }); 
> We should extract the common method to let our codes more cleaner and reduce 
> the possibility of new issue.



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

Re: Review Request 60696: In different places to achieve the same function using repeat codes, new issue is perhaps generated when these functions are modified.

2017-07-10 Thread pengjianhua


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

(Updated 七月 11, 2017, 1:52 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.


Changes
---

Colm O hEigeartaigh
thanks for your suggestion, I have modified it.


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


Repository: ranger


Description
---

In agents-audit module, there are following two places of writing audit logs to 
solr: 
1. org.apache.ranger.audit.provider.solr.SolrAuditProvider.
2. org.apache.ranger.audit.destination.SolrAuditDestination.
Above classes use the same method( "MiscUtil.executePrivilegedAction") to send 
the audit logs to solr. Codes is as following
final UpdateResponse response = MiscUtil.executePrivilegedAction(new 
PrivilegedExceptionAction() {
@Override
public UpdateResponse run() throws Exception {
return solrClient.add(docs);
}
 }); 

We should extract the common method to let our codes more cleaner and reduce 
the possibility of new issue.


Diffs (updated)
-

  
agents-audit/src/main/java/org/apache/ranger/audit/destination/SolrAuditDestination.java
 14ad791 
  
agents-audit/src/main/java/org/apache/ranger/audit/provider/solr/SolrAuditProvider.java
 e0c192c 
  agents-audit/src/main/java/org/apache/ranger/audit/utils/SolrAppUtil.java 
PRE-CREATION 


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

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


Testing
---


Thanks,

pengjianhua

[jira] [Commented] (RANGER-1671) The admin service can't audit to Solr using Basic Authentication

2017-07-10 Thread Qiang Zhang (JIRA)


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

Qiang Zhang commented on RANGER-1671:
-

Hi [~coheigea]. Solr uses kerberos to authenticate. audit_solr_user 
audit_solr_password is not invalid. They are different authentication. 
audit_solr_user audit_solr_password is basic authentication.

In RANGER-1684 we resolved this problem.


> The admin service can't audit to Solr using Basic Authentication
> 
>
> Key: RANGER-1671
> URL: https://issues.apache.org/jira/browse/RANGER-1671
> Project: Ranger
>  Issue Type: Bug
>  Components: admin
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
> Fix For: 1.0.0
>
> Attachments: 
> 0001-RANGER-1671-The-admin-service-can-t-audit-to-Solr-us.patch
>
>
> Although we have configuration items in install.properties to set a username 
> and password for Solr, these are not actually used in the admin service:
>  - audit_solr_user
>  - audit_solr_password
> This means that if Solr is configured to require basic authentication then we 
> can't audit to it.



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

[jira] [Created] (RANGER-1684) We should support solr plugin in ranger when kerberos was not opened.

2017-07-10 Thread Qiang Zhang (JIRA)

Qiang Zhang created RANGER-1684:
---

 Summary: We should support solr plugin in ranger when kerberos was 
not opened.
 Key: RANGER-1684
 URL: https://issues.apache.org/jira/browse/RANGER-1684
 Project: Ranger
  Issue Type: New Feature
  Components: plugins
Reporter: Qiang Zhang
Assignee: Qiang Zhang


We must open kerberos when using solr plugin in ranger. So the kerberos must be 
opened if user used solr plugin. Actually user hope that the kerberos was not 
opened when they used other plugins. We should support solr plugin in ranger 
when kerberos was not opened.



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

[jira] [Commented] (RANGER-1502) Solr shutdown does not cause the audit log file to be flushed and closed.

2017-07-10 Thread Yan (JIRA)


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

Yan commented on RANGER-1502:
-

It's Solr 6.3. But can't confirm that is Solr-only because each Hadoop 
component's shutdown mechanism is probably different. 

> Solr shutdown does not cause the audit log file to be flushed and closed.
> -
>
> Key: RANGER-1502
> URL: https://issues.apache.org/jira/browse/RANGER-1502
> Project: Ranger
>  Issue Type: Bug
>  Components: audit, plugins
>Affects Versions: 0.7.0
>Reporter: Yan
>Assignee: Yan
> Fix For: 1.0.0
>
> Attachments: 
> 0001-RANGER-1502-Solr-shutdown-does-not-cause-the-audit-l.patch
>
>
> The current audit stream close mechanism uses a Java shutdown hook registered 
> with Hadoop's ShutdownHookManager. Solr shutdown, however, somehow does not 
> cause the shutdown hook to be invoked, potentially resulting lost audit logs. 
> We are experiencing lost logs toward HDFS audit destination.



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

[jira] [Updated] (RANGER-1502) Solr shutdown does not cause the audit log file to be flushed and closed.

2017-07-10 Thread Velmurugan Periasamy (JIRA)


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

Velmurugan Periasamy updated RANGER-1502:
-
Fix Version/s: (was: master)
   1.0.0

> Solr shutdown does not cause the audit log file to be flushed and closed.
> -
>
> Key: RANGER-1502
> URL: https://issues.apache.org/jira/browse/RANGER-1502
> Project: Ranger
>  Issue Type: Bug
>  Components: audit, plugins
>Affects Versions: 0.7.0
>Reporter: Yan
>Assignee: Yan
> Fix For: 1.0.0
>
> Attachments: 
> 0001-RANGER-1502-Solr-shutdown-does-not-cause-the-audit-l.patch
>
>
> The current audit stream close mechanism uses a Java shutdown hook registered 
> with Hadoop's ShutdownHookManager. Solr shutdown, however, somehow does not 
> cause the shutdown hook to be invoked, potentially resulting lost audit logs. 
> We are experiencing lost logs toward HDFS audit destination.



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

[jira] [Commented] (RANGER-1502) Solr shutdown does not cause the audit log file to be flushed and closed.

2017-07-10 Thread Velmurugan Periasamy (JIRA)


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

Velmurugan Periasamy commented on RANGER-1502:
--

[~yzhou2001] - can you please confirm this scenario is specific to Ranger Solr 
plugin auditing to HDFS? What Solr version is being used? 

CC [~rmani]/[~sneethiraj] for review.

> Solr shutdown does not cause the audit log file to be flushed and closed.
> -
>
> Key: RANGER-1502
> URL: https://issues.apache.org/jira/browse/RANGER-1502
> Project: Ranger
>  Issue Type: Bug
>  Components: audit, plugins
>Affects Versions: 0.7.0
>Reporter: Yan
>Assignee: Yan
> Fix For: master
>
> Attachments: 
> 0001-RANGER-1502-Solr-shutdown-does-not-cause-the-audit-l.patch
>
>
> The current audit stream close mechanism uses a Java shutdown hook registered 
> with Hadoop's ShutdownHookManager. Solr shutdown, however, somehow does not 
> cause the shutdown hook to be invoked, potentially resulting lost audit logs. 
> We are experiencing lost logs toward HDFS audit destination.



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

Re: Review Request 60746: RANGER-1683 - Fix the failing Kerberos tests on Jenkins

2017-07-10 Thread Velmurugan Periasamy


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


Ship it!




Ship It!

- Velmurugan Periasamy


On July 10, 2017, 2:36 p.m., Colm O hEigeartaigh wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/60746/
> ---
> 
> (Updated July 10, 2017, 2:36 p.m.)
> 
> 
> Review request for ranger.
> 
> 
> Bugs: RANGER-1683
> https://issues.apache.org/jira/browse/RANGER-1683
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> Fix the failing Kerberos tests on Jenkins
> 
> 
> Diffs
> -
> 
>   
> plugin-kafka/src/test/java/org/apache/ranger/authorization/kafka/authorizer/KafkaRangerAuthorizerGSSTest.java
>  d072a6f5 
>   pom.xml a4764ea4 
> 
> 
> Diff: https://reviews.apache.org/r/60746/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Colm O hEigeartaigh
> 
>

[jira] [Resolved] (RANGER-1675) Policy conditions not enabled by default for Hive policies

2017-07-10 Thread suja s (JIRA)


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

suja s resolved RANGER-1675.

Resolution: Not A Bug

> Policy conditions not enabled by default for Hive policies
> --
>
> Key: RANGER-1675
> URL: https://issues.apache.org/jira/browse/RANGER-1675
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Affects Versions: 0.7.2
>Reporter: suja s
>
> Policy conditions (like expiry_date) are not visible by default on Ranger UI 
> for hive policy creation



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

[jira] [Created] (RANGER-1683) Fix the failing Kerberos tests on Jenkins

2017-07-10 Thread Colm O hEigeartaigh (JIRA)

Colm O hEigeartaigh created RANGER-1683:
---

 Summary: Fix the failing Kerberos tests on Jenkins
 Key: RANGER-1683
 URL: https://issues.apache.org/jira/browse/RANGER-1683
 Project: Ranger
  Issue Type: Bug
  Components: plugins
Reporter: Colm O hEigeartaigh
Assignee: Colm O hEigeartaigh
Priority: Minor
 Fix For: 1.0.0


The Kafka kerberos tests are failing on Jenkins.



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

[jira] [Commented] (RANGER-1666) Ranger UI should consider "recursiveSupported" attribute value at each resource level to Store the Policy

2017-07-10 Thread Nitin Galave (JIRA)


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

Nitin Galave commented on RANGER-1666:
--

Committed to [master| 
https://github.com/apache/ranger/commit/b3e4fdb3aa450cbdb93c0f8246bc09ce6d5f4802]
 and 
 [ranger-0.7| 
https://github.com/apache/ranger/commit/496fc23b1cc1f829c00e7ec3f3ab594d83317e2a]
 branch.


> Ranger UI should consider "recursiveSupported" attribute value at each 
> resource level to Store the Policy
> -
>
> Key: RANGER-1666
> URL: https://issues.apache.org/jira/browse/RANGER-1666
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Affects Versions: 1.0.0, master
>Reporter: Ramesh Mani
>Assignee: Nitin Galave
>Priority: Critical
> Fix For: 1.0.0
>
> Attachments: RANGER-1666.patch
>
>
> Ranger UI should consider "recursiveSupported" value at each resource level 
> to Store the Policy. Currently, if there is resource matcher with 
> "recursiveSupported" = true and others resource has false, UI call the 
> createPolicy REST with "true" for all resources in the policy which resulted 
> in the failure of the policy saving.



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

[jira] [Commented] (RANGER-1671) The admin service can't audit to Solr using Basic Authentication

2017-07-10 Thread Colm O hEigeartaigh (JIRA)


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

Colm O hEigeartaigh commented on RANGER-1671:
-

Hi [~zhangqiang2],

Could you expand a bit on what the problem is? If you are using Solr with 
Kerberos then why would you configure audit_solr_user audit_solr_password?

> The admin service can't audit to Solr using Basic Authentication
> 
>
> Key: RANGER-1671
> URL: https://issues.apache.org/jira/browse/RANGER-1671
> Project: Ranger
>  Issue Type: Bug
>  Components: admin
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
> Fix For: 1.0.0
>
> Attachments: 
> 0001-RANGER-1671-The-admin-service-can-t-audit-to-Solr-us.patch
>
>
> Although we have configuration items in install.properties to set a username 
> and password for Solr, these are not actually used in the admin service:
>  - audit_solr_user
>  - audit_solr_password
> This means that if Solr is configured to require basic authentication then we 
> can't audit to it.



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

Re: Review Request 60696: In different places to achieve the same function using repeat codes, new issue is perhaps generated when these functions are modified.

2017-07-10 Thread Colm O hEigeartaigh


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



> final Collection docs = new ArrayList();
> docs.add(document);

Better to write this as:

final Collection docs = Collections.singletonList(document);

- Colm O hEigeartaigh


On July 7, 2017, 1:46 a.m., pengjianhua wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/60696/
> ---
> 
> (Updated July 7, 2017, 1:46 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-1678
> https://issues.apache.org/jira/browse/RANGER-1678
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> In agents-audit module, there are following two places of writing audit logs 
> to solr: 
> 1. org.apache.ranger.audit.provider.solr.SolrAuditProvider.
> 2. org.apache.ranger.audit.destination.SolrAuditDestination.
> Above classes use the same method( "MiscUtil.executePrivilegedAction") to 
> send the audit logs to solr. Codes is as following
> final UpdateResponse response = MiscUtil.executePrivilegedAction(new 
> PrivilegedExceptionAction() {
> @Override
> public UpdateResponse run() throws Exception {
> return solrClient.add(docs);
> }
>  }); 
> 
> We should extract the common method to let our codes more cleaner and reduce 
> the possibility of new issue.
> 
> 
> Diffs
> -
> 
>   
> agents-audit/src/main/java/org/apache/ranger/audit/destination/SolrAuditDestination.java
>  14ad791 
>   
> agents-audit/src/main/java/org/apache/ranger/audit/provider/solr/SolrAuditProvider.java
>  e0c192c 
>   agents-audit/src/main/java/org/apache/ranger/audit/utils/SolrAppUtil.java 
> PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/60696/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> pengjianhua
> 
>

[jira] [Commented] (RANGER-1639) Ranger KMS should validate key name before importing into DB

2017-07-10 Thread Ankita Sinha (JIRA)


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

Ankita Sinha commented on RANGER-1639:
--

Committed to Master : 
https://github.com/apache/ranger/commit/b47fe34779beb4be49015ca2f3dfecae7413135a
Committed to ranger-0.7 : 
https://github.com/apache/ranger/commit/50ef5f0fd94f29debb81bffb15d2aefe6dad4381

> Ranger KMS should validate key name before importing into DB
> 
>
> Key: RANGER-1639
> URL: https://issues.apache.org/jira/browse/RANGER-1639
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Affects Versions: 1.0.0
>Reporter: Ankita Sinha
>Assignee: Ankita Sinha
> Fix For: 1.0.0
>
> Attachments: RANGER-1639_07.patch, RANGER-1639.patch
>
>
> *Actual* : 
> Ranger KMS does not validate key name before importing into DB. So the 
> imported key can have special characters in Key name.
> *Expected* :
> Ranger KMS should validate key name before importing into DB.



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

Re: Review Request 60385: Ranger KMS should validate key name before importing into DB

2017-07-10 Thread Mehul Parikh


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


Ship it!




Ship It!

- Mehul Parikh


On June 23, 2017, 6:19 a.m., Ankita Sinha wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/60385/
> ---
> 
> (Updated June 23, 2017, 6:19 a.m.)
> 
> 
> Review request for ranger, Don Bosco Durai, Gautam Borad, Abhay Kulkarni, 
> Madhan Neethiraj, Pradeep Agrawal, Ramesh Mani, Selvamohan Neethiraj, Sailaja 
> Polavarapu, and Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-1639
> https://issues.apache.org/jira/browse/RANGER-1639
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> Actual :
> Ranger KMS does not validate key name before importing into DB. So the 
> imported key can have special characters in Key name.
> 
> Expected :
> Ranger KMS should validate key name before importing into DB.
> 
> 
> Diffs
> -
> 
>   kms/src/main/java/org/apache/hadoop/crypto/key/RangerKeyStore.java a001c08 
>   kms/src/test/java/org/apache/hadoop/crypto/key/kms/TestRangerKeyStore.java 
> PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/60385/diff/1/
> 
> 
> Testing
> ---
> 
> Below steps were followed to test this scenario
> 
> 1. Installed Hadoop KMS
> 2. Created encryption keys with combination of special characters, alphabets 
> and numbers
> 3. Installed Ranger KMS
> 4. imported hadoop key jceks to Ranger KMS (Validation was successful)
> 
> 
> Thanks,
> 
> Ankita Sinha
> 
>

[jira] [Created] (RANGER-1682) Clicking on export service after session timeout gets stuck indefinitely

2017-07-10 Thread Aditya Sirna (JIRA)

Aditya Sirna created RANGER-1682:


 Summary: Clicking on export service after session timeout gets 
stuck indefinitely
 Key: RANGER-1682
 URL: https://issues.apache.org/jira/browse/RANGER-1682
 Project: Ranger
  Issue Type: Bug
  Components: Ranger
Reporter: Aditya Sirna






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

[jira] [Updated] (RANGER-1680) Hive user can't read from HDFS when trying to "LOAD DATA INPATH" in spite of HDFS access is granted by Ranger

2017-07-10 Thread Andrei Saniuk (JIRA)


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

Andrei Saniuk updated RANGER-1680:
--
Summary: Hive user can't read from HDFS when trying to "LOAD DATA INPATH" 
in spite of HDFS access is granted by Ranger   (was: Hive user can't read from 
HDFS when trying to "LOAD DATA INPATH" inspite of HDFS access is granted by 
Ranger)

> Hive user can't read from HDFS when trying to "LOAD DATA INPATH" in spite of 
> HDFS access is granted by Ranger 
> --
>
> Key: RANGER-1680
> URL: https://issues.apache.org/jira/browse/RANGER-1680
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
> Environment: HDP26 cluster protected with ranger
>Reporter: Andrei Saniuk
>
> I've enabled hive.server2.enable.doAs=false and granted all permissions for 
> source file path in HDFS to user 'hive'. When I'm trying to load data into 
> internal table, an error occures
> {code}INFO : Loading data to table tablename from 
> hdfs://myclusterhdfs:8020/user/test/ ERROR : Failed with exception 
> org.apache.hadoop.security.AccessControlException: Permission denied. 
> user=hive is not the owner of inode=sometext.txt at 
> org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.checkOwner(FSPermissionChecker.java:250)
>  at 
> org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.checkPermission(FSPermissionChecker.java:227)
>  at 
> org.apache.ranger.authorization.hadoop.RangerHdfsAuthorizer$RangerAccessControlEnforcer.checkPermission(RangerHd
>  fsAuthorizer.java:307){code}
> Inspite of this, data is loaded into table. The file is copied into 
> /apps/hive/mytable, but its owner is not user 'hive'



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

[jira] [Comment Edited] (RANGER-1681) Now ranger's kerberos configuration item relies directly on the configuration of the hadoop component. When the HDFS opens other functions such as HA, the test co

2017-07-10 Thread peng.jianhua (JIRA)


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

peng.jianhua edited comment on RANGER-1681 at 7/10/17 7:44 AM:
---

Hi [~vperiasamy], you are right. It is one of the ways to solve this problem. 
There are following defects using this way to resolve the problem.
1. The user must manually link these files. For user, it increases the 
difficulty using ranger.
2. Actually some files are not needed. Excessive reliance on irrelevant files 
can cause potential problems. User will be very difficult to locate and 
analysis it once problem occurs.

It is estimated that you have also been troubled by this problem.

However the issue resolved above defects.


was (Author: peng.jianhua):
Hi [~vperiasamy], you are right. It is one of the ways to solve this problem. 
There are following defects using this way to resolve the problem.
1. The user must manually link these files. For user, it increases the 
difficulty using ranger.
2. Actually some files are not needed. Excessive reliance on irrelevant files 
can cause potential problems. User will be very difficult to locate and 
analysis it once problem occurs.

However the issue resolved above defects.

> Now ranger's kerberos configuration item relies directly on the configuration 
> of the hadoop component. When the HDFS opens other functions such as HA, the 
> test connection of hbase will fail
> -
>
> Key: RANGER-1681
> URL: https://issues.apache.org/jira/browse/RANGER-1681
> Project: Ranger
>  Issue Type: Bug
>  Components: admin, Ranger
>Reporter: peng.jianhua
>Assignee: peng.jianhua
>  Labels: patch
> Attachments: 0001-RANGER-1681.patch
>
>
> Currently, ragner-admin opens kerberos switch:
> 1.Configure the ranger-admin install.properties file:
> {code}
>   hadoop_conf=/etc/hadoop/conf
> {code}
> 2.Read the configuration items in the hadoop configuration file core-site.xml:
> {code}
>   
>   hadoop.security.authentication
>   kerberos
>   
> {code}
> However, when ranger-admin opened kerberos,and the HDFS opens the HA function,
> hbase-plugin service tests connection failure ,this is because ranger and 
> hadoop shared the same kerberos switch configuration file which caused a 
> series of unnecessary dependencies
> {code}
> 2017-06-22 08:14:44,518 INFO 
> org.apache.ranger.services.hbase.client.HBaseClient: HBase connection has 
> [zookeeper.znode.parent] with value [/hbase]
> 2017-06-22 08:14:44,520 INFO org.apache.ranger.plugin.client.BaseClient: Init 
> Login: security not enabled, using username
> 2017-06-22 08:14:44,581 INFO 
> org.apache.ranger.services.hbase.client.HBaseClient: getHBaseStatus: creating 
> default Hbase configuration
> 2017-06-22 08:14:44,582 INFO 
> org.apache.ranger.services.hbase.client.HBaseClient: getHBaseStatus: setting 
> config values from client
> 2017-06-22 08:14:44,582 INFO 
> org.apache.ranger.services.hbase.client.HBaseClient: getHBaseStatus: checking 
> HbaseAvailability with the new config
> 2017-06-22 08:14:44,923 WARN org.apache.zookeeper.ClientCnxn: SASL 
> configuration failed: javax.security.auth.login.LoginException: No JAAS 
> configuration section named 'Client' was found in specified JAAS 
> configuration file: '/dev/null'. Will continue connection to Zookeeper server 
> without SASL authentication, if Zookeeper server allows it.
> 2017-06-22 08:14:45,033 ERROR 
> org.apache.ranger.services.hbase.client.HBaseClient: getHBaseStatus: Unable 
> to check availability of Hbase environment [hbasedev].java.io.IOException: 
> java.lang.reflect.InvocationTargetException
> 2017-06-22 08:14:45,033 ERROR 
> org.apache.ranger.services.hbase.client.HBaseClient: <== 
> HBaseClient.testConnection(): Unable to retrieve any databases using given 
> parameters
> org.apache.ranger.plugin.client.HadoopException: getHBaseStatus: Unable to 
> check availability of Hbase environment [hbasedev].
>   at 
> org.apache.ranger.services.hbase.client.HBaseClient$1.run(HBaseClient.java:175)
>   at 
> org.apache.ranger.services.hbase.client.HBaseClient$1.run(HBaseClient.java:128)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at javax.security.auth.Subject.doAs(Subject.java:356)
>   at 
> org.apache.ranger.services.hbase.client.HBaseClient.getHBaseStatus(HBaseClient.java:128)
>   at 
> org.apache.ranger.services.hbase.client.HBaseClient.connectionTest(HBaseClient.java:100)
>   at 
> org.apache.ranger.services.hbase.client.HBaseResourceMgr.connectionTest(HBaseResourceMgr.java:47)
>   at 
>

[jira] [Commented] (RANGER-1681) Now ranger's kerberos configuration item relies directly on the configuration of the hadoop component. When the HDFS opens other functions such as HA, the test connect

2017-07-10 Thread peng.jianhua (JIRA)


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

peng.jianhua commented on RANGER-1681:
--

Hi [~vperiasamy], you are right. It is one of the ways to solve this problem. 
There are following defects using this way to resolve the problem.
1. The user must manually link these files. For user, it increases the 
difficulty using ranger.
2. Actually some files are not needed. Excessive reliance on irrelevant files 
can cause potential problems. User will be very difficult to locate and 
analysis it once problem occurs.

However the issue resolved above defects.

> Now ranger's kerberos configuration item relies directly on the configuration 
> of the hadoop component. When the HDFS opens other functions such as HA, the 
> test connection of hbase will fail
> -
>
> Key: RANGER-1681
> URL: https://issues.apache.org/jira/browse/RANGER-1681
> Project: Ranger
>  Issue Type: Bug
>  Components: admin, Ranger
>Reporter: peng.jianhua
>Assignee: peng.jianhua
>  Labels: patch
> Attachments: 0001-RANGER-1681.patch
>
>
> Currently, ragner-admin opens kerberos switch:
> 1.Configure the ranger-admin install.properties file:
> {code}
>   hadoop_conf=/etc/hadoop/conf
> {code}
> 2.Read the configuration items in the hadoop configuration file core-site.xml:
> {code}
>   
>   hadoop.security.authentication
>   kerberos
>   
> {code}
> However, when ranger-admin opened kerberos,and the HDFS opens the HA function,
> hbase-plugin service tests connection failure ,this is because ranger and 
> hadoop shared the same kerberos switch configuration file which caused a 
> series of unnecessary dependencies
> {code}
> 2017-06-22 08:14:44,518 INFO 
> org.apache.ranger.services.hbase.client.HBaseClient: HBase connection has 
> [zookeeper.znode.parent] with value [/hbase]
> 2017-06-22 08:14:44,520 INFO org.apache.ranger.plugin.client.BaseClient: Init 
> Login: security not enabled, using username
> 2017-06-22 08:14:44,581 INFO 
> org.apache.ranger.services.hbase.client.HBaseClient: getHBaseStatus: creating 
> default Hbase configuration
> 2017-06-22 08:14:44,582 INFO 
> org.apache.ranger.services.hbase.client.HBaseClient: getHBaseStatus: setting 
> config values from client
> 2017-06-22 08:14:44,582 INFO 
> org.apache.ranger.services.hbase.client.HBaseClient: getHBaseStatus: checking 
> HbaseAvailability with the new config
> 2017-06-22 08:14:44,923 WARN org.apache.zookeeper.ClientCnxn: SASL 
> configuration failed: javax.security.auth.login.LoginException: No JAAS 
> configuration section named 'Client' was found in specified JAAS 
> configuration file: '/dev/null'. Will continue connection to Zookeeper server 
> without SASL authentication, if Zookeeper server allows it.
> 2017-06-22 08:14:45,033 ERROR 
> org.apache.ranger.services.hbase.client.HBaseClient: getHBaseStatus: Unable 
> to check availability of Hbase environment [hbasedev].java.io.IOException: 
> java.lang.reflect.InvocationTargetException
> 2017-06-22 08:14:45,033 ERROR 
> org.apache.ranger.services.hbase.client.HBaseClient: <== 
> HBaseClient.testConnection(): Unable to retrieve any databases using given 
> parameters
> org.apache.ranger.plugin.client.HadoopException: getHBaseStatus: Unable to 
> check availability of Hbase environment [hbasedev].
>   at 
> org.apache.ranger.services.hbase.client.HBaseClient$1.run(HBaseClient.java:175)
>   at 
> org.apache.ranger.services.hbase.client.HBaseClient$1.run(HBaseClient.java:128)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at javax.security.auth.Subject.doAs(Subject.java:356)
>   at 
> org.apache.ranger.services.hbase.client.HBaseClient.getHBaseStatus(HBaseClient.java:128)
>   at 
> org.apache.ranger.services.hbase.client.HBaseClient.connectionTest(HBaseClient.java:100)
>   at 
> org.apache.ranger.services.hbase.client.HBaseResourceMgr.connectionTest(HBaseResourceMgr.java:47)
>   at 
> org.apache.ranger.services.hbase.RangerServiceHBase.validateConfig(RangerServiceHBase.java:59)
>   at 
> org.apache.ranger.biz.ServiceMgr$ValidateCallable.actualCall(ServiceMgr.java:560)
>   at 
> org.apache.ranger.biz.ServiceMgr$ValidateCallable.actualCall(ServiceMgr.java:547)
>   at 
> org.apache.ranger.biz.ServiceMgr$TimedCallable.call(ServiceMgr.java:508)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:262)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>

Review Request 60733: RANGER-1681:Now ranger's kerberos configuration item relies directly on the configuration of the hadoop component. When the HDFS opens other functions such as HA, the test connec

2017-07-10 Thread pengjianhua


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

Review request for ranger, Don Bosco Durai, Colm O hEigeartaigh, Ramesh Mani, 
Selvamohan Neethiraj, Velmurugan Periasamy, and Qiang Zhang.


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


Repository: ranger


Description
---

Currently, ragner-admin opens kerberos switch:
1.Configure the ranger-admin install.properties file:
hadoop_conf=/etc/hadoop/conf
2.Read the configuration items in the hadoop configuration file core-site.xml:

hadoop.security.authentication
kerberos

However, when ranger-admin opened kerberos,and the HDFS opens the HA function,
hbase-plugin service tests connection failure ,this is because ranger and 
hadoop shared the same kerberos switch configuration file which caused a series 
of unnecessary dependencies

2017-06-22 08:14:44,518 INFO 
org.apache.ranger.services.hbase.client.HBaseClient: HBase connection has 
[zookeeper.znode.parent] with value [/hbase]
2017-06-22 08:14:44,520 INFO org.apache.ranger.plugin.client.BaseClient: Init 
Login: security not enabled, using username
2017-06-22 08:14:44,581 INFO 
org.apache.ranger.services.hbase.client.HBaseClient: getHBaseStatus: creating 
default Hbase configuration
2017-06-22 08:14:44,582 INFO 
org.apache.ranger.services.hbase.client.HBaseClient: getHBaseStatus: setting 
config values from client
2017-06-22 08:14:44,582 INFO 
org.apache.ranger.services.hbase.client.HBaseClient: getHBaseStatus: checking 
HbaseAvailability with the new config
2017-06-22 08:14:44,923 WARN org.apache.zookeeper.ClientCnxn: SASL 
configuration failed: javax.security.auth.login.LoginException: No JAAS 
configuration section named 'Client' was found in specified JAAS configuration 
file: '/dev/null'. Will continue connection to Zookeeper server without SASL 
authentication, if Zookeeper server allows it.
2017-06-22 08:14:45,033 ERROR 
org.apache.ranger.services.hbase.client.HBaseClient: getHBaseStatus: Unable to 
check availability of Hbase environment [hbasedev].java.io.IOException: 
java.lang.reflect.InvocationTargetException
2017-06-22 08:14:45,033 ERROR 
org.apache.ranger.services.hbase.client.HBaseClient: <== 
HBaseClient.testConnection(): Unable to retrieve any databases using given 
parameters
org.apache.ranger.plugin.client.HadoopException: getHBaseStatus: Unable to 
check availability of Hbase environment [hbasedev].
at 
org.apache.ranger.services.hbase.client.HBaseClient$1.run(HBaseClient.java:175)
at 
org.apache.ranger.services.hbase.client.HBaseClient$1.run(HBaseClient.java:128)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at 
org.apache.ranger.services.hbase.client.HBaseClient.getHBaseStatus(HBaseClient.java:128)
at 
org.apache.ranger.services.hbase.client.HBaseClient.connectionTest(HBaseClient.java:100)
at 
org.apache.ranger.services.hbase.client.HBaseResourceMgr.connectionTest(HBaseResourceMgr.java:47)
at 
org.apache.ranger.services.hbase.RangerServiceHBase.validateConfig(RangerServiceHBase.java:59)
at 
org.apache.ranger.biz.ServiceMgr$ValidateCallable.actualCall(ServiceMgr.java:560)
at 
org.apache.ranger.biz.ServiceMgr$ValidateCallable.actualCall(ServiceMgr.java:547)
at 
org.apache.ranger.biz.ServiceMgr$TimedCallable.call(ServiceMgr.java:508)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.io.IOException: java.lang.reflect.InvocationTargetException
at 
org.apache.hadoop.hbase.client.ConnectionFactory.createConnection(ConnectionFactory.java:240)
at 
org.apache.hadoop.hbase.client.ConnectionFactory.createConnection(ConnectionFactory.java:218)
at 
org.apache.hadoop.hbase.client.ConnectionFactory.createConnection(ConnectionFactory.java:119)
at 
org.apache.hadoop.hbase.client.HBaseAdmin.checkHBaseAvailable(HBaseAdmin.java:2916)
at 
org.apache.ranger.services.hbase.client.HBaseClient$1.run(HBaseClient.java:138)
... 14 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
at

[jira] [Commented] (RANGER-1681) Now ranger's kerberos configuration item relies directly on the configuration of the hadoop component. When the HDFS opens other functions such as HA, the test connect

2017-07-10 Thread Velmurugan Periasamy (JIRA)


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

Velmurugan Periasamy commented on RANGER-1681:
--

[~peng.jianhua] - can you explain the issue here? If you create a symlink to 
core-site.xml, hdfs-site.xml, hbase-site.xml under the ranger conf folder, HA 
configuration should work fine. 

> Now ranger's kerberos configuration item relies directly on the configuration 
> of the hadoop component. When the HDFS opens other functions such as HA, the 
> test connection of hbase will fail
> -
>
> Key: RANGER-1681
> URL: https://issues.apache.org/jira/browse/RANGER-1681
> Project: Ranger
>  Issue Type: Bug
>  Components: admin, Ranger
>Reporter: peng.jianhua
>Assignee: peng.jianhua
>  Labels: patch
> Attachments: 0001-RANGER-1681.patch
>
>
> Currently, ragner-admin opens kerberos switch:
> 1.Configure the ranger-admin install.properties file:
> {code}
>   hadoop_conf=/etc/hadoop/conf
> {code}
> 2.Read the configuration items in the hadoop configuration file core-site.xml:
> {code}
>   
>   hadoop.security.authentication
>   kerberos
>   
> {code}
> However, when ranger-admin opened kerberos,and the HDFS opens the HA function,
> hbase-plugin service tests connection failure ,this is because ranger and 
> hadoop shared the same kerberos switch configuration file which caused a 
> series of unnecessary dependencies
> {code}
> 2017-06-22 08:14:44,518 INFO 
> org.apache.ranger.services.hbase.client.HBaseClient: HBase connection has 
> [zookeeper.znode.parent] with value [/hbase]
> 2017-06-22 08:14:44,520 INFO org.apache.ranger.plugin.client.BaseClient: Init 
> Login: security not enabled, using username
> 2017-06-22 08:14:44,581 INFO 
> org.apache.ranger.services.hbase.client.HBaseClient: getHBaseStatus: creating 
> default Hbase configuration
> 2017-06-22 08:14:44,582 INFO 
> org.apache.ranger.services.hbase.client.HBaseClient: getHBaseStatus: setting 
> config values from client
> 2017-06-22 08:14:44,582 INFO 
> org.apache.ranger.services.hbase.client.HBaseClient: getHBaseStatus: checking 
> HbaseAvailability with the new config
> 2017-06-22 08:14:44,923 WARN org.apache.zookeeper.ClientCnxn: SASL 
> configuration failed: javax.security.auth.login.LoginException: No JAAS 
> configuration section named 'Client' was found in specified JAAS 
> configuration file: '/dev/null'. Will continue connection to Zookeeper server 
> without SASL authentication, if Zookeeper server allows it.
> 2017-06-22 08:14:45,033 ERROR 
> org.apache.ranger.services.hbase.client.HBaseClient: getHBaseStatus: Unable 
> to check availability of Hbase environment [hbasedev].java.io.IOException: 
> java.lang.reflect.InvocationTargetException
> 2017-06-22 08:14:45,033 ERROR 
> org.apache.ranger.services.hbase.client.HBaseClient: <== 
> HBaseClient.testConnection(): Unable to retrieve any databases using given 
> parameters
> org.apache.ranger.plugin.client.HadoopException: getHBaseStatus: Unable to 
> check availability of Hbase environment [hbasedev].
>   at 
> org.apache.ranger.services.hbase.client.HBaseClient$1.run(HBaseClient.java:175)
>   at 
> org.apache.ranger.services.hbase.client.HBaseClient$1.run(HBaseClient.java:128)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at javax.security.auth.Subject.doAs(Subject.java:356)
>   at 
> org.apache.ranger.services.hbase.client.HBaseClient.getHBaseStatus(HBaseClient.java:128)
>   at 
> org.apache.ranger.services.hbase.client.HBaseClient.connectionTest(HBaseClient.java:100)
>   at 
> org.apache.ranger.services.hbase.client.HBaseResourceMgr.connectionTest(HBaseResourceMgr.java:47)
>   at 
> org.apache.ranger.services.hbase.RangerServiceHBase.validateConfig(RangerServiceHBase.java:59)
>   at 
> org.apache.ranger.biz.ServiceMgr$ValidateCallable.actualCall(ServiceMgr.java:560)
>   at 
> org.apache.ranger.biz.ServiceMgr$ValidateCallable.actualCall(ServiceMgr.java:547)
>   at 
> org.apache.ranger.biz.ServiceMgr$TimedCallable.call(ServiceMgr.java:508)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:262)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>   at java.lang.Thread.run(Thread.java:745)
> Caused by: java.io.IOException: java.lang.reflect.InvocationTargetException
>   at 
> org.apache.hadoop.hbase.client.ConnectionFactory.createConnection(ConnectionFactory.java:240)
>   at 
>

Re: Review Request 60733: RANGER-1681:Now ranger's kerberos configuration item relies directly on the configuration of the hadoop component. When the HDFS opens other functions such as HA, the test co

2017-07-10 Thread pengjianhua


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

(Updated 七月 10, 2017, 7:02 a.m.)


Review request for ranger, Don Bosco Durai, Colm O hEigeartaigh, Ramesh Mani, 
Selvamohan Neethiraj, Velmurugan Periasamy, and Qiang Zhang.


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


Repository: ranger


Description
---

Currently, ragner-admin opens kerberos switch:
1.Configure the ranger-admin install.properties file:
hadoop_conf=/etc/hadoop/conf
2.Read the configuration items in the hadoop configuration file core-site.xml:

hadoop.security.authentication
kerberos

However, when ranger-admin opened kerberos,and the HDFS opens the HA function,
hbase-plugin service tests connection failure ,this is because ranger and 
hadoop shared the same kerberos switch configuration file which caused a series 
of unnecessary dependencies

2017-06-22 08:14:44,518 INFO 
org.apache.ranger.services.hbase.client.HBaseClient: HBase connection has 
[zookeeper.znode.parent] with value [/hbase]
2017-06-22 08:14:44,520 INFO org.apache.ranger.plugin.client.BaseClient: Init 
Login: security not enabled, using username
2017-06-22 08:14:44,581 INFO 
org.apache.ranger.services.hbase.client.HBaseClient: getHBaseStatus: creating 
default Hbase configuration
2017-06-22 08:14:44,582 INFO 
org.apache.ranger.services.hbase.client.HBaseClient: getHBaseStatus: setting 
config values from client
2017-06-22 08:14:44,582 INFO 
org.apache.ranger.services.hbase.client.HBaseClient: getHBaseStatus: checking 
HbaseAvailability with the new config
2017-06-22 08:14:44,923 WARN org.apache.zookeeper.ClientCnxn: SASL 
configuration failed: javax.security.auth.login.LoginException: No JAAS 
configuration section named 'Client' was found in specified JAAS configuration 
file: '/dev/null'. Will continue connection to Zookeeper server without SASL 
authentication, if Zookeeper server allows it.
2017-06-22 08:14:45,033 ERROR 
org.apache.ranger.services.hbase.client.HBaseClient: getHBaseStatus: Unable to 
check availability of Hbase environment [hbasedev].java.io.IOException: 
java.lang.reflect.InvocationTargetException
2017-06-22 08:14:45,033 ERROR 
org.apache.ranger.services.hbase.client.HBaseClient: <== 
HBaseClient.testConnection(): Unable to retrieve any databases using given 
parameters
org.apache.ranger.plugin.client.HadoopException: getHBaseStatus: Unable to 
check availability of Hbase environment [hbasedev].
at 
org.apache.ranger.services.hbase.client.HBaseClient$1.run(HBaseClient.java:175)
at 
org.apache.ranger.services.hbase.client.HBaseClient$1.run(HBaseClient.java:128)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at 
org.apache.ranger.services.hbase.client.HBaseClient.getHBaseStatus(HBaseClient.java:128)
at 
org.apache.ranger.services.hbase.client.HBaseClient.connectionTest(HBaseClient.java:100)
at 
org.apache.ranger.services.hbase.client.HBaseResourceMgr.connectionTest(HBaseResourceMgr.java:47)
at 
org.apache.ranger.services.hbase.RangerServiceHBase.validateConfig(RangerServiceHBase.java:59)
at 
org.apache.ranger.biz.ServiceMgr$ValidateCallable.actualCall(ServiceMgr.java:560)
at 
org.apache.ranger.biz.ServiceMgr$ValidateCallable.actualCall(ServiceMgr.java:547)
at 
org.apache.ranger.biz.ServiceMgr$TimedCallable.call(ServiceMgr.java:508)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.io.IOException: java.lang.reflect.InvocationTargetException
at 
org.apache.hadoop.hbase.client.ConnectionFactory.createConnection(ConnectionFactory.java:240)
at 
org.apache.hadoop.hbase.client.ConnectionFactory.createConnection(ConnectionFactory.java:218)
at 
org.apache.hadoop.hbase.client.ConnectionFactory.createConnection(ConnectionFactory.java:119)
at 
org.apache.hadoop.hbase.client.HBaseAdmin.checkHBaseAvailable(HBaseAdmin.java:2916)
at 
org.apache.ranger.services.hbase.client.HBaseClient$1.run(HBaseClient.java:138)
... 14 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:526)

[jira] [Updated] (RANGER-1681) Now ranger's kerberos configuration item relies directly on the configuration of the hadoop component. When the HDFS opens other functions such as HA, the test connectio

2017-07-10 Thread peng.jianhua (JIRA)


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

peng.jianhua updated RANGER-1681:
-
Attachment: 0001-RANGER-1681.patch

> Now ranger's kerberos configuration item relies directly on the configuration 
> of the hadoop component. When the HDFS opens other functions such as HA, the 
> test connection of hbase will fail
> -
>
> Key: RANGER-1681
> URL: https://issues.apache.org/jira/browse/RANGER-1681
> Project: Ranger
>  Issue Type: Bug
>  Components: admin, Ranger
>Reporter: peng.jianhua
>Assignee: peng.jianhua
>  Labels: patch
> Attachments: 0001-RANGER-1681.patch
>
>
> Currently, ragner-admin opens kerberos switch:
> 1.Configure the ranger-admin install.properties file:
> {code}
>   hadoop_conf=/etc/hadoop/conf
> {code}
> 2.Read the configuration items in the hadoop configuration file core-site.xml:
> {code}
>   
>   hadoop.security.authentication
>   kerberos
>   
> {code}
> However, when ranger-admin opened kerberos,and the HDFS opens the HA function,
> hbase-plugin service tests connection failure ,this is because ranger and 
> hadoop shared the same kerberos switch configuration file which caused a 
> series of unnecessary dependencies
> {code}
> 2017-06-22 08:14:44,518 INFO 
> org.apache.ranger.services.hbase.client.HBaseClient: HBase connection has 
> [zookeeper.znode.parent] with value [/hbase]
> 2017-06-22 08:14:44,520 INFO org.apache.ranger.plugin.client.BaseClient: Init 
> Login: security not enabled, using username
> 2017-06-22 08:14:44,581 INFO 
> org.apache.ranger.services.hbase.client.HBaseClient: getHBaseStatus: creating 
> default Hbase configuration
> 2017-06-22 08:14:44,582 INFO 
> org.apache.ranger.services.hbase.client.HBaseClient: getHBaseStatus: setting 
> config values from client
> 2017-06-22 08:14:44,582 INFO 
> org.apache.ranger.services.hbase.client.HBaseClient: getHBaseStatus: checking 
> HbaseAvailability with the new config
> 2017-06-22 08:14:44,923 WARN org.apache.zookeeper.ClientCnxn: SASL 
> configuration failed: javax.security.auth.login.LoginException: No JAAS 
> configuration section named 'Client' was found in specified JAAS 
> configuration file: '/dev/null'. Will continue connection to Zookeeper server 
> without SASL authentication, if Zookeeper server allows it.
> 2017-06-22 08:14:45,033 ERROR 
> org.apache.ranger.services.hbase.client.HBaseClient: getHBaseStatus: Unable 
> to check availability of Hbase environment [hbasedev].java.io.IOException: 
> java.lang.reflect.InvocationTargetException
> 2017-06-22 08:14:45,033 ERROR 
> org.apache.ranger.services.hbase.client.HBaseClient: <== 
> HBaseClient.testConnection(): Unable to retrieve any databases using given 
> parameters
> org.apache.ranger.plugin.client.HadoopException: getHBaseStatus: Unable to 
> check availability of Hbase environment [hbasedev].
>   at 
> org.apache.ranger.services.hbase.client.HBaseClient$1.run(HBaseClient.java:175)
>   at 
> org.apache.ranger.services.hbase.client.HBaseClient$1.run(HBaseClient.java:128)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at javax.security.auth.Subject.doAs(Subject.java:356)
>   at 
> org.apache.ranger.services.hbase.client.HBaseClient.getHBaseStatus(HBaseClient.java:128)
>   at 
> org.apache.ranger.services.hbase.client.HBaseClient.connectionTest(HBaseClient.java:100)
>   at 
> org.apache.ranger.services.hbase.client.HBaseResourceMgr.connectionTest(HBaseResourceMgr.java:47)
>   at 
> org.apache.ranger.services.hbase.RangerServiceHBase.validateConfig(RangerServiceHBase.java:59)
>   at 
> org.apache.ranger.biz.ServiceMgr$ValidateCallable.actualCall(ServiceMgr.java:560)
>   at 
> org.apache.ranger.biz.ServiceMgr$ValidateCallable.actualCall(ServiceMgr.java:547)
>   at 
> org.apache.ranger.biz.ServiceMgr$TimedCallable.call(ServiceMgr.java:508)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:262)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>   at java.lang.Thread.run(Thread.java:745)
> Caused by: java.io.IOException: java.lang.reflect.InvocationTargetException
>   at 
> org.apache.hadoop.hbase.client.ConnectionFactory.createConnection(ConnectionFactory.java:240)
>   at 
> org.apache.hadoop.hbase.client.ConnectionFactory.createConnection(ConnectionFactory.java:218)
>   at 
> org.apache.hadoop.hbase.client.ConnectionFactory.createConnection(ConnectionFactory.java:119)
>   at 
>

Re: Review Request 60421: RANGER-1491 : Automatically map group of external users to Administrator Role

2017-07-10 Thread Velmurugan Periasamy


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




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


single return from the method would be better. Also no exceptions are 
handled here.



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


will this work if usersync user is customized? Also it would be a good idea 
to log debug messages for else condition, currently there is no clue if the 
execution falls on else condition.



security-admin/src/main/java/org/apache/ranger/biz/XUserMgr.java
Line 1278 (original), 1298 (patched)


Logging else condition (allowing rangerusersync) would be helpful



unixauthservice/scripts/templates/ranger-ugsync-template.xml
Lines 209 (patched)


To be consistent, add prefix "ranger.usersync" to this new property



unixauthservice/scripts/templates/ranger-ugsync-template.xml
Lines 213 (patched)


To be consistent, add prefix "ranger.usersync" to this new property



unixauthservice/scripts/templates/ranger-ugsync-template.xml
Lines 217 (patched)


To be consistent, add prefix "ranger.usersync" to this new property



unixauthservice/scripts/templates/ranger-ugsync-template.xml
Lines 221 (patched)


To be consistent, add prefix "ranger.usersync" to this new property


- Velmurugan Periasamy


On June 26, 2017, 8:01 a.m., bhavik patel wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/60421/
> ---
> 
> (Updated June 26, 2017, 8:01 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-1491
> https://issues.apache.org/jira/browse/RANGER-1491
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> Currently when Ranger connect to external LDAP server than users are 
> synchronised and they will get default as "User" role.
> 
> It would be a good feature to introduce a mechanism to automatically map 
> certain users (e.g. they are in a specific group) to "Administrator" or 
> "Keyadmin" role rather than setting as default "User" role.
> 
> 
> Diffs
> -
> 
>   security-admin/src/main/java/org/apache/ranger/biz/UserMgr.java 6f77832 
>   security-admin/src/main/java/org/apache/ranger/biz/XUserMgr.java cd1de9f 
>   security-admin/src/main/java/org/apache/ranger/service/XUserService.java 
> de95138 
>   security-admin/src/test/java/org/apache/ranger/biz/TestUserMgr.java 5e0ca20 
>   security-admin/src/test/java/org/apache/ranger/biz/TestXUserMgr.java 
> 30525b3 
>   
> ugsync/src/main/java/org/apache/ranger/ldapusersync/process/LdapPolicyMgrUserGroupBuilder.java
>  428ad30 
>   
> ugsync/src/main/java/org/apache/ranger/unixusersync/config/UserGroupSyncConfig.java
>  19343b2 
>   ugsync/src/main/java/org/apache/ranger/unixusersync/model/MUserInfo.java 
> 841bac6 
>   ugsync/src/main/java/org/apache/ranger/unixusersync/model/XUserInfo.java 
> 7d636fd 
>   unixauthservice/scripts/install.properties 13ae1e5 
>   unixauthservice/scripts/setup.py bbc9226 
>   unixauthservice/scripts/templates/installprop2xml.properties 1a9bf36 
>   unixauthservice/scripts/templates/ranger-ugsync-template.xml 0025dc8 
> 
> 
> Diff: https://reviews.apache.org/r/60421/diff/1/
> 
> 
> Testing
> ---
> 
> 1. Verified when ranger-admin connect to LDAP server than users are 
> synchronised form there they got same role which is specified in 
> usersync-side.
> 2. Verified unix authentication and usersync.
> 
> 
> Thanks,
> 
> bhavik patel
> 
>

Re: Review Request 60144: RANGER-1638. Improve the password validation from Ranger API

2017-07-10 Thread Ankita Sinha


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


Ship it!




Ship It!

- Ankita Sinha


On June 23, 2017, 9:43 a.m., Gautam Borad wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/60144/
> ---
> 
> (Updated June 23, 2017, 9:43 a.m.)
> 
> 
> Review request for ranger, Ankita Sinha, Don Bosco Durai, Abhay Kulkarni, 
> Madhan Neethiraj, Ramesh Mani, Selvamohan Neethiraj, and Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-1638
> https://issues.apache.org/jira/browse/RANGER-1638
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> Validation for password is done as per validation rules on the Ranger UI 
> side. Initially on Ranger API we didnt have validation for password length, 
> non-us character, alphabet and number compulsion. This patch handles that.
> 
> 
> Diffs
> -
> 
>   security-admin/src/main/java/org/apache/ranger/biz/XUserMgr.java cd1de9f 
>   security-admin/src/test/java/org/apache/ranger/biz/TestXUserMgr.java 
> 30525b3 
> 
> 
> Diff: https://reviews.apache.org/r/60144/diff/2/
> 
> 
> Testing
> ---
> 
> Tested the validations from both UI and backend in a CentOS node with Ranger.
> 
> 
> Thanks,
> 
> Gautam Borad
> 
>

Re: Review Request 60043: Ranger KMS should validate key name before importing into DB

2017-07-10 Thread Velmurugan Periasamy


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


Ship it!




Ship It!

- Velmurugan Periasamy


On June 22, 2017, 1:50 p.m., Ankita Sinha wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/60043/
> ---
> 
> (Updated June 22, 2017, 1:50 p.m.)
> 
> 
> Review request for ranger, Don Bosco Durai, Gautam Borad, Abhay Kulkarni, 
> Madhan Neethiraj, Pradeep Agrawal, Ramesh Mani, Selvamohan Neethiraj, Sailaja 
> Polavarapu, and Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-1639
> https://issues.apache.org/jira/browse/RANGER-1639
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> Actual :
> Ranger KMS does not validate key name before importing into DB. So the 
> imported key can have special characters in Key name.
> 
> Expected :
> Ranger KMS should validate key name before importing into DB.
> 
> 
> Diffs
> -
> 
>   kms/src/main/java/org/apache/hadoop/crypto/key/RangerKeyStore.java 09b46bc 
>   kms/src/test/java/org/apache/hadoop/crypto/key/kms/TestRangerKeyStore.java 
> PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/60043/diff/3/
> 
> 
> Testing
> ---
> 
> Below steps were followed to test this scenario
> 
> 1. Installed Hadoop KMS
> 2. Created encryption keys with combination of special characters, alphabets 
> and numbers
> 3. Installed Ranger KMS
> 4. imported hadoop key jceks to Ranger KMS (Validation was successful)
> 
> 
> Thanks,
> 
> Ankita Sinha
> 
>

Re: Review Request 60706: Export Policy not working when Knox proxy is Enabled.

2017-07-10 Thread Velmurugan Periasamy


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


Ship it!




Ship It!

- Velmurugan Periasamy


On July 7, 2017, 1:06 p.m., Nitin Galave wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/60706/
> ---
> 
> (Updated July 7, 2017, 1:06 p.m.)
> 
> 
> Review request for ranger, Ankita Sinha, Gautam Borad, and Velmurugan 
> Periasamy.
> 
> 
> Bugs: RANGER-1679
> https://issues.apache.org/jira/browse/RANGER-1679
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> When Knox proxy is enabled, export button which is used to download the 
> policies is not working.
> 
> 
> Diffs
> -
> 
>   security-admin/src/main/webapp/scripts/utils/XAUtils.js 56ac538 
> 
> 
> Diff: https://reviews.apache.org/r/60706/diff/1/
> 
> 
> Testing
> ---
> 
> Verified : 
> Able to import/export policies on service listing page for both cases( 
> enable/disabled Knox proxy ).
> 
> 
> Thanks,
> 
> Nitin Galave
> 
>

Re: Review Request 60144: RANGER-1638. Improve the password validation from Ranger API

2017-07-10 Thread Velmurugan Periasamy


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


Ship it!




Ship It!

- Velmurugan Periasamy


On June 23, 2017, 9:43 a.m., Gautam Borad wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/60144/
> ---
> 
> (Updated June 23, 2017, 9:43 a.m.)
> 
> 
> Review request for ranger, Ankita Sinha, Don Bosco Durai, Abhay Kulkarni, 
> Madhan Neethiraj, Ramesh Mani, Selvamohan Neethiraj, and Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-1638
> https://issues.apache.org/jira/browse/RANGER-1638
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> Validation for password is done as per validation rules on the Ranger UI 
> side. Initially on Ranger API we didnt have validation for password length, 
> non-us character, alphabet and number compulsion. This patch handles that.
> 
> 
> Diffs
> -
> 
>   security-admin/src/main/java/org/apache/ranger/biz/XUserMgr.java cd1de9f 
>   security-admin/src/test/java/org/apache/ranger/biz/TestXUserMgr.java 
> 30525b3 
> 
> 
> Diff: https://reviews.apache.org/r/60144/diff/2/
> 
> 
> Testing
> ---
> 
> Tested the validations from both UI and backend in a CentOS node with Ranger.
> 
> 
> Thanks,
> 
> Gautam Borad
> 
>

Re: Review Request 60385: Ranger KMS should validate key name before importing into DB

2017-07-10 Thread Velmurugan Periasamy


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


Ship it!




Ship It!

- Velmurugan Periasamy


On June 23, 2017, 6:19 a.m., Ankita Sinha wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/60385/
> ---
> 
> (Updated June 23, 2017, 6:19 a.m.)
> 
> 
> Review request for ranger, Don Bosco Durai, Gautam Borad, Abhay Kulkarni, 
> Madhan Neethiraj, Pradeep Agrawal, Ramesh Mani, Selvamohan Neethiraj, Sailaja 
> Polavarapu, and Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-1639
> https://issues.apache.org/jira/browse/RANGER-1639
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> Actual :
> Ranger KMS does not validate key name before importing into DB. So the 
> imported key can have special characters in Key name.
> 
> Expected :
> Ranger KMS should validate key name before importing into DB.
> 
> 
> Diffs
> -
> 
>   kms/src/main/java/org/apache/hadoop/crypto/key/RangerKeyStore.java a001c08 
>   kms/src/test/java/org/apache/hadoop/crypto/key/kms/TestRangerKeyStore.java 
> PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/60385/diff/1/
> 
> 
> Testing
> ---
> 
> Below steps were followed to test this scenario
> 
> 1. Installed Hadoop KMS
> 2. Created encryption keys with combination of special characters, alphabets 
> and numbers
> 3. Installed Ranger KMS
> 4. imported hadoop key jceks to Ranger KMS (Validation was successful)
> 
> 
> Thanks,
> 
> Ankita Sinha
> 
>

Re: Review Request 60421: RANGER-1491 : Automatically map group of external users to Administrator Role

[jira] [Created] (RANGER-1685) Utility script that will list the users with a given role

[jira] [Updated] (RANGER-1678) In different places to achieve the same function using repeat codes, new issue is perhaps generated when these functions are modified.

Re: Review Request 60696: In different places to achieve the same function using repeat codes, new issue is perhaps generated when these functions are modified.

[jira] [Updated] (RANGER-1678) In different places to achieve the same function using repeat codes, new issue is perhaps generated when these functions are modified.

Re: Review Request 60696: In different places to achieve the same function using repeat codes, new issue is perhaps generated when these functions are modified.

[jira] [Commented] (RANGER-1671) The admin service can't audit to Solr using Basic Authentication

[jira] [Created] (RANGER-1684) We should support solr plugin in ranger when kerberos was not opened.

[jira] [Commented] (RANGER-1502) Solr shutdown does not cause the audit log file to be flushed and closed.

[jira] [Updated] (RANGER-1502) Solr shutdown does not cause the audit log file to be flushed and closed.

[jira] [Commented] (RANGER-1502) Solr shutdown does not cause the audit log file to be flushed and closed.

Re: Review Request 60746: RANGER-1683 - Fix the failing Kerberos tests on Jenkins

[jira] [Resolved] (RANGER-1675) Policy conditions not enabled by default for Hive policies

[jira] [Created] (RANGER-1683) Fix the failing Kerberos tests on Jenkins

[jira] [Commented] (RANGER-1666) Ranger UI should consider "recursiveSupported" attribute value at each resource level to Store the Policy

[jira] [Commented] (RANGER-1671) The admin service can't audit to Solr using Basic Authentication

Re: Review Request 60696: In different places to achieve the same function using repeat codes, new issue is perhaps generated when these functions are modified.

[jira] [Commented] (RANGER-1639) Ranger KMS should validate key name before importing into DB

Re: Review Request 60385: Ranger KMS should validate key name before importing into DB

[jira] [Created] (RANGER-1682) Clicking on export service after session timeout gets stuck indefinitely

[jira] [Updated] (RANGER-1680) Hive user can't read from HDFS when trying to "LOAD DATA INPATH" in spite of HDFS access is granted by Ranger

[jira] [Comment Edited] (RANGER-1681) Now ranger's kerberos configuration item relies directly on the configuration of the hadoop component. When the HDFS opens other functions such as HA, the test co

[jira] [Commented] (RANGER-1681) Now ranger's kerberos configuration item relies directly on the configuration of the hadoop component. When the HDFS opens other functions such as HA, the test connect

Review Request 60733: RANGER-1681:Now ranger's kerberos configuration item relies directly on the configuration of the hadoop component. When the HDFS opens other functions such as HA, the test connec

[jira] [Commented] (RANGER-1681) Now ranger's kerberos configuration item relies directly on the configuration of the hadoop component. When the HDFS opens other functions such as HA, the test connect

Re: Review Request 60733: RANGER-1681:Now ranger's kerberos configuration item relies directly on the configuration of the hadoop component. When the HDFS opens other functions such as HA, the test co

[jira] [Updated] (RANGER-1681) Now ranger's kerberos configuration item relies directly on the configuration of the hadoop component. When the HDFS opens other functions such as HA, the test connectio

Re: Review Request 60421: RANGER-1491 : Automatically map group of external users to Administrator Role

Re: Review Request 60144: RANGER-1638. Improve the password validation from Ranger API

Re: Review Request 60043: Ranger KMS should validate key name before importing into DB

Re: Review Request 60706: Export Policy not working when Knox proxy is Enabled.

Re: Review Request 60144: RANGER-1638. Improve the password validation from Ranger API

Re: Review Request 60385: Ranger KMS should validate key name before importing into DB

33 matches

Site Navigation

Mail list logo

Footer information