[jira] [Created] (RANGER-2002) Ranger support for time based classifications and business terms from Apache Atlas

2018-02-28 Thread Srikanth Venkat (JIRA) 
Srikanth Venkat created RANGER-2002:
---

 Summary: Ranger support for time based classifications and 
business terms from Apache Atlas
 Key: RANGER-2002
 URL: https://issues.apache.org/jira/browse/RANGER-2002
 Project: Ranger
  Issue Type: New Feature
  Components: Ranger
Reporter: Srikanth Venkat
 Fix For: 1.0.0


Currently classifications and business glossary terms in Apache Atlas are 
treated as being valid permanently in Ranger. There are use cases where such 
classifications are time bound based on customer input (such as financial 
information about earnings that is sensitive and restricted only until the 
earnings release) (i.e) either be effective after a certain date/time and/or 
expire after a specific date/time or valid only during an interval from a start 
date/time to an end date/time

Ranger policy engine needs to be able to recognize the start and end times for 
tags/classifications received from Apache Atlas via tag sync and enforce 
tag-based policies depending on attributes of the tags that represent its 
validity period.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (RANGER-1978) Upgrade Jackson Databind to 2.8.11

2018-02-28 Thread Velmurugan Periasamy (JIRA) 

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

Velmurugan Periasamy commented on RANGER-1978:
--

Removing 1.0.0 as fix version 

> Upgrade Jackson Databind to 2.8.11
> --
>
> Key: RANGER-1978
> URL: https://issues.apache.org/jira/browse/RANGER-1978
> Project: Ranger
>  Issue Type: Improvement
>  Components: Ranger
>Affects Versions: 1.0.0
>Reporter: Pradeep Agrawal
>Assignee: Pradeep Agrawal
>Priority: Major
> Attachments: 0001-RANGER-1978-Upgrade-Jackson-Databind-to-2.8.11.patch
>
>
> Upgrade Jackson Databind to 2.8.11



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (RANGER-1978) Upgrade Jackson Databind to 2.8.11

2018-02-28 Thread Velmurugan Periasamy (JIRA) 

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

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

> Upgrade Jackson Databind to 2.8.11
> --
>
> Key: RANGER-1978
> URL: https://issues.apache.org/jira/browse/RANGER-1978
> Project: Ranger
>  Issue Type: Improvement
>  Components: Ranger
>Affects Versions: 1.0.0
>Reporter: Pradeep Agrawal
>Assignee: Pradeep Agrawal
>Priority: Major
> Attachments: 0001-RANGER-1978-Upgrade-Jackson-Databind-to-2.8.11.patch
>
>
> Upgrade Jackson Databind to 2.8.11



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (RANGER-1935) Upgrade Ranger to support Apache Hadoop 3.0.0

2018-02-28 Thread Velmurugan Periasamy (JIRA) 

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

Velmurugan Periasamy commented on RANGER-1935:
--

Since Ranger 1.0.0 will only support Hadoop 2.7.0, can we remove 1.0.0 as fix 
version ? 

> Upgrade Ranger to support Apache Hadoop 3.0.0
> -
>
> Key: RANGER-1935
> URL: https://issues.apache.org/jira/browse/RANGER-1935
> Project: Ranger
>  Issue Type: Improvement
>  Components: plugins
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 1.0.0
>
> Attachments: 
> 0001-RANGER-1935-Upgrade-Ranger-to-support-Apache-Hadoop-.patch
>
>
> This task is to upgrade Ranger to support Apache Hadoop 3.0.0. Here are some 
> notes about the upgrade:
> a) The Hive plugin needs the Hadoop 3.0.0 jars to run the tests properly, as 
> Hive only supports the older Hadoop version, so an exclusion and some 
> additional 3.0.0 dependencies need to be added.
> b) The Storm plugin bundles the hadoop-auth jars in storm-core (although they 
> really should be renamed here). Therefore, we have no option but to package 
> Storm with the Hadoop 2.7.x jars, until such time that Storm upgrades the 
> Hadoop dependency.
> This is an initial patch to get some feedback. If there is broad agreement on 
> the upgrade I will test the distributions properly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Review Request 65858: RANGER-2001:Similar to RANGER-1469, we should check whether the user or group has existed before the installer create a new user or group when user install usersync

2018-02-28 Thread Qiang Zhang 

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

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


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


Repository: ranger


Description
---

Similar to RANGER-1469, we should check whether the user or group has existed 
before the installer create a new user or group when user install usersync


Diffs
-

  unixauthservice/scripts/setup.py 5ae9123 


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


Testing
---


Thanks,

Qiang Zhang

[jira] [Updated] (RANGER-2001) Similar to RANGER-1469, we should check whether the user or group has existed before the installer create a new user or group when user install usersync

2018-02-28 Thread Qiang Zhang (JIRA) 

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

Qiang Zhang updated RANGER-2001:

Attachment: 0001-RANGER-2001-Similar-to-RANGER-1469-we-should-check-w.patch

> Similar to RANGER-1469, we should check whether the user or group has existed 
> before the installer create a new user or group when user install usersync
> 
>
> Key: RANGER-2001
> URL: https://issues.apache.org/jira/browse/RANGER-2001
> Project: Ranger
>  Issue Type: Improvement
>  Components: usersync
>Reporter: Qiang Zhang
>Assignee: Qiang Zhang
>Priority: Major
> Attachments: 
> 0001-RANGER-2001-Similar-to-RANGER-1469-we-should-check-w.patch
>
>
> Similar to RANGER-1469, we should check whether the user or group has existed 
> before the installer create a new user or group when user install usersync



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (RANGER-1824) Upgrade Spring Framework to 3.2.18

2018-02-28 Thread Velmurugan Periasamy (JIRA) 

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

Velmurugan Periasamy commented on RANGER-1824:
--

Since the plan is to release 1.0.0 soon, I think this should be addressed in 
next release. CC [~spolavarapu]/[~coheigea]/[~pradeep.agrawal]

> Upgrade Spring Framework to 3.2.18
> --
>
> Key: RANGER-1824
> URL: https://issues.apache.org/jira/browse/RANGER-1824
> Project: Ranger
>  Issue Type: Improvement
>  Components: admin
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
>Priority: Minor
> Fix For: 1.0.0
>
> Attachments: 0001-RANGER-1824-Upgrade-Spring-Framework-to-3.2.18.patch
>
>
> When starting the Admin console, the following appears in the logs:
> 2017-10-02 10:00:35,651 [localhost-startStop-1] WARN  
> org.springframework.security.core.SpringSecurityCoreVersion 
> (SpringSecurityCoreVersion.java:60) -  You are advised to use Spring 
> 3.2.18.RELEASE or later with this version. You are running: 3.2.10.RELEASE
> We should update Spring to 3.2.18



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (RANGER-1933) Improvement on Ranger-usersync log configuration

2018-02-28 Thread Nikhil Purbhe (JIRA) 

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

Nikhil Purbhe updated RANGER-1933:
--
Issue Type: Improvement  (was: Bug)

> Improvement on Ranger-usersync log configuration
> 
>
> Key: RANGER-1933
> URL: https://issues.apache.org/jira/browse/RANGER-1933
> Project: Ranger
>  Issue Type: Improvement
>  Components: Ranger
>Affects Versions: 1.0.0
>Reporter: Nikhil Purbhe
>Assignee: Nikhil Purbhe
>Priority: Major
> Fix For: 1.0.0
>
> Attachments: RANGER-1933.patch
>
>
> Improvement on Ranger-usersync log configuration.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (RANGER-1953) improvement on user-group page listing

2018-02-28 Thread Nikhil Purbhe (JIRA) 

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

Nikhil Purbhe updated RANGER-1953:
--
Issue Type: Improvement  (was: Bug)

> improvement on user-group page listing
> --
>
> Key: RANGER-1953
> URL: https://issues.apache.org/jira/browse/RANGER-1953
> Project: Ranger
>  Issue Type: Improvement
>  Components: Ranger
>Affects Versions: 1.0.0
>Reporter: Nikhil Purbhe
>Assignee: Nikhil Purbhe
>Priority: Major
> Fix For: 1.0.0, 0.7.2
>
> Attachments: RANGER-1953-improvement-on-user-group-page-listing.patch
>
>
> improvement on user-group page listing



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (RANGER-1738) RangerYarnAuthorizer not compatible with Hadoop-3.0.0

2018-02-28 Thread Velmurugan Periasamy (JIRA) 

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

Velmurugan Periasamy commented on RANGER-1738:
--

Since Ranger 1.0.0 will only support Hadoop 2.7.0, can we remove 1.0.0 as fix 
version ? 

> RangerYarnAuthorizer not compatible with Hadoop-3.0.0
> -
>
> Key: RANGER-1738
> URL: https://issues.apache.org/jira/browse/RANGER-1738
> Project: Ranger
>  Issue Type: Bug
>  Components: plugins
>Affects Versions: 0.7.1
>Reporter: Hong Shen
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 1.0.0
>
> Attachments: 
> 0001-RANGER-1738-RangerYarnAuthorizer-not-compatible-with.patch
>
>
> In the newest hadoop version 3.0.0, YarnAuthorizationProvider has changed.
> The new YarnAuthorizationProvider.java has change the methods checkPermission 
> and setPermission, 
> {code:title=YarnAuthorizationProvider.java|borderStyle=solid}
>   /**
>* Check if user has the permission to access the target object.
>* 
>* @param accessRequest
>*  the request object which contains all the access context info.
>* @return true if user can access the object, otherwise false.
>*/
>   public abstract boolean checkPermission(AccessRequest accessRequest);
>   /**
>* Set permissions for the target object.
>*
>* @param permissions
>*A list of permissions on the target object.
>* @param ugi User who sets the permissions.
>*/
>   public abstract void setPermission(List permissions,
>   UserGroupInformation ugi);
> {code}
> But the RangerYarnAuthorizer extends YarnAuthorizationProvider impletement 
> the old method.
> {code:title=RangerYarnAuthorizer.java|borderStyle=solid}
>   @Override
>   public void setPermission(PrivilegedEntity entity, Map AccessControlList> permission, UserGroupInformation ugi) {
>...
>   @Override
>   public boolean checkPermission(AccessType accessType, PrivilegedEntity 
> entity, UserGroupInformation ugi) {
> {code}
> I think yarn plugin should also impletement the new method. I will add a 
> patch for it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (RANGER-1963) Show actual hive query on ranger audit UI.

2018-02-28 Thread Nikhil Purbhe (JIRA) 

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

Nikhil Purbhe updated RANGER-1963:
--
Issue Type: New Feature  (was: Bug)

> Show actual hive query on ranger audit UI.
> --
>
> Key: RANGER-1963
> URL: https://issues.apache.org/jira/browse/RANGER-1963
> Project: Ranger
>  Issue Type: New Feature
>  Components: Ranger
>Affects Versions: 0.7.2
>Reporter: Nikhil Purbhe
>Assignee: Nikhil Purbhe
>Priority: Major
> Fix For: 1.0.0
>
> Attachments: 
> RANGER-1963-Show-actual-hive-query-on-ranger-audit-U.patch
>
>
> Hive Access audits in ranger(Access Audit Tab) should show the actual query 
> associated with the hive access event for a particular column or table or 
> database. 
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (RANGER-2001) Similar to RANGER-1469, we should check whether the user or group has existed before the installer create a new user or group when user install usersync

2018-02-28 Thread Qiang Zhang (JIRA) 
Qiang Zhang created RANGER-2001:
---

 Summary: Similar to RANGER-1469, we should check whether the user 
or group has existed before the installer create a new user or group when user 
install usersync
 Key: RANGER-2001
 URL: https://issues.apache.org/jira/browse/RANGER-2001
 Project: Ranger
  Issue Type: Improvement
  Components: usersync
Reporter: Qiang Zhang
Assignee: Qiang Zhang


Similar to RANGER-1469, we should check whether the user or group has existed 
before the installer create a new user or group when user install usersync



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Ranger user sync with Identity Server on a kerberized cluster

2018-02-28 Thread CHODISETTY, LAKSHMI SIRISHA 
Hi Team,

Is it possible to use Identity Server for configuring Ranger user sync ? If 
possible, could you just share the steps to do the same ?

I'm using Azure hadoop clusters that are provisioned using cloud break and the 
set up is kerberized.

With best regards,
Sirisha Chodisetty

Siemens Technology and Services Private Limited
CT RDA BAM ADM-IN
84, Hosur Road
Bengaluru 560100, Indien
Mobil: +91 9731149224
mailto:lakshmi.chodise...@siemens.com
www.siemens.co.in/STS
www.siemens.com/ingenuityforlife
[www.siemens.com/ingenuityforlife]
Registered Office: Unit 501/C-1, 5th Floor, Poonam Chambers, A Wing, Dr. Annie 
Besant Road, Worli, Mumbai - 400018. Telephone +91 22 39677000. Fax +91 22 
24362404. Other Offices: Bangalore, Chennai, Gurgaon, Noida, Pune. Corporate 
Identity number: U9MH1986PTC093854

[jira] [Created] (RANGER-2000) Policy & policy item effective dates to support time-bound and temporary authorization

2018-02-28 Thread Srikanth Venkat (JIRA) 
Srikanth Venkat created RANGER-2000:
---

 Summary: Policy & policy item effective dates to support 
time-bound and temporary authorization
 Key: RANGER-2000
 URL: https://issues.apache.org/jira/browse/RANGER-2000
 Project: Ranger
  Issue Type: New Feature
  Components: Ranger
Reporter: Srikanth Venkat
 Fix For: 1.0.0


Currently Ranger policies have effectiveness period that is permanent i.e. once 
authored they can only be disabled or enabled. There are many use cases where 
such policies or even a policy condition needs to be time bound. For example 
certain financial information about earnings that is sensitive and restricted 
only until the earnings release date. 

it would be great to have the ability to specify with each policy or policy 
condition a time horizon when it is effective (i.e.) either be effective after 
a certain date and/or expire after a specific date or only valid within a 
certain time window and have Ranger check whether the policy is effective 
before evaluating in the policy engine. Therefore, policy authoring can be 
simplified and does not require any subsequent action from the user, basically 
making policy authoring a one time effort and users do not have to go back 
disable the policies once it is past the expiration date.

This means that:
 # Ranger policy engine needs to be able to recognize the start and end times 
for policies or specific policy items (conditions) and enforce them based on 
period of validity specified by the user.
 # Active policies should be checked not only based on the resource, user and 
environment context but also whether the policy itself or policy item condition 
is effective.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (RANGER-1999) Policy evaluation to support multiple values for accessed resource

2018-02-28 Thread Madhan Neethiraj (JIRA) 

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

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

> Policy evaluation to support multiple values for accessed resource
> --
>
> Key: RANGER-1999
> URL: https://issues.apache.org/jira/browse/RANGER-1999
> Project: Ranger
>  Issue Type: Improvement
>  Components: plugins
>Reporter: Madhan Neethiraj
>Assignee: Madhan Neethiraj
>Priority: Major
> Attachments: RANGER-1999.patch
>
>
> While evaluating access requests, Ranger policy engine picks policies based 
> on the resource value specified in the access request. Currently 
> access-resource abstraction only supports a single value for each 
> resource-type - like database/table/column. Authorization of access to some 
> resources might require the policy engine to pick policies based on multiple 
> values for a resource.
> For example, consider access authorization for an entity in Apache Atlas. An 
> entity has a specific-type and a number of super-types - example: 
> type=database super-types=[dataset, asset]. While authorizing access to a 
> database entity, policies specified for its super-types, dataset and asset, 
> should also be evaluated.
> To enable such usecases, Ranger policy evaluation needs to be enhanced to 
> support a list of value for a resource. Policies that match for any of the 
> given values should be evaluated to determine the access result. Note that 
> this enhancement doesn't require any updates to the policy model; the changes 
> are needed only in the policy-engine.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Review Request 65854: RANGER-1999: Ranger policy engine updates to support list-of-values in access reource

2018-02-28 Thread Madhan Neethiraj 

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

Review request for ranger, Don Bosco Durai, Abhay Kulkarni, Nixon Rodrigues, 
and Ramesh Mani.


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


Repository: ranger


Description
---

Updated policy engine module to handle resources with multiple values


Diffs
-

  
agents-common/src/main/java/org/apache/ranger/authorization/utils/StringUtil.java
 2835cddd 
  
agents-common/src/main/java/org/apache/ranger/plugin/policyengine/RangerAccessResource.java
 2ee616a1 
  
agents-common/src/main/java/org/apache/ranger/plugin/policyengine/RangerAccessResourceImpl.java
 58004862 
  
agents-common/src/main/java/org/apache/ranger/plugin/policyengine/RangerAccessResourceReadOnly.java
 18bb1f44 
  
agents-common/src/main/java/org/apache/ranger/plugin/policyengine/RangerMutableResource.java
 9fcefbe0 
  
agents-common/src/main/java/org/apache/ranger/plugin/policyresourcematcher/RangerDefaultPolicyResourceMatcher.java
 415263ee 
  
agents-common/src/main/java/org/apache/ranger/plugin/resourcematcher/RangerAbstractResourceMatcher.java
 acd599a7 
  
agents-common/src/main/java/org/apache/ranger/plugin/resourcematcher/RangerDefaultResourceMatcher.java
 a7399eed 
  
agents-common/src/main/java/org/apache/ranger/plugin/resourcematcher/RangerResourceMatcher.java
 8183dedb 
  
agents-common/src/main/java/org/apache/ranger/plugin/resourcematcher/ResourceMatcher.java
 eab9dbc7 
  
agents-common/src/main/java/org/apache/ranger/plugin/service/RangerBasePlugin.java
 aad78340 
  
agents-common/src/main/java/org/apache/ranger/plugin/util/RangerResourceTrie.java
 f6c1e4d5 
  
agents-common/src/test/java/org/apache/ranger/plugin/policyengine/TestPolicyEngine.java
 bcd15779 
  
agents-common/src/test/java/org/apache/ranger/plugin/resourcematcher/RangerAbstractResourceMatcherTest.java
 e2c7c270 
  agents-common/src/test/resources/policyengine/test_policyengine_atlas.json 
PRE-CREATION 
  
hive-agent/src/main/java/org/apache/ranger/authorization/hive/authorizer/RangerHiveResource.java
 e4eafc69 
  
ranger-tools/src/main/java/org/apache/ranger/policyengine/perftest/v2/RangerPolicyFactory.java
 0008808e 
  security-admin/src/main/java/org/apache/ranger/rest/ServiceREST.java 5b7d0859 


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


Testing
---

- added unit tests to validate the enhancements


Thanks,

Madhan Neethiraj

[jira] [Created] (RANGER-1999) Policy evaluation to support multiple values for accessed resource

2018-02-28 Thread Madhan Neethiraj (JIRA) 
Madhan Neethiraj created RANGER-1999:


 Summary: Policy evaluation to support multiple values for accessed 
resource
 Key: RANGER-1999
 URL: https://issues.apache.org/jira/browse/RANGER-1999
 Project: Ranger
  Issue Type: Improvement
  Components: plugins
Reporter: Madhan Neethiraj
Assignee: Madhan Neethiraj


While evaluating access requests, Ranger policy engine picks policies based on 
the resource value specified in the access request. Currently access-resource 
abstraction only supports a single value for each resource-type - like 
database/table/column. Authorization of access to some resources might require 
the policy engine to pick policies based on multiple values for a resource.

For example, consider access authorization for an entity in Apache Atlas. An 
entity has a specific-type and a number of super-types - example: type=database 
super-types=[dataset, asset]. While authorizing access to a database entity, 
policies specified for its super-types, dataset and asset, should also be 
evaluated.

To enable such usecases, Ranger policy evaluation needs to be enhanced to 
support a list of value for a resource. Policies that match for any of the 
given values should be evaluated to determine the access result. Note that this 
enhancement doesn't require any updates to the policy model; the changes are 
needed only in the policy-engine.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Review Request 65739: RANGER-1985: Auditing for Ranger usersync operations

2018-02-28 Thread Sailaja Polavarapu 


> On Feb. 28, 2018, 8:14 a.m., Ramesh Mani wrote:
> > security-admin/src/main/java/org/apache/ranger/service/XUgsyncAuditInfoServiceBase.java
> > Lines 70 (patched)
> > 
> >
> > Can the resultList be null?

removed unused method


> On Feb. 28, 2018, 8:14 a.m., Ramesh Mani wrote:
> > ugsync/src/main/java/org/apache/ranger/ldapusersync/process/LdapPolicyMgrUserGroupBuilder.java
> > Lines 507 (patched)
> > 
> >
> > this doesnt throw exception? Please review this part restructure?

There is some cleanup/restructuring need to be done. So will track in a 
separate review request.


> On Feb. 28, 2018, 8:14 a.m., Ramesh Mani wrote:
> > ugsync/src/main/java/org/apache/ranger/unixusersync/process/PolicyMgrUserGroupBuilder.java
> > Lines 1220 (patched)
> > 
> >
> > return ret?
> > Assign ret with necessary value and also if possible return once at the 
> > end of the method, which is less error prone and readble.

There is some cleanup/restructuring need to be done. So will track in a 
separate review request.


- Sailaja


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


On March 1, 2018, 1:03 a.m., Sailaja Polavarapu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/65739/
> ---
> 
> (Updated March 1, 2018, 1:03 a.m.)
> 
> 
> Review request for ranger, Ankita Sinha, Gautam Borad, Abhay Kulkarni, Madhan 
> Neethiraj, Pradeep Agrawal, Ramesh Mani, Selvamohan Neethiraj, Sailaja 
> Polavarapu, and Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-1985
> https://issues.apache.org/jira/browse/RANGER-1985
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> Added code to support auditing for Ranger Usersync operations. This includes 
> auditing for all the sync sources (unix, file, and LDAP/AD) for every sync 
> interval. Also includes Rest API for showing these audits in Ranger UI.
> 
> 
> Diffs
> -
> 
>   security-admin/db/mysql/optimized/current/ranger_core_db_mysql.sql d516d64e 
>   
> security-admin/db/mysql/patches/031-create-schema-for-usersync-audit-info.sql 
> PRE-CREATION 
>   security-admin/db/oracle/optimized/current/ranger_core_db_oracle.sql 
> abc7d593 
>   
> security-admin/db/oracle/patches/031-create-schema-for-usersync-audit-info.sql
>  PRE-CREATION 
>   security-admin/db/postgres/optimized/current/ranger_core_db_postgres.sql 
> 88629463 
>   
> security-admin/db/postgres/patches/031-create-schema-for-usersync-audit-info.sql
>  PRE-CREATION 
>   
> security-admin/db/sqlanywhere/optimized/current/ranger_core_db_sqlanywhere.sql
>  bf3d954b 
>   
> security-admin/db/sqlanywhere/patches/031-create-schema-for-usersync-audit-info.sql
>  PRE-CREATION 
>   security-admin/db/sqlserver/optimized/current/ranger_core_db_sqlserver.sql 
> 56e2e99a 
>   
> security-admin/db/sqlserver/patches/031-create-schema-for-usersync-audit-info.sql
>  PRE-CREATION 
>   security-admin/src/main/java/org/apache/ranger/biz/AssetMgr.java 034053d2 
>   security-admin/src/main/java/org/apache/ranger/biz/XUserMgr.java 71298a41 
>   security-admin/src/main/java/org/apache/ranger/common/AppConstants.java 
> 4a02e26b 
>   security-admin/src/main/java/org/apache/ranger/db/RangerDaoManagerBase.java 
> d61cbc7b 
>   security-admin/src/main/java/org/apache/ranger/db/XXUgsyncAuditInfoDao.java 
> PRE-CREATION 
>   
> security-admin/src/main/java/org/apache/ranger/entity/XXUgsyncAuditInfo.java 
> PRE-CREATION 
>   security-admin/src/main/java/org/apache/ranger/rest/AssetREST.java 3c274e3f 
>   security-admin/src/main/java/org/apache/ranger/rest/XUserREST.java a07c243a 
>   
> security-admin/src/main/java/org/apache/ranger/security/context/RangerAPIList.java
>  460c7fda 
>   
> security-admin/src/main/java/org/apache/ranger/service/XUgsyncAuditInfoService.java
>  PRE-CREATION 
>   
> security-admin/src/main/java/org/apache/ranger/service/XUgsyncAuditInfoServiceBase.java
>  PRE-CREATION 
>   
> security-admin/src/main/java/org/apache/ranger/view/VXFileSyncSourceInfo.java 
> PRE-CREATION 
>   
> security-admin/src/main/java/org/apache/ranger/view/VXLdapSyncSourceInfo.java 
> PRE-CREATION 
>   security-admin/src/main/java/org/apache/ranger/view/VXUgsyncAuditInfo.java 
> PRE-CREATION 
>   
> security-admin/src/main/java/org/apache/ranger/view/VXUgsyncAuditInfoList.java
>  PRE-CREATION 
>   
> security-admin/src/main/java/org/apache/ranger/view/VXUnixSyncSourceInfo.java 
> PRE-CREATION 
>   security-admin/src/main/resources/META-INF/jpa_named_queries.xml

Re: Review Request 65739: RANGER-1985: Auditing for Ranger usersync operations

2018-02-28 Thread Sailaja Polavarapu 

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

(Updated March 1, 2018, 1:03 a.m.)


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


Changes
---

Incorporated review comments as well as updated patch file with latest sources 
from master


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


Repository: ranger


Description
---

Added code to support auditing for Ranger Usersync operations. This includes 
auditing for all the sync sources (unix, file, and LDAP/AD) for every sync 
interval. Also includes Rest API for showing these audits in Ranger UI.


Diffs (updated)
-

  security-admin/db/mysql/optimized/current/ranger_core_db_mysql.sql d516d64e 
  security-admin/db/mysql/patches/031-create-schema-for-usersync-audit-info.sql 
PRE-CREATION 
  security-admin/db/oracle/optimized/current/ranger_core_db_oracle.sql abc7d593 
  
security-admin/db/oracle/patches/031-create-schema-for-usersync-audit-info.sql 
PRE-CREATION 
  security-admin/db/postgres/optimized/current/ranger_core_db_postgres.sql 
88629463 
  
security-admin/db/postgres/patches/031-create-schema-for-usersync-audit-info.sql
 PRE-CREATION 
  
security-admin/db/sqlanywhere/optimized/current/ranger_core_db_sqlanywhere.sql 
bf3d954b 
  
security-admin/db/sqlanywhere/patches/031-create-schema-for-usersync-audit-info.sql
 PRE-CREATION 
  security-admin/db/sqlserver/optimized/current/ranger_core_db_sqlserver.sql 
56e2e99a 
  
security-admin/db/sqlserver/patches/031-create-schema-for-usersync-audit-info.sql
 PRE-CREATION 
  security-admin/src/main/java/org/apache/ranger/biz/AssetMgr.java 034053d2 
  security-admin/src/main/java/org/apache/ranger/biz/XUserMgr.java 71298a41 
  security-admin/src/main/java/org/apache/ranger/common/AppConstants.java 
4a02e26b 
  security-admin/src/main/java/org/apache/ranger/db/RangerDaoManagerBase.java 
d61cbc7b 
  security-admin/src/main/java/org/apache/ranger/db/XXUgsyncAuditInfoDao.java 
PRE-CREATION 
  security-admin/src/main/java/org/apache/ranger/entity/XXUgsyncAuditInfo.java 
PRE-CREATION 
  security-admin/src/main/java/org/apache/ranger/rest/AssetREST.java 3c274e3f 
  security-admin/src/main/java/org/apache/ranger/rest/XUserREST.java a07c243a 
  
security-admin/src/main/java/org/apache/ranger/security/context/RangerAPIList.java
 460c7fda 
  
security-admin/src/main/java/org/apache/ranger/service/XUgsyncAuditInfoService.java
 PRE-CREATION 
  
security-admin/src/main/java/org/apache/ranger/service/XUgsyncAuditInfoServiceBase.java
 PRE-CREATION 
  security-admin/src/main/java/org/apache/ranger/view/VXFileSyncSourceInfo.java 
PRE-CREATION 
  security-admin/src/main/java/org/apache/ranger/view/VXLdapSyncSourceInfo.java 
PRE-CREATION 
  security-admin/src/main/java/org/apache/ranger/view/VXUgsyncAuditInfo.java 
PRE-CREATION 
  
security-admin/src/main/java/org/apache/ranger/view/VXUgsyncAuditInfoList.java 
PRE-CREATION 
  security-admin/src/main/java/org/apache/ranger/view/VXUnixSyncSourceInfo.java 
PRE-CREATION 
  security-admin/src/main/resources/META-INF/jpa_named_queries.xml 35ba30d9 
  security-admin/src/main/resources/META-INF/persistence.xml 20f5bbac 
  
ugsync/src/main/java/org/apache/ranger/ldapusersync/process/LdapDeltaUserGroupBuilder.java
 2852b320 
  
ugsync/src/main/java/org/apache/ranger/ldapusersync/process/LdapPolicyMgrUserGroupBuilder.java
 18366ef1 
  
ugsync/src/main/java/org/apache/ranger/ldapusersync/process/LdapUserGroupBuilder.java
 6b2648d9 
  
ugsync/src/main/java/org/apache/ranger/unixusersync/model/FileSyncSourceInfo.java
 PRE-CREATION 
  
ugsync/src/main/java/org/apache/ranger/unixusersync/model/LdapSyncSourceInfo.java
 PRE-CREATION 
  
ugsync/src/main/java/org/apache/ranger/unixusersync/model/UgsyncAuditInfo.java 
PRE-CREATION 
  
ugsync/src/main/java/org/apache/ranger/unixusersync/model/UnixSyncSourceInfo.java
 PRE-CREATION 
  
ugsync/src/main/java/org/apache/ranger/unixusersync/process/FileSourceUserGroupBuilder.java
 713c8688 
  
ugsync/src/main/java/org/apache/ranger/unixusersync/process/PolicyMgrUserGroupBuilder.java
 864d884d 
  
ugsync/src/main/java/org/apache/ranger/unixusersync/process/UnixUserGroupBuilder.java
 60ce08d1 
  ugsync/src/main/java/org/apache/ranger/usergroupsync/UserGroupSink.java 
494efc21 


Diff: https://reviews.apache.org/r/65739/diff/4/

Changes: https://reviews.apache.org/r/65739/diff/3-4/


Testing
---

1. Tested with different types of sync sources (Unix, File, and LDAP/AD)
2. Also tested with incremental sync enabled for AD sync source.
3. Tested the Rest API for showing audits in Ranger UI.


Thanks,

Sailaja Polavarapu

[jira] [Commented] (RANGER-1958) [HBase] Implement getUserPermissions API of AccessControlService.Interface to allow clients to access HBase permissions stored in Ranger

2018-02-28 Thread Ramesh Mani (JIRA) 

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

Ramesh Mani commented on RANGER-1958:
-

[~an...@apache.org] Since there is ACL in Phoenix, it would good to have a 
RangerPhoenixPlugin than relying on RangerHBasePlugin alone.

But incase that is a long way to go and want to leverage on RangerHBasePlugin 
what is the expected implementation on getUserPernissions API? Could you please 
elaborate on the Phoenix request and what is expected out from Ranger? That 
will help us to move forward on this.

 

> [HBase] Implement getUserPermissions API of AccessControlService.Interface to 
> allow clients to access HBase permissions stored in Ranger
> 
>
> Key: RANGER-1958
> URL: https://issues.apache.org/jira/browse/RANGER-1958
> Project: Ranger
>  Issue Type: Bug
>  Components: plugins
>Reporter: Ankit Singhal
>Priority: Major
>
> We have added the support of ACLs in Phoenix as part of PHOENIX-4198. 
> Currently, the implementation relies on some of the APIs provided by 
> AccessControlService.Interface to get the user permission of the table but we 
> see that the API "AccessControlService.Interface#getUserPermissions"  is not 
> yet implemented in Ranger authorization module for HBase and thus, we are 
> unable to access permissions stored for HBase Table in Phoenix.
> In class RangerAuthorizationCoprocessor
> {code}
> @Override
>   public void getUserPermissions(RpcController controller, 
> AccessControlProtos.GetUserPermissionsRequest request, 
> RpcCallback done) {
>   LOG.debug("getUserPermissions(): ");
>   }
> {code}
> If we just implement this API, we can leverage the current HBase Ranger 
> plugin for Phoenix too.
> Although the long-term solution for Ranger could be to implement the 
> coprocessor hooks for Phoenix as how it has been done for HBase so that we 
> can also authorize new entities like VIEW, SEQUENCES, FUNCTIONs  (which can 
> not be supported with native HBase ACLs) along with Table and Schema. 
> Let me know your thoughts, I can try to put up a patch soon.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Review Request 65828: Update tagsync to handle Atlas notifications of type V1 and V2

2018-02-28 Thread Abhay Kulkarni 


> On Feb. 28, 2018, 6:28 a.m., Madhan Neethiraj wrote:
> > tagsync/src/main/java/org/apache/ranger/tagsync/source/atlas/EntityNotificationWrapper.java
> > Lines 47 (patched)
> > 
> >
> > Consider extracting fields in the constructor itself and storing them 
> > as members, so that accessor methods can simply return them:
> > - RangerAtlasEntityentity;
> > - String   entityTypeName;
> > - entityNotificationType   notificationType;
> > - Map> allClassifications;
> > - boolean  isEntityTypeHandled;
> > - boolean  isEntityDeleteOp;

Added following data items as members and initialized them in the constructor. 
Provided accessors for these members.

RangerAtlasEntity rangerAtlasEntity;
String entityTypeName;
EntityNotification.EntityNotificationType notificationType;
boolean isEntityTypeHandled;
boolean isEntityDeleteOp;
boolean isEmptyClassifications;


- Abhay


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


On Feb. 28, 2018, 3:11 a.m., Abhay Kulkarni wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/65828/
> ---
> 
> (Updated Feb. 28, 2018, 3:11 a.m.)
> 
> 
> Review request for ranger and Madhan Neethiraj.
> 
> 
> Bugs: RANGER-1997
> https://issues.apache.org/jira/browse/RANGER-1997
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> Atlas is upgraded to emit more efficient Entity Notifications (of type V2). 
> Tagsync is updated to handle them.
> 
> 
> Diffs
> -
> 
>   
> tagsync/src/main/java/org/apache/ranger/tagsync/source/atlas/AtlasNotificationMapper.java
>  91cf606af 
>   
> tagsync/src/main/java/org/apache/ranger/tagsync/source/atlas/AtlasTagSource.java
>  8c15ee58b 
>   
> tagsync/src/main/java/org/apache/ranger/tagsync/source/atlas/EntityNotificationWrapper.java
>  PRE-CREATION 
>   
> tagsync/src/main/java/org/apache/ranger/tagsync/source/atlasrest/RangerAtlasEntityWithTags.java
>  b25a24127 
> 
> 
> Diff: https://reviews.apache.org/r/65828/diff/1/
> 
> 
> Testing
> ---
> 
> Tested with local VM
> 
> 
> Thanks,
> 
> Abhay Kulkarni
> 
>

Re: Review Request 65828: Update tagsync to handle Atlas notifications of type V1 and V2

2018-02-28 Thread Abhay Kulkarni 

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

(Updated Feb. 28, 2018, 8:40 p.m.)


Review request for ranger and Madhan Neethiraj.


Changes
---

Addressed review comments


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


Repository: ranger


Description
---

Atlas is upgraded to emit more efficient Entity Notifications (of type V2). 
Tagsync is updated to handle them.


Diffs (updated)
-

  
tagsync/src/main/java/org/apache/ranger/tagsync/source/atlas/AtlasNotificationMapper.java
 91cf606af 
  
tagsync/src/main/java/org/apache/ranger/tagsync/source/atlas/AtlasTagSource.java
 8c15ee58b 
  
tagsync/src/main/java/org/apache/ranger/tagsync/source/atlas/EntityNotificationWrapper.java
 PRE-CREATION 
  
tagsync/src/main/java/org/apache/ranger/tagsync/source/atlasrest/RangerAtlasEntityWithTags.java
 b25a24127 


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

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


Testing
---

Tested with local VM


Thanks,

Abhay Kulkarni

Re: Review Request 65829: Improvement on permission module for listing modules

2018-02-28 Thread Gautam Borad 

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


Ship it!




Ship It!

- Gautam Borad


On Feb. 28, 2018, 7:35 a.m., Fatima Khan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/65829/
> ---
> 
> (Updated Feb. 28, 2018, 7:35 a.m.)
> 
> 
> Review request for ranger, Don Bosco Durai, Gautam Borad, Abhay Kulkarni, 
> Madhan Neethiraj, Pradeep Agrawal, Ramesh Mani, Selvamohan Neethiraj, and 
> Sailaja Polavarapu.
> 
> 
> Bugs: RANGER-1993
> https://issues.apache.org/jira/browse/RANGER-1993
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> 1.On permission listing page, if there are many users/group added in modules 
> and we do partial search then it gives pagination even when number of modules 
> are 7.
> 2.On Policy Listing Page, we don't have partial search for users and groups.
> 
> 
> Diffs
> -
> 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/store/AbstractPredicateUtil.java
>  7583864 
>   
> security-admin/src/main/java/org/apache/ranger/service/XModuleDefServiceBase.java
>  57cc694 
> 
> 
> Diff: https://reviews.apache.org/r/65829/diff/1/
> 
> 
> Testing
> ---
> 
> 1.Tested on permission listing module: to show proper results even after 
> applying filters.
> 2.Tested for all allowed filters on policy listing page, verified results 
> after applying filters for user's name and group name  .
> 
> 
> Thanks,
> 
> Fatima Khan
> 
>

Review Request 65831: RANGER-1998 : Add ability to specify passwords for admin accounts during ranger install only.

2018-02-28 Thread Fatima Khan 

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

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


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


Repository: ranger


Description
---

1] Currently, when Ranger is installed admin, keyadmin, rangerusersync, 
rangertagsync users are seeded users and they are not configurable during the 
install process. This task is to provide a facility to specify the admin users 
password during ranger install.
2] This feature can only be used once, for changing the admin user password for 
more than one time, users can use Ranger UI or using change password utility.


Diffs
-

  security-admin/scripts/db_setup.py 25b004a 
  security-admin/scripts/install.properties 49d2baa 
  security-admin/scripts/setup.sh b68347a 
  tagsync/scripts/install.properties e2e3ecd 
  tagsync/scripts/setup.py 9712e8c 
  tagsync/scripts/updatetagadminpassword.py 2c89e83 
  unixauthservice/scripts/install.properties 88bce69 
  unixauthservice/scripts/setup.py 5ae9123 
  unixauthservice/scripts/updatepolicymgrpassword.py 574ce3b 


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


Testing
---

Verified creation of seeded users with given passwords during ranger install.
Logged in to ranger using those passwords and verified all functionality 
provided for those users.


Thanks,

Fatima Khan

[jira] [Updated] (RANGER-1998) Add ability to specify passwords for admin accounts during ranger install only.

2018-02-28 Thread Fatima Amjad Khan (JIRA) 

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

Fatima Amjad Khan updated RANGER-1998:
--
Attachment: 0001-RANGER-1998-Add-ability-to-specify-passwords-for-adm.patch

> Add ability to specify passwords for admin accounts during ranger install 
> only.
> ---
>
> Key: RANGER-1998
> URL: https://issues.apache.org/jira/browse/RANGER-1998
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Affects Versions: 1.0.0
>Reporter: Fatima Amjad Khan
>Assignee: Fatima Amjad Khan
>Priority: Major
> Fix For: 1.0.0
>
> Attachments: 
> 0001-RANGER-1998-Add-ability-to-specify-passwords-for-adm.patch
>
>
> 1] Currently, when Ranger is installed admin,keyadmin, rangerusersync, 
> rangertagsync users are seeded users and they are not configurable during the 
> install process. This task is to provide a facility to specify the admin 
> users password during ranger install.
> 2] This feature can only be used once, for changing the admin user password 
> for more than one time, users can use Ranger UI or using change password 
> utility.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Prep for ranger-1.0.0 release

2018-02-28 Thread Colm O hEigeartaigh 
Thanks, please update the version on master to 1.1.0-SNAPSHOT as well when
you get a chance to avoid confusion.

Colm.

On Tue, Feb 27, 2018 at 11:50 PM, Sailaja Polavarapu <
spolavar...@hortonworks.com> wrote:

> FYI – ranger-1.0 branch is created with the pom files updated to 1.0.0
> version. From now on, only the patches that are required for 1.0.0 release
> should be cherry picked into this branch.
> Master branch is open for regular commits and will track for next release
> (1.1).
>
> Thanks,
> Sailaja.
>
> On 2/27/18, 1:48 PM, "Sailaja Polavarapu" 
> wrote:
>
> Thanks for all the feedback and +1s. I will be including latest
> version of kafka in ranger-1.0.0. But for Kylin, since there will be
> hadoop3 support release soon, it can be included in that.
> -Sailaja.
>
> On 2/23/18, 2:36 PM, "Zsombor Gegesy"  wrote:
>
> +1 for Ranger 1.0 !
>
> Regards,
>  Zsombor
>
> On Sat, Feb 24, 2018 at 5:03 AM, Velmurugan Periasamy <
> v...@apache.org>
> wrote:
>
> > +1 for Ranger 1.0 release.
> >
> > Thanks Sailaja for volunteering.
> >
> > From:  pengjianhua <35573...@qq.com>
> > Reply-To:  "dev@ranger.apache.org" 
> > Date:  Friday, February 23, 2018 at 4:55 AM
> > To:  "dev@ranger.apache.org" 
> > Subject:  Re: Prep for ranger-1.0.0 release
> >
> > I agree with Colm's point of view. Zhangqiang am developing this
> issue
> > to upgrade Kafka whichwas delayed due to our Spring Festival.
> >
> > I also hope to merge the Apacke Kylin Plugin into the ranger
> 1.0.0. the
> > 2.3.0 version of the Apache kylin is being voted. The Apacke
> Kylin
> > Plugin of the ranger has been successfully applied in some
> business
> > projects.
> >
> >
> >
> > Jianhua Peng
> >
> > 在 2018年02月23日 17:36, Colm O hEigeartaigh 写道:
> > >  +1. It would be nice to get the Kafka upgrade in if possible,
> as
> > currently
> > >  we support a very old version of Kafka.
> > >
> > >  Colm.
> > >
> > >  On Fri, Feb 23, 2018 at 9:00 AM, Jianhua Peng <
> pengjian...@apache.org>
> > >  wrote:
> > >
> > >>  +1
> > >>
> > >>  On 2018/02/23 01:34:36, Sailaja Polavarapu <
> > spolavar...@hortonworks.com>
> > >>  wrote:
> > >>>  Rangers:
> > >>>  As we are planning to do a release of ranger 1.0.0 soon
> (tentatively
> > >>  3/15/2018), I would like to create a branch ranger-1.0.0 for
> > stabilizing
> > >>  the release. All of the fixes should go into the master
> which will
> > track
> > >>  for our next major release and if needed will get
> cherry-picked into
> > >>  ranger-1.0.0 release.
> > >>>  I am volunteering to be the release manager for ranger
> 1.0.0 release.
> > >>  Based on the discussion, current plan is to make the ranger
> 1.0.0
> > release
> > >>  with Hadoop 2.7.x (not Hadoop 3) and Atlas 0.8.2 as
> dependencies.
> > >>>  Please let me know if any of you have any concerns and/or
> suggestions
> > on
> > >>  the release process.
> > >>>  Thanks,
> > >>>  Sailaja.
> > >>>
> > >
> > >
> >
> >
> >
> >
> >
>
>
>
>
>


-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Re: Review Request 65829: Improvement on permission module for listing modules

2018-02-28 Thread Zsombor Gegesy 

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


Ship it!




Ship It!

- Zsombor Gegesy


On Feb. 28, 2018, 7:35 a.m., Fatima Khan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/65829/
> ---
> 
> (Updated Feb. 28, 2018, 7:35 a.m.)
> 
> 
> Review request for ranger, Don Bosco Durai, Gautam Borad, Abhay Kulkarni, 
> Madhan Neethiraj, Pradeep Agrawal, Ramesh Mani, Selvamohan Neethiraj, and 
> Sailaja Polavarapu.
> 
> 
> Bugs: RANGER-1993
> https://issues.apache.org/jira/browse/RANGER-1993
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> 1.On permission listing page, if there are many users/group added in modules 
> and we do partial search then it gives pagination even when number of modules 
> are 7.
> 2.On Policy Listing Page, we don't have partial search for users and groups.
> 
> 
> Diffs
> -
> 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/store/AbstractPredicateUtil.java
>  7583864 
>   
> security-admin/src/main/java/org/apache/ranger/service/XModuleDefServiceBase.java
>  57cc694 
> 
> 
> Diff: https://reviews.apache.org/r/65829/diff/1/
> 
> 
> Testing
> ---
> 
> 1.Tested on permission listing module: to show proper results even after 
> applying filters.
> 2.Tested for all allowed filters on policy listing page, verified results 
> after applying filters for user's name and group name  .
> 
> 
> Thanks,
> 
> Fatima Khan
> 
>

[jira] [Commented] (RANGER-1991) Fix problems detected by static code analysis

2018-02-28 Thread Zsombor Gegesy (JIRA) 

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

Zsombor Gegesy commented on RANGER-1991:


Change commited to the master branch:
https://github.com/apache/ranger/commit/49b8a7a26653b028b7adaff3809a88f59fee3bf7

> Fix problems detected by static code analysis
> -
>
> Key: RANGER-1991
> URL: https://issues.apache.org/jira/browse/RANGER-1991
> Project: Ranger
>  Issue Type: Bug
>  Components: admin
>Affects Versions: 0.7.1
>Reporter: Zsombor Gegesy
>Assignee: Zsombor Gegesy
>Priority: Minor
>  Labels: code-cleanup, findbugs
> Fix For: master
>
> Attachments: RANGER-1991.patch
>
>
> FindBugs/SpotBug detects a couple of problems with the code base:
>  * Incorrect class casting - in XXServiceDef.equals
>  * Unnecessary NPE checks - for variables which is known to be non-null (for 
> example, because in other places a method is called on that object). In 
> ServiceREST.java PublicAPIs.java, ServiceUtil.java and independently in 
> XUserMgr.java
>  * Collection.contains method call which is never true - in 
> ServiceDBStore.validatePolicyItems for policyItem.getAccesses().contains("") 
> - because getAccesses doesn't store String objects
>  * Making public partially initialized objects in 
> HadoopConfigHolder.initResourceMap()
>  * Calling toString on array, which is not too readable
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (RANGER-1991) Fix problems detected by static code analysis

2018-02-28 Thread Zsombor Gegesy (JIRA) 

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

Zsombor Gegesy updated RANGER-1991:
---
Fix Version/s: master

> Fix problems detected by static code analysis
> -
>
> Key: RANGER-1991
> URL: https://issues.apache.org/jira/browse/RANGER-1991
> Project: Ranger
>  Issue Type: Bug
>  Components: admin
>Affects Versions: 0.7.1
>Reporter: Zsombor Gegesy
>Assignee: Zsombor Gegesy
>Priority: Minor
>  Labels: code-cleanup, findbugs
> Fix For: master
>
> Attachments: RANGER-1991.patch
>
>
> FindBugs/SpotBug detects a couple of problems with the code base:
>  * Incorrect class casting - in XXServiceDef.equals
>  * Unnecessary NPE checks - for variables which is known to be non-null (for 
> example, because in other places a method is called on that object). In 
> ServiceREST.java PublicAPIs.java, ServiceUtil.java and independently in 
> XUserMgr.java
>  * Collection.contains method call which is never true - in 
> ServiceDBStore.validatePolicyItems for policyItem.getAccesses().contains("") 
> - because getAccesses doesn't store String objects
>  * Making public partially initialized objects in 
> HadoopConfigHolder.initResourceMap()
>  * Calling toString on array, which is not too readable
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Review Request 65739: RANGER-1985: Auditing for Ranger usersync operations

2018-02-28 Thread Ramesh Mani 

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




security-admin/src/main/java/org/apache/ranger/service/XUgsyncAuditInfoServiceBase.java
Lines 70 (patched)


Can the resultList be null?



security-admin/src/main/java/org/apache/ranger/view/VXFileSyncSourceInfo.java
Lines 75 (patched)


Use StringBuilder.append()



ugsync/src/main/java/org/apache/ranger/ldapusersync/process/LdapPolicyMgrUserGroupBuilder.java
Lines 507 (patched)


this doesnt throw exception? Please review this part restructure?



ugsync/src/main/java/org/apache/ranger/unixusersync/model/UnixSyncSourceInfo.java
Lines 80 (patched)


Please use StringBuilder instead of + for concat, change all occurance of 
such usage



ugsync/src/main/java/org/apache/ranger/unixusersync/process/PolicyMgrUserGroupBuilder.java
Lines 1220 (patched)


return ret?
Assign ret with necessary value and also if possible return once at the end 
of the method, which is less error prone and readble.



ugsync/src/main/java/org/apache/ranger/unixusersync/process/UnixUserGroupBuilder.java
Lines 163 (patched)


remove commented out part?


- Ramesh Mani


On Feb. 28, 2018, 6:34 a.m., Sailaja Polavarapu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/65739/
> ---
> 
> (Updated Feb. 28, 2018, 6:34 a.m.)
> 
> 
> Review request for ranger, Ankita Sinha, Gautam Borad, Abhay Kulkarni, Madhan 
> Neethiraj, Pradeep Agrawal, Ramesh Mani, Selvamohan Neethiraj, Sailaja 
> Polavarapu, and Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-1985
> https://issues.apache.org/jira/browse/RANGER-1985
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> Added code to support auditing for Ranger Usersync operations. This includes 
> auditing for all the sync sources (unix, file, and LDAP/AD) for every sync 
> interval. Also includes Rest API for showing these audits in Ranger UI.
> 
> 
> Diffs
> -
> 
>   security-admin/db/mysql/optimized/current/ranger_core_db_mysql.sql 69f3768e 
>   
> security-admin/db/mysql/patches/031-create-schema-for-usersync-audit-info.sql 
> PRE-CREATION 
>   security-admin/db/oracle/optimized/current/ranger_core_db_oracle.sql 
> 5abbcd0c 
>   
> security-admin/db/oracle/patches/031-create-schema-for-usersync-audit-info.sql
>  PRE-CREATION 
>   security-admin/db/postgres/optimized/current/ranger_core_db_postgres.sql 
> 6dfc8412 
>   
> security-admin/db/postgres/patches/031-create-schema-for-usersync-audit-info.sql
>  PRE-CREATION 
>   
> security-admin/db/sqlanywhere/optimized/current/ranger_core_db_sqlanywhere.sql
>  d016 
>   
> security-admin/db/sqlanywhere/patches/031-create-schema-for-usersync-audit-info.sql
>  PRE-CREATION 
>   security-admin/db/sqlserver/optimized/current/ranger_core_db_sqlserver.sql 
> a2be2d4c 
>   
> security-admin/db/sqlserver/patches/031-create-schema-for-usersync-audit-info.sql
>  PRE-CREATION 
>   security-admin/src/main/java/org/apache/ranger/biz/AssetMgr.java 034053d2 
>   security-admin/src/main/java/org/apache/ranger/biz/XUserMgr.java cecb3f8b 
>   security-admin/src/main/java/org/apache/ranger/common/AppConstants.java 
> 4a02e26b 
>   security-admin/src/main/java/org/apache/ranger/db/RangerDaoManagerBase.java 
> db20a14a 
>   security-admin/src/main/java/org/apache/ranger/db/XXUgsyncAuditInfoDao.java 
> PRE-CREATION 
>   
> security-admin/src/main/java/org/apache/ranger/entity/XXUgsyncAuditInfo.java 
> PRE-CREATION 
>   security-admin/src/main/java/org/apache/ranger/rest/AssetREST.java 3c274e3f 
>   security-admin/src/main/java/org/apache/ranger/rest/XUserREST.java a07c243a 
>   
> security-admin/src/main/java/org/apache/ranger/security/context/RangerAPIList.java
>  460c7fda 
>   
> security-admin/src/main/java/org/apache/ranger/service/XUgsyncAuditInfoService.java
>  PRE-CREATION 
>   
> security-admin/src/main/java/org/apache/ranger/service/XUgsyncAuditInfoServiceBase.java
>  PRE-CREATION 
>   
> security-admin/src/main/java/org/apache/ranger/view/VXFileSyncSourceInfo.java 
> PRE-CREATION 
>   
> security-admin/src/main/java/org/apache/ranger/view/VXLdapSyncSourceInfo.java 
> PRE-CREATION 
>   security-admin/src/main/java/org/apache/ranger/view/VXUgsyncAuditInfo.java 
> PRE-CREATION 
>   
> security-admin/src/main/java/org/apache/ranger/view/VXUgsyncAuditInfoList.java
>  PRE-CREATION 
>   
>