date:20180314

Re: Review Request 65920: Ranger Tagsync should use cookie based authentication for subsequent requests to Ranger admin

2018-03-14 Thread Nikhil P


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

(Updated March 14, 2018, 12:01 p.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-2010
https://issues.apache.org/jira/browse/RANGER-2010


Repository: ranger


Description
---

Ranger Tagsync should use cookie based authentication for subsequent requests 
to Ranger admin.


Diffs (updated)
-

  
agents-common/src/main/java/org/apache/ranger/plugin/util/RangerRESTClient.java 
0d94edc 
  tagsync/src/main/java/org/apache/ranger/tagsync/process/TagSyncConfig.java 
697c7cc 
  
tagsync/src/main/java/org/apache/ranger/tagsync/sink/tagadmin/TagAdminRESTSink.java
 a1dc8f5 
  tagsync/src/main/resources/ranger-tagsync-site.xml 3542ae2 


Diff: https://reviews.apache.org/r/65920/diff/5/

Changes: https://reviews.apache.org/r/65920/diff/4-5/


Testing
---

1)verified if ranger tagsync works as expected.
2)verified if tagsync is not re-login for every notification if 
"ranger.tagsync.cookie.enabled" is set as true.


File Attachments (updated)


0003-RANGER-2010-Ranger-Tagsync-should-use-cookie-based-a.patch
  
https://reviews.apache.org/media/uploaded/files/2018/03/12/3f7133ab-72f9-413e-997c-4d9265f88cdc__0003-RANGER-2010-Ranger-Tagsync-should-use-cookie-based-a.patch
0005-RANGER-2010-Ranger-Tagsync-should-use-cookie-based-a.patch
  
https://reviews.apache.org/media/uploaded/files/2018/03/14/e8193a99-70e9-4124-b70a-bd9335665455__0005-RANGER-2010-Ranger-Tagsync-should-use-cookie-based-a.patch


Thanks,

Nikhil P

Re: Review Request 65920: Ranger Tagsync should use cookie based authentication for subsequent requests to Ranger admin

2018-03-14 Thread Madhan Neethiraj


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


Ship it!




Ship It!

- Madhan Neethiraj


On March 14, 2018, 6:31 a.m., Nikhil P wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/65920/
> ---
> 
> (Updated March 14, 2018, 6:31 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-2010
> https://issues.apache.org/jira/browse/RANGER-2010
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> Ranger Tagsync should use cookie based authentication for subsequent requests 
> to Ranger admin.
> 
> 
> Diffs
> -
> 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/util/RangerRESTClient.java
>  0d94edc 
>   tagsync/src/main/java/org/apache/ranger/tagsync/process/TagSyncConfig.java 
> 697c7cc 
>   
> tagsync/src/main/java/org/apache/ranger/tagsync/sink/tagadmin/TagAdminRESTSink.java
>  a1dc8f5 
>   tagsync/src/main/resources/ranger-tagsync-site.xml 3542ae2 
> 
> 
> Diff: https://reviews.apache.org/r/65920/diff/5/
> 
> 
> Testing
> ---
> 
> 1)verified if ranger tagsync works as expected.
> 2)verified if tagsync is not re-login for every notification if 
> "ranger.tagsync.cookie.enabled" is set as true.
> 
> 
> File Attachments
> 
> 
> 0003-RANGER-2010-Ranger-Tagsync-should-use-cookie-based-a.patch
>   
> https://reviews.apache.org/media/uploaded/files/2018/03/12/3f7133ab-72f9-413e-997c-4d9265f88cdc__0003-RANGER-2010-Ranger-Tagsync-should-use-cookie-based-a.patch
> 0005-RANGER-2010-Ranger-Tagsync-should-use-cookie-based-a.patch
>   
> https://reviews.apache.org/media/uploaded/files/2018/03/14/e8193a99-70e9-4124-b70a-bd9335665455__0005-RANGER-2010-Ranger-Tagsync-should-use-cookie-based-a.patch
> 
> 
> Thanks,
> 
> Nikhil P
> 
>

[jira] [Updated] (RANGER-2021) Ranger "Login Sessions" Audits impossible to browse due to 'rangerusersync'

2018-03-14 Thread Sean Roberts (JIRA)


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

Sean Roberts updated RANGER-2021:
-
Description: 
"Ranger User Sync" logs into Ranger multiple times a second.

The high number and rate of these sessions makes it impossible to use the 
"Login Sessions" audit page:
 !screenshot-1.png! 

Further, it's adding a lot of extra requests and overhead to Ranger, Ranger 
User Sync, and the backing database (e.g. MySQL).

The service should re-use its session rather than continual logins.

{code}
$ rpm -qa *usersync*
ranger_2_6_4_0_91-usersync-0.7.0.2.6.4.0-91.x86_64
{code}

  was:
"Ranger User Sync" logs into Ranger multiple times a second.

The high number and rate of these sessions makes it impossible to use the 
"Login Sessions" audit page.

Further, it's adding a lot of extra requests and overhead to Ranger, Ranger 
User Sync, and the backing database (e.g. MySQL).

The service should re-use its session rather than continual logins.

{code}
$ rpm -qa *usersync*
ranger_2_6_4_0_91-usersync-0.7.0.2.6.4.0-91.x86_64
{code}


> Ranger "Login Sessions" Audits impossible to browse due to 'rangerusersync'
> ---
>
> Key: RANGER-2021
> URL: https://issues.apache.org/jira/browse/RANGER-2021
> Project: Ranger
>  Issue Type: Bug
>  Components: usersync
>Affects Versions: 0.7.0
>Reporter: Sean Roberts
>Priority: Major
> Attachments: screenshot-1.png
>
>
> "Ranger User Sync" logs into Ranger multiple times a second.
> The high number and rate of these sessions makes it impossible to use the 
> "Login Sessions" audit page:
>  !screenshot-1.png! 
> Further, it's adding a lot of extra requests and overhead to Ranger, Ranger 
> User Sync, and the backing database (e.g. MySQL).
> The service should re-use its session rather than continual logins.
> {code}
> $ rpm -qa *usersync*
> ranger_2_6_4_0_91-usersync-0.7.0.2.6.4.0-91.x86_64
> {code}



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

Re: Review Request 66061: RANGER-2020 - Mandatory values are not filled then also able to create atlas policy

2018-03-14 Thread Nitin Galave


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


Ship it!




Ship It!

- Nitin Galave


On March 14, 2018, 10:16 a.m., Nixon Rodrigues wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66061/
> ---
> 
> (Updated March 14, 2018, 10:16 a.m.)
> 
> 
> Review request for ranger, Madhan Neethiraj, Mehul Parikh, Nitin Galave, and 
> Pradeep Agrawal.
> 
> 
> Bugs: RANGER-2020
> https://issues.apache.org/jira/browse/RANGER-2020
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> This patch includes changes in ranger-servicedef-atlas.json to add mandatory 
> property as true.
> 
> 
> Diffs
> -
> 
>   agents-common/src/main/resources/service-defs/ranger-servicedef-atlas.json 
> 52371257 
> 
> 
> Diff: https://reviews.apache.org/r/66061/diff/1/
> 
> 
> Testing
> ---
> 
> Deleted existing atlas-servicedef and added the updated servicedef and tested 
> creating policies 
> without values, the UI validation is now preventing from submiting the form.
> 
> 
> Thanks,
> 
> Nixon Rodrigues
> 
>

[jira] [Updated] (RANGER-2021) Ranger "Login Sessions" Audits impossible to browse due to 'rangerusersync'

2018-03-14 Thread Sean Roberts (JIRA)


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

Sean Roberts updated RANGER-2021:
-
Description: 
"Ranger User Sync" logs into Ranger multiple times a second. This is with:
{code}
ranger.usersync.source.impl.class=org.apache.ranger.unixusersync.process.UnixUserGroupBuilder
ranger.usersync.unix.backend=nss
{code}

The high number and rate of these sessions makes it impossible to use the 
"Login Sessions" audit page:

Further, it's adding a lot of extra requests and overhead to Ranger, Ranger 
User Sync, and the backing database (e.g. MySQL).

*The service should re-use its session rather than continual logins.*

!screenshot-1.png|width=640!

{code}
MariaDB [ranger]> select count(*),DATE(create_time) as date from x_auth_sess 
where login_id='rangerusersync' group by DATE(create_time) order by date desc 
limit 10;
+--++
| count(*) | date   |
+--++
| 3558 | 2018-03-14 |
| 8520 | 2018-03-13 |
| 8514 | 2018-03-12 |
| 8508 | 2018-03-11 |
| 8520 | 2018-03-10 |
| 8523 | 2018-03-09 |
| 8532 | 2018-03-08 |
| 8522 | 2018-03-07 |
| 8528 | 2018-03-06 |
| 8520 | 2018-03-05 |
+--++
10 rows in set (0.13 sec)
{code}

{code}
$ rpm -qa *usersync*
ranger_2_6_4_0_91-usersync-0.7.0.2.6.4.0-91.x86_64
{code}

  was:
"Ranger User Sync" logs into Ranger multiple times a second. This is with:
{code}
ranger.usersync.source.impl.class=org.apache.ranger.unixusersync.process.UnixUserGroupBuilder
ranger.usersync.unix.backend=nss
{code}

The high number and rate of these sessions makes it impossible to use the 
"Login Sessions" audit page:

Further, it's adding a lot of extra requests and overhead to Ranger, Ranger 
User Sync, and the backing database (e.g. MySQL).

The service should re-use its session rather than continual logins.

!screenshot-1.png|width=640!

{code}
MariaDB [ranger]> select count(*),DATE(create_time) as date from x_auth_sess 
where login_id='rangerusersync' group by DATE(create_time) order by date desc 
limit 10;
+--++
| count(*) | date   |
+--++
| 3558 | 2018-03-14 |
| 8520 | 2018-03-13 |
| 8514 | 2018-03-12 |
| 8508 | 2018-03-11 |
| 8520 | 2018-03-10 |
| 8523 | 2018-03-09 |
| 8532 | 2018-03-08 |
| 8522 | 2018-03-07 |
| 8528 | 2018-03-06 |
| 8520 | 2018-03-05 |
+--++
10 rows in set (0.13 sec)
{code}

{code}
$ rpm -qa *usersync*
ranger_2_6_4_0_91-usersync-0.7.0.2.6.4.0-91.x86_64
{code}


> Ranger "Login Sessions" Audits impossible to browse due to 'rangerusersync'
> ---
>
> Key: RANGER-2021
> URL: https://issues.apache.org/jira/browse/RANGER-2021
> Project: Ranger
>  Issue Type: Bug
>  Components: usersync
>Affects Versions: 0.7.0
>Reporter: Sean Roberts
>Priority: Major
> Attachments: screenshot-1.png
>
>
> "Ranger User Sync" logs into Ranger multiple times a second. This is with:
> {code}
> ranger.usersync.source.impl.class=org.apache.ranger.unixusersync.process.UnixUserGroupBuilder
> ranger.usersync.unix.backend=nss
> {code}
> The high number and rate of these sessions makes it impossible to use the 
> "Login Sessions" audit page:
> Further, it's adding a lot of extra requests and overhead to Ranger, Ranger 
> User Sync, and the backing database (e.g. MySQL).
> *The service should re-use its session rather than continual logins.*
> !screenshot-1.png|width=640!
> {code}
> MariaDB [ranger]> select count(*),DATE(create_time) as date from x_auth_sess 
> where login_id='rangerusersync' group by DATE(create_time) order by date desc 
> limit 10;
> +--++
> | count(*) | date   |
> +--++
> | 3558 | 2018-03-14 |
> | 8520 | 2018-03-13 |
> | 8514 | 2018-03-12 |
> | 8508 | 2018-03-11 |
> | 8520 | 2018-03-10 |
> | 8523 | 2018-03-09 |
> | 8532 | 2018-03-08 |
> | 8522 | 2018-03-07 |
> | 8528 | 2018-03-06 |
> | 8520 | 2018-03-05 |
> +--++
> 10 rows in set (0.13 sec)
> {code}
> {code}
> $ rpm -qa *usersync*
> ranger_2_6_4_0_91-usersync-0.7.0.2.6.4.0-91.x86_64
> {code}



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

[jira] [Created] (RANGER-2020) Mandatory values are not filled then also able to create atlas policy

2018-03-14 Thread Nixon Rodrigues (JIRA)

Nixon Rodrigues created RANGER-2020:
---

 Summary: Mandatory values are not filled then also able to create 
atlas policy
 Key: RANGER-2020
 URL: https://issues.apache.org/jira/browse/RANGER-2020
 Project: Ranger
  Issue Type: Bug
  Components: admin
Affects Versions: 1.1.0
Reporter: Nixon Rodrigues
Assignee: Nixon Rodrigues
 Fix For: 1.1.0


Steps to reproduce:-

try to create a ranger policy for Atlas without giving the mandatory fields:
eg: type-name, entity classification, entity name etc.

but then also ranger policy creation is allowed



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

[jira] [Created] (RANGER-2021) Ranger "Login Sessions" Audits impossible to browse due to 'rangerusersync'

2018-03-14 Thread Sean Roberts (JIRA)

Sean Roberts created RANGER-2021:


 Summary: Ranger "Login Sessions" Audits impossible to browse due 
to 'rangerusersync'
 Key: RANGER-2021
 URL: https://issues.apache.org/jira/browse/RANGER-2021
 Project: Ranger
  Issue Type: Bug
  Components: usersync
Affects Versions: 0.7.0
Reporter: Sean Roberts


"Ranger User Sync" logs into Ranger multiple times a second.

The high number and rate of these sessions makes it impossible to use the 
"Login Sessions" audit page.

Further, it's adding a lot of extra requests and overhead to Ranger, Ranger 
User Sync, and the backing database (e.g. MySQL).

The service should re-use its session rather than continual logins.

{code}
$ rpm -qa *usersync*
ranger_2_6_4_0_91-usersync-0.7.0.2.6.4.0-91.x86_64
{code}



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

[jira] [Updated] (RANGER-2021) Ranger "Login Sessions" Audits impossible to browse due to 'rangerusersync'

2018-03-14 Thread Sean Roberts (JIRA)


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

Sean Roberts updated RANGER-2021:
-
Description: 
"Ranger User Sync" logs into Ranger multiple times a second. This is with unix 
sync with PAM.

The high number and rate of these sessions makes it impossible to use the 
"Login Sessions" audit page:

Further, it's adding a lot of extra requests and overhead to Ranger, Ranger 
User Sync, and the backing database (e.g. MySQL).

The service should re-use its session rather than continual logins.

{code}
MariaDB [ranger]> select count(*),DATE(create_time) as date from x_auth_sess 
where login_id='rangerusersync' group by DATE(create_time) order by date desc 
limit 10;
+--++
| count(*) | date   |
+--++
| 3558 | 2018-03-14 |
| 8520 | 2018-03-13 |
| 8514 | 2018-03-12 |
| 8508 | 2018-03-11 |
| 8520 | 2018-03-10 |
| 8523 | 2018-03-09 |
| 8532 | 2018-03-08 |
| 8522 | 2018-03-07 |
| 8528 | 2018-03-06 |
| 8520 | 2018-03-05 |
+--++
10 rows in set (0.13 sec)
{code}

 !screenshot-1.png! 

{code}
$ rpm -qa *usersync*
ranger_2_6_4_0_91-usersync-0.7.0.2.6.4.0-91.x86_64
{code}

  was:
"Ranger User Sync" logs into Ranger multiple times a second.

The high number and rate of these sessions makes it impossible to use the 
"Login Sessions" audit page:
 !screenshot-1.png! 

Further, it's adding a lot of extra requests and overhead to Ranger, Ranger 
User Sync, and the backing database (e.g. MySQL).

The service should re-use its session rather than continual logins.

{code}
$ rpm -qa *usersync*
ranger_2_6_4_0_91-usersync-0.7.0.2.6.4.0-91.x86_64
{code}


> Ranger "Login Sessions" Audits impossible to browse due to 'rangerusersync'
> ---
>
> Key: RANGER-2021
> URL: https://issues.apache.org/jira/browse/RANGER-2021
> Project: Ranger
>  Issue Type: Bug
>  Components: usersync
>Affects Versions: 0.7.0
>Reporter: Sean Roberts
>Priority: Major
> Attachments: screenshot-1.png
>
>
> "Ranger User Sync" logs into Ranger multiple times a second. This is with 
> unix sync with PAM.
> The high number and rate of these sessions makes it impossible to use the 
> "Login Sessions" audit page:
> Further, it's adding a lot of extra requests and overhead to Ranger, Ranger 
> User Sync, and the backing database (e.g. MySQL).
> The service should re-use its session rather than continual logins.
> {code}
> MariaDB [ranger]> select count(*),DATE(create_time) as date from x_auth_sess 
> where login_id='rangerusersync' group by DATE(create_time) order by date desc 
> limit 10;
> +--++
> | count(*) | date   |
> +--++
> | 3558 | 2018-03-14 |
> | 8520 | 2018-03-13 |
> | 8514 | 2018-03-12 |
> | 8508 | 2018-03-11 |
> | 8520 | 2018-03-10 |
> | 8523 | 2018-03-09 |
> | 8532 | 2018-03-08 |
> | 8522 | 2018-03-07 |
> | 8528 | 2018-03-06 |
> | 8520 | 2018-03-05 |
> +--++
> 10 rows in set (0.13 sec)
> {code}
>  !screenshot-1.png! 
> {code}
> $ rpm -qa *usersync*
> ranger_2_6_4_0_91-usersync-0.7.0.2.6.4.0-91.x86_64
> {code}



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

[jira] [Updated] (RANGER-2021) Ranger "Login Sessions" Audits impossible to browse due to 'rangerusersync'

2018-03-14 Thread Sean Roberts (JIRA)


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

Sean Roberts updated RANGER-2021:
-
Description: 
"Ranger User Sync" logs into Ranger multiple times a second. This is with:
{code}
ranger.usersync.source.impl.class=org.apache.ranger.unixusersync.process.UnixUserGroupBuilder
ranger.usersync.unix.backend=nss
{code}

The high number and rate of these sessions makes it impossible to use the 
"Login Sessions" audit page:

Further, it's adding a lot of extra requests and overhead to Ranger, Ranger 
User Sync, and the backing database (e.g. MySQL).

The service should re-use its session rather than continual logins.

!screenshot-1.png|thumbnail!

{code}
MariaDB [ranger]> select count(*),DATE(create_time) as date from x_auth_sess 
where login_id='rangerusersync' group by DATE(create_time) order by date desc 
limit 10;
+--++
| count(*) | date   |
+--++
| 3558 | 2018-03-14 |
| 8520 | 2018-03-13 |
| 8514 | 2018-03-12 |
| 8508 | 2018-03-11 |
| 8520 | 2018-03-10 |
| 8523 | 2018-03-09 |
| 8532 | 2018-03-08 |
| 8522 | 2018-03-07 |
| 8528 | 2018-03-06 |
| 8520 | 2018-03-05 |
+--++
10 rows in set (0.13 sec)
{code}

{code}
$ rpm -qa *usersync*
ranger_2_6_4_0_91-usersync-0.7.0.2.6.4.0-91.x86_64
{code}

  was:
"Ranger User Sync" logs into Ranger multiple times a second. This is with:
{code}
ranger.usersync.source.impl.class=org.apache.ranger.unixusersync.process.UnixUserGroupBuilder
ranger.usersync.unix.backend=nss
{code}

The high number and rate of these sessions makes it impossible to use the 
"Login Sessions" audit page:

Further, it's adding a lot of extra requests and overhead to Ranger, Ranger 
User Sync, and the backing database (e.g. MySQL).

The service should re-use its session rather than continual logins.

 !screenshot-1.png|thumbnail! 

{code}
MariaDB [ranger]> select count(*),DATE(create_time) as date from x_auth_sess 
where login_id='rangerusersync' group by DATE(create_time) order by date desc 
limit 10;
+--++
| count(*) | date   |
+--++
| 3558 | 2018-03-14 |
| 8520 | 2018-03-13 |
| 8514 | 2018-03-12 |
| 8508 | 2018-03-11 |
| 8520 | 2018-03-10 |
| 8523 | 2018-03-09 |
| 8532 | 2018-03-08 |
| 8522 | 2018-03-07 |
| 8528 | 2018-03-06 |
| 8520 | 2018-03-05 |
+--++
10 rows in set (0.13 sec)
{code}

{code}
$ rpm -qa *usersync*
ranger_2_6_4_0_91-usersync-0.7.0.2.6.4.0-91.x86_64
{code}


> Ranger "Login Sessions" Audits impossible to browse due to 'rangerusersync'
> ---
>
> Key: RANGER-2021
> URL: https://issues.apache.org/jira/browse/RANGER-2021
> Project: Ranger
>  Issue Type: Bug
>  Components: usersync
>Affects Versions: 0.7.0
>Reporter: Sean Roberts
>Priority: Major
> Attachments: screenshot-1.png
>
>
> "Ranger User Sync" logs into Ranger multiple times a second. This is with:
> {code}
> ranger.usersync.source.impl.class=org.apache.ranger.unixusersync.process.UnixUserGroupBuilder
> ranger.usersync.unix.backend=nss
> {code}
> The high number and rate of these sessions makes it impossible to use the 
> "Login Sessions" audit page:
> Further, it's adding a lot of extra requests and overhead to Ranger, Ranger 
> User Sync, and the backing database (e.g. MySQL).
> The service should re-use its session rather than continual logins.
> !screenshot-1.png|thumbnail!
> {code}
> MariaDB [ranger]> select count(*),DATE(create_time) as date from x_auth_sess 
> where login_id='rangerusersync' group by DATE(create_time) order by date desc 
> limit 10;
> +--++
> | count(*) | date   |
> +--++
> | 3558 | 2018-03-14 |
> | 8520 | 2018-03-13 |
> | 8514 | 2018-03-12 |
> | 8508 | 2018-03-11 |
> | 8520 | 2018-03-10 |
> | 8523 | 2018-03-09 |
> | 8532 | 2018-03-08 |
> | 8522 | 2018-03-07 |
> | 8528 | 2018-03-06 |
> | 8520 | 2018-03-05 |
> +--++
> 10 rows in set (0.13 sec)
> {code}
> {code}
> $ rpm -qa *usersync*
> ranger_2_6_4_0_91-usersync-0.7.0.2.6.4.0-91.x86_64
> {code}



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

[jira] [Updated] (RANGER-2021) Ranger "Login Sessions" Audits impossible to browse due to 'rangerusersync'

2018-03-14 Thread Sean Roberts (JIRA)


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

Sean Roberts updated RANGER-2021:
-
Description: 
"Ranger User Sync" logs into Ranger multiple times a second. This is with:
{code}
ranger.usersync.source.impl.class=org.apache.ranger.unixusersync.process.UnixUserGroupBuilder
ranger.usersync.unix.backend=nss
{code}

The high number and rate of these sessions makes it impossible to use the 
"Login Sessions" audit page:

Further, it's adding a lot of extra requests and overhead to Ranger, Ranger 
User Sync, and the backing database (e.g. MySQL).

The service should re-use its session rather than continual logins.

 !screenshot-1.png|thumbnail! 

{code}
MariaDB [ranger]> select count(*),DATE(create_time) as date from x_auth_sess 
where login_id='rangerusersync' group by DATE(create_time) order by date desc 
limit 10;
+--++
| count(*) | date   |
+--++
| 3558 | 2018-03-14 |
| 8520 | 2018-03-13 |
| 8514 | 2018-03-12 |
| 8508 | 2018-03-11 |
| 8520 | 2018-03-10 |
| 8523 | 2018-03-09 |
| 8532 | 2018-03-08 |
| 8522 | 2018-03-07 |
| 8528 | 2018-03-06 |
| 8520 | 2018-03-05 |
+--++
10 rows in set (0.13 sec)
{code}

{code}
$ rpm -qa *usersync*
ranger_2_6_4_0_91-usersync-0.7.0.2.6.4.0-91.x86_64
{code}

  was:
"Ranger User Sync" logs into Ranger multiple times a second. This is with:
{code}
ranger.usersync.source.impl.class=org.apache.ranger.unixusersync.process.UnixUserGroupBuilder
ranger.usersync.unix.backend=nss
{code}

The high number and rate of these sessions makes it impossible to use the 
"Login Sessions" audit page:

Further, it's adding a lot of extra requests and overhead to Ranger, Ranger 
User Sync, and the backing database (e.g. MySQL).

The service should re-use its session rather than continual logins.

 !screenshot-1.png!thumbnail! 

{code}
MariaDB [ranger]> select count(*),DATE(create_time) as date from x_auth_sess 
where login_id='rangerusersync' group by DATE(create_time) order by date desc 
limit 10;
+--++
| count(*) | date   |
+--++
| 3558 | 2018-03-14 |
| 8520 | 2018-03-13 |
| 8514 | 2018-03-12 |
| 8508 | 2018-03-11 |
| 8520 | 2018-03-10 |
| 8523 | 2018-03-09 |
| 8532 | 2018-03-08 |
| 8522 | 2018-03-07 |
| 8528 | 2018-03-06 |
| 8520 | 2018-03-05 |
+--++
10 rows in set (0.13 sec)
{code}

{code}
$ rpm -qa *usersync*
ranger_2_6_4_0_91-usersync-0.7.0.2.6.4.0-91.x86_64
{code}


> Ranger "Login Sessions" Audits impossible to browse due to 'rangerusersync'
> ---
>
> Key: RANGER-2021
> URL: https://issues.apache.org/jira/browse/RANGER-2021
> Project: Ranger
>  Issue Type: Bug
>  Components: usersync
>Affects Versions: 0.7.0
>Reporter: Sean Roberts
>Priority: Major
> Attachments: screenshot-1.png
>
>
> "Ranger User Sync" logs into Ranger multiple times a second. This is with:
> {code}
> ranger.usersync.source.impl.class=org.apache.ranger.unixusersync.process.UnixUserGroupBuilder
> ranger.usersync.unix.backend=nss
> {code}
> The high number and rate of these sessions makes it impossible to use the 
> "Login Sessions" audit page:
> Further, it's adding a lot of extra requests and overhead to Ranger, Ranger 
> User Sync, and the backing database (e.g. MySQL).
> The service should re-use its session rather than continual logins.
>  !screenshot-1.png|thumbnail! 
> {code}
> MariaDB [ranger]> select count(*),DATE(create_time) as date from x_auth_sess 
> where login_id='rangerusersync' group by DATE(create_time) order by date desc 
> limit 10;
> +--++
> | count(*) | date   |
> +--++
> | 3558 | 2018-03-14 |
> | 8520 | 2018-03-13 |
> | 8514 | 2018-03-12 |
> | 8508 | 2018-03-11 |
> | 8520 | 2018-03-10 |
> | 8523 | 2018-03-09 |
> | 8532 | 2018-03-08 |
> | 8522 | 2018-03-07 |
> | 8528 | 2018-03-06 |
> | 8520 | 2018-03-05 |
> +--++
> 10 rows in set (0.13 sec)
> {code}
> {code}
> $ rpm -qa *usersync*
> ranger_2_6_4_0_91-usersync-0.7.0.2.6.4.0-91.x86_64
> {code}



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

[jira] [Updated] (RANGER-2021) Ranger "Login Sessions" Audits impossible to browse due to 'rangerusersync'

2018-03-14 Thread Sean Roberts (JIRA)


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

Sean Roberts updated RANGER-2021:
-
Description: 
"Ranger User Sync" logs into Ranger multiple times a second. This is with:
{code}
ranger.usersync.source.impl.class=org.apache.ranger.unixusersync.process.UnixUserGroupBuilder
ranger.usersync.unix.backend=nss
{code}

The high number and rate of these sessions makes it impossible to use the 
"Login Sessions" audit page:

Further, it's adding a lot of extra requests and overhead to Ranger, Ranger 
User Sync, and the backing database (e.g. MySQL).

The service should re-use its session rather than continual logins.

 !screenshot-1.png!thumbnail! 

{code}
MariaDB [ranger]> select count(*),DATE(create_time) as date from x_auth_sess 
where login_id='rangerusersync' group by DATE(create_time) order by date desc 
limit 10;
+--++
| count(*) | date   |
+--++
| 3558 | 2018-03-14 |
| 8520 | 2018-03-13 |
| 8514 | 2018-03-12 |
| 8508 | 2018-03-11 |
| 8520 | 2018-03-10 |
| 8523 | 2018-03-09 |
| 8532 | 2018-03-08 |
| 8522 | 2018-03-07 |
| 8528 | 2018-03-06 |
| 8520 | 2018-03-05 |
+--++
10 rows in set (0.13 sec)
{code}

{code}
$ rpm -qa *usersync*
ranger_2_6_4_0_91-usersync-0.7.0.2.6.4.0-91.x86_64
{code}

  was:
"Ranger User Sync" logs into Ranger multiple times a second. This is with unix 
sync with PAM.

The high number and rate of these sessions makes it impossible to use the 
"Login Sessions" audit page:

Further, it's adding a lot of extra requests and overhead to Ranger, Ranger 
User Sync, and the backing database (e.g. MySQL).

The service should re-use its session rather than continual logins.

{code}
MariaDB [ranger]> select count(*),DATE(create_time) as date from x_auth_sess 
where login_id='rangerusersync' group by DATE(create_time) order by date desc 
limit 10;
+--++
| count(*) | date   |
+--++
| 3558 | 2018-03-14 |
| 8520 | 2018-03-13 |
| 8514 | 2018-03-12 |
| 8508 | 2018-03-11 |
| 8520 | 2018-03-10 |
| 8523 | 2018-03-09 |
| 8532 | 2018-03-08 |
| 8522 | 2018-03-07 |
| 8528 | 2018-03-06 |
| 8520 | 2018-03-05 |
+--++
10 rows in set (0.13 sec)
{code}

 !screenshot-1.png! 

{code}
$ rpm -qa *usersync*
ranger_2_6_4_0_91-usersync-0.7.0.2.6.4.0-91.x86_64
{code}


> Ranger "Login Sessions" Audits impossible to browse due to 'rangerusersync'
> ---
>
> Key: RANGER-2021
> URL: https://issues.apache.org/jira/browse/RANGER-2021
> Project: Ranger
>  Issue Type: Bug
>  Components: usersync
>Affects Versions: 0.7.0
>Reporter: Sean Roberts
>Priority: Major
> Attachments: screenshot-1.png
>
>
> "Ranger User Sync" logs into Ranger multiple times a second. This is with:
> {code}
> ranger.usersync.source.impl.class=org.apache.ranger.unixusersync.process.UnixUserGroupBuilder
> ranger.usersync.unix.backend=nss
> {code}
> The high number and rate of these sessions makes it impossible to use the 
> "Login Sessions" audit page:
> Further, it's adding a lot of extra requests and overhead to Ranger, Ranger 
> User Sync, and the backing database (e.g. MySQL).
> The service should re-use its session rather than continual logins.
>  !screenshot-1.png!thumbnail! 
> {code}
> MariaDB [ranger]> select count(*),DATE(create_time) as date from x_auth_sess 
> where login_id='rangerusersync' group by DATE(create_time) order by date desc 
> limit 10;
> +--++
> | count(*) | date   |
> +--++
> | 3558 | 2018-03-14 |
> | 8520 | 2018-03-13 |
> | 8514 | 2018-03-12 |
> | 8508 | 2018-03-11 |
> | 8520 | 2018-03-10 |
> | 8523 | 2018-03-09 |
> | 8532 | 2018-03-08 |
> | 8522 | 2018-03-07 |
> | 8528 | 2018-03-06 |
> | 8520 | 2018-03-05 |
> +--++
> 10 rows in set (0.13 sec)
> {code}
> {code}
> $ rpm -qa *usersync*
> ranger_2_6_4_0_91-usersync-0.7.0.2.6.4.0-91.x86_64
> {code}



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

[jira] [Updated] (RANGER-2021) Ranger "Login Sessions" Audits impossible to browse due to 'rangerusersync'

2018-03-14 Thread Sean Roberts (JIRA)


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

Sean Roberts updated RANGER-2021:
-
Description: 
"Ranger User Sync" logs into Ranger multiple times a second. This is with:
{code}
ranger.usersync.source.impl.class=org.apache.ranger.unixusersync.process.UnixUserGroupBuilder
ranger.usersync.unix.backend=nss
{code}

The high number and rate of these sessions makes it impossible to use the 
"Login Sessions" audit page:

Further, it's adding a lot of extra requests and overhead to Ranger, Ranger 
User Sync, and the backing database (e.g. MySQL).

The service should re-use its session rather than continual logins.

!screenshot-1.png|with=640!

{code}
MariaDB [ranger]> select count(*),DATE(create_time) as date from x_auth_sess 
where login_id='rangerusersync' group by DATE(create_time) order by date desc 
limit 10;
+--++
| count(*) | date   |
+--++
| 3558 | 2018-03-14 |
| 8520 | 2018-03-13 |
| 8514 | 2018-03-12 |
| 8508 | 2018-03-11 |
| 8520 | 2018-03-10 |
| 8523 | 2018-03-09 |
| 8532 | 2018-03-08 |
| 8522 | 2018-03-07 |
| 8528 | 2018-03-06 |
| 8520 | 2018-03-05 |
+--++
10 rows in set (0.13 sec)
{code}

{code}
$ rpm -qa *usersync*
ranger_2_6_4_0_91-usersync-0.7.0.2.6.4.0-91.x86_64
{code}

  was:
"Ranger User Sync" logs into Ranger multiple times a second. This is with:
{code}
ranger.usersync.source.impl.class=org.apache.ranger.unixusersync.process.UnixUserGroupBuilder
ranger.usersync.unix.backend=nss
{code}

The high number and rate of these sessions makes it impossible to use the 
"Login Sessions" audit page:

Further, it's adding a lot of extra requests and overhead to Ranger, Ranger 
User Sync, and the backing database (e.g. MySQL).

The service should re-use its session rather than continual logins.

!screenshot-1.png|thumbnail!

{code}
MariaDB [ranger]> select count(*),DATE(create_time) as date from x_auth_sess 
where login_id='rangerusersync' group by DATE(create_time) order by date desc 
limit 10;
+--++
| count(*) | date   |
+--++
| 3558 | 2018-03-14 |
| 8520 | 2018-03-13 |
| 8514 | 2018-03-12 |
| 8508 | 2018-03-11 |
| 8520 | 2018-03-10 |
| 8523 | 2018-03-09 |
| 8532 | 2018-03-08 |
| 8522 | 2018-03-07 |
| 8528 | 2018-03-06 |
| 8520 | 2018-03-05 |
+--++
10 rows in set (0.13 sec)
{code}

{code}
$ rpm -qa *usersync*
ranger_2_6_4_0_91-usersync-0.7.0.2.6.4.0-91.x86_64
{code}


> Ranger "Login Sessions" Audits impossible to browse due to 'rangerusersync'
> ---
>
> Key: RANGER-2021
> URL: https://issues.apache.org/jira/browse/RANGER-2021
> Project: Ranger
>  Issue Type: Bug
>  Components: usersync
>Affects Versions: 0.7.0
>Reporter: Sean Roberts
>Priority: Major
> Attachments: screenshot-1.png
>
>
> "Ranger User Sync" logs into Ranger multiple times a second. This is with:
> {code}
> ranger.usersync.source.impl.class=org.apache.ranger.unixusersync.process.UnixUserGroupBuilder
> ranger.usersync.unix.backend=nss
> {code}
> The high number and rate of these sessions makes it impossible to use the 
> "Login Sessions" audit page:
> Further, it's adding a lot of extra requests and overhead to Ranger, Ranger 
> User Sync, and the backing database (e.g. MySQL).
> The service should re-use its session rather than continual logins.
> !screenshot-1.png|with=640!
> {code}
> MariaDB [ranger]> select count(*),DATE(create_time) as date from x_auth_sess 
> where login_id='rangerusersync' group by DATE(create_time) order by date desc 
> limit 10;
> +--++
> | count(*) | date   |
> +--++
> | 3558 | 2018-03-14 |
> | 8520 | 2018-03-13 |
> | 8514 | 2018-03-12 |
> | 8508 | 2018-03-11 |
> | 8520 | 2018-03-10 |
> | 8523 | 2018-03-09 |
> | 8532 | 2018-03-08 |
> | 8522 | 2018-03-07 |
> | 8528 | 2018-03-06 |
> | 8520 | 2018-03-05 |
> +--++
> 10 rows in set (0.13 sec)
> {code}
> {code}
> $ rpm -qa *usersync*
> ranger_2_6_4_0_91-usersync-0.7.0.2.6.4.0-91.x86_64
> {code}



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

[jira] [Updated] (RANGER-2021) Ranger "Login Sessions" Audits impossible to browse due to 'rangerusersync'

2018-03-14 Thread Sean Roberts (JIRA)


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

Sean Roberts updated RANGER-2021:
-
Description: 
"Ranger User Sync" logs into Ranger multiple times a second. This is with:
{code}
ranger.usersync.source.impl.class=org.apache.ranger.unixusersync.process.UnixUserGroupBuilder
ranger.usersync.unix.backend=nss
{code}

The high number and rate of these sessions makes it impossible to use the 
"Login Sessions" audit page:

Further, it's adding a lot of extra requests and overhead to Ranger, Ranger 
User Sync, and the backing database (e.g. MySQL).

The service should re-use its session rather than continual logins.

!screenshot-1.png|width=640!

{code}
MariaDB [ranger]> select count(*),DATE(create_time) as date from x_auth_sess 
where login_id='rangerusersync' group by DATE(create_time) order by date desc 
limit 10;
+--++
| count(*) | date   |
+--++
| 3558 | 2018-03-14 |
| 8520 | 2018-03-13 |
| 8514 | 2018-03-12 |
| 8508 | 2018-03-11 |
| 8520 | 2018-03-10 |
| 8523 | 2018-03-09 |
| 8532 | 2018-03-08 |
| 8522 | 2018-03-07 |
| 8528 | 2018-03-06 |
| 8520 | 2018-03-05 |
+--++
10 rows in set (0.13 sec)
{code}

{code}
$ rpm -qa *usersync*
ranger_2_6_4_0_91-usersync-0.7.0.2.6.4.0-91.x86_64
{code}

  was:
"Ranger User Sync" logs into Ranger multiple times a second. This is with:
{code}
ranger.usersync.source.impl.class=org.apache.ranger.unixusersync.process.UnixUserGroupBuilder
ranger.usersync.unix.backend=nss
{code}

The high number and rate of these sessions makes it impossible to use the 
"Login Sessions" audit page:

Further, it's adding a lot of extra requests and overhead to Ranger, Ranger 
User Sync, and the backing database (e.g. MySQL).

The service should re-use its session rather than continual logins.

!screenshot-1.png|with=640!

{code}
MariaDB [ranger]> select count(*),DATE(create_time) as date from x_auth_sess 
where login_id='rangerusersync' group by DATE(create_time) order by date desc 
limit 10;
+--++
| count(*) | date   |
+--++
| 3558 | 2018-03-14 |
| 8520 | 2018-03-13 |
| 8514 | 2018-03-12 |
| 8508 | 2018-03-11 |
| 8520 | 2018-03-10 |
| 8523 | 2018-03-09 |
| 8532 | 2018-03-08 |
| 8522 | 2018-03-07 |
| 8528 | 2018-03-06 |
| 8520 | 2018-03-05 |
+--++
10 rows in set (0.13 sec)
{code}

{code}
$ rpm -qa *usersync*
ranger_2_6_4_0_91-usersync-0.7.0.2.6.4.0-91.x86_64
{code}


> Ranger "Login Sessions" Audits impossible to browse due to 'rangerusersync'
> ---
>
> Key: RANGER-2021
> URL: https://issues.apache.org/jira/browse/RANGER-2021
> Project: Ranger
>  Issue Type: Bug
>  Components: usersync
>Affects Versions: 0.7.0
>Reporter: Sean Roberts
>Priority: Major
> Attachments: screenshot-1.png
>
>
> "Ranger User Sync" logs into Ranger multiple times a second. This is with:
> {code}
> ranger.usersync.source.impl.class=org.apache.ranger.unixusersync.process.UnixUserGroupBuilder
> ranger.usersync.unix.backend=nss
> {code}
> The high number and rate of these sessions makes it impossible to use the 
> "Login Sessions" audit page:
> Further, it's adding a lot of extra requests and overhead to Ranger, Ranger 
> User Sync, and the backing database (e.g. MySQL).
> The service should re-use its session rather than continual logins.
> !screenshot-1.png|width=640!
> {code}
> MariaDB [ranger]> select count(*),DATE(create_time) as date from x_auth_sess 
> where login_id='rangerusersync' group by DATE(create_time) order by date desc 
> limit 10;
> +--++
> | count(*) | date   |
> +--++
> | 3558 | 2018-03-14 |
> | 8520 | 2018-03-13 |
> | 8514 | 2018-03-12 |
> | 8508 | 2018-03-11 |
> | 8520 | 2018-03-10 |
> | 8523 | 2018-03-09 |
> | 8532 | 2018-03-08 |
> | 8522 | 2018-03-07 |
> | 8528 | 2018-03-06 |
> | 8520 | 2018-03-05 |
> +--++
> 10 rows in set (0.13 sec)
> {code}
> {code}
> $ rpm -qa *usersync*
> ranger_2_6_4_0_91-usersync-0.7.0.2.6.4.0-91.x86_64
> {code}



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

[jira] [Updated] (RANGER-2021) Ranger "Login Sessions" Audits impossible to browse due to 'rangerusersync'

2018-03-14 Thread Sean Roberts (JIRA)


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

Sean Roberts updated RANGER-2021:
-
Description: 
"Ranger User Sync" logs into Ranger multiple times a second. This is with:
{code}
ranger.usersync.source.impl.class=org.apache.ranger.unixusersync.process.UnixUserGroupBuilder
ranger.usersync.unix.backend=nss
{code}

The high number and rate of these sessions makes it impossible to use the 
"Login Sessions" audit page:

Further, it's adding a lot of extra requests and overhead to Ranger, Ranger 
User Sync, and the backing database (e.g. MySQL).

*The service should re-use its session rather than continual logins.*

!screenshot-1.png|width=640!

{code}
$ rpm -qa *usersync*
ranger_2_6_4_0_91-usersync-0.7.0.2.6.4.0-91.x86_64
{code}

  was:
"Ranger User Sync" logs into Ranger multiple times a second. This is with:
{code}
ranger.usersync.source.impl.class=org.apache.ranger.unixusersync.process.UnixUserGroupBuilder
ranger.usersync.unix.backend=nss
{code}

The high number and rate of these sessions makes it impossible to use the 
"Login Sessions" audit page:

Further, it's adding a lot of extra requests and overhead to Ranger, Ranger 
User Sync, and the backing database (e.g. MySQL).

*The service should re-use its session rather than continual logins.*

!screenshot-1.png|width=640!

{code}
MariaDB [ranger]> select count(*),DATE(create_time) as date from x_auth_sess 
where login_id='rangerusersync' group by DATE(create_time) order by date desc 
limit 10;
+--++
| count(*) | date   |
+--++
| 3558 | 2018-03-14 |
| 8520 | 2018-03-13 |
| 8514 | 2018-03-12 |
| 8508 | 2018-03-11 |
| 8520 | 2018-03-10 |
| 8523 | 2018-03-09 |
| 8532 | 2018-03-08 |
| 8522 | 2018-03-07 |
| 8528 | 2018-03-06 |
| 8520 | 2018-03-05 |
+--++
10 rows in set (0.13 sec)
{code}

{code}
$ rpm -qa *usersync*
ranger_2_6_4_0_91-usersync-0.7.0.2.6.4.0-91.x86_64
{code}


> Ranger "Login Sessions" Audits impossible to browse due to 'rangerusersync'
> ---
>
> Key: RANGER-2021
> URL: https://issues.apache.org/jira/browse/RANGER-2021
> Project: Ranger
>  Issue Type: Bug
>  Components: usersync
>Affects Versions: 0.7.0
>Reporter: Sean Roberts
>Priority: Major
> Attachments: screenshot-1.png
>
>
> "Ranger User Sync" logs into Ranger multiple times a second. This is with:
> {code}
> ranger.usersync.source.impl.class=org.apache.ranger.unixusersync.process.UnixUserGroupBuilder
> ranger.usersync.unix.backend=nss
> {code}
> The high number and rate of these sessions makes it impossible to use the 
> "Login Sessions" audit page:
> Further, it's adding a lot of extra requests and overhead to Ranger, Ranger 
> User Sync, and the backing database (e.g. MySQL).
> *The service should re-use its session rather than continual logins.*
> !screenshot-1.png|width=640!
> {code}
> $ rpm -qa *usersync*
> ranger_2_6_4_0_91-usersync-0.7.0.2.6.4.0-91.x86_64
> {code}



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

[jira] [Updated] (RANGER-2021) Ranger "Login Sessions" Audits impossible to browse due to 'rangerusersync'

2018-03-14 Thread Sean Roberts (JIRA)


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

Sean Roberts updated RANGER-2021:
-
Attachment: screenshot-1.png

> Ranger "Login Sessions" Audits impossible to browse due to 'rangerusersync'
> ---
>
> Key: RANGER-2021
> URL: https://issues.apache.org/jira/browse/RANGER-2021
> Project: Ranger
>  Issue Type: Bug
>  Components: usersync
>Affects Versions: 0.7.0
>Reporter: Sean Roberts
>Priority: Major
> Attachments: screenshot-1.png
>
>
> "Ranger User Sync" logs into Ranger multiple times a second.
> The high number and rate of these sessions makes it impossible to use the 
> "Login Sessions" audit page.
> Further, it's adding a lot of extra requests and overhead to Ranger, Ranger 
> User Sync, and the backing database (e.g. MySQL).
> The service should re-use its session rather than continual logins.
> {code}
> $ rpm -qa *usersync*
> ranger_2_6_4_0_91-usersync-0.7.0.2.6.4.0-91.x86_64
> {code}



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

Review Request 66061: RANGER-2020 - Mandatory values are not filled then also able to create atlas policy

2018-03-14 Thread Nixon Rodrigues


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

Review request for ranger, Madhan Neethiraj, Mehul Parikh, Nitin Galave, and 
Pradeep Agrawal.


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


Repository: ranger


Description
---

This patch includes changes in ranger-servicedef-atlas.json to add mandatory 
property as true.


Diffs
-

  agents-common/src/main/resources/service-defs/ranger-servicedef-atlas.json 
52371257 


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


Testing
---

Deleted existing atlas-servicedef and added the updated servicedef and tested 
creating policies 
without values, the UI validation is now preventing from submiting the form.


Thanks,

Nixon Rodrigues

[jira] [Updated] (RANGER-2020) Mandatory values are not filled then also able to create atlas policy

2018-03-14 Thread Nixon Rodrigues (JIRA)


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

Nixon Rodrigues updated RANGER-2020:

Attachment: RANGER-2020.patch

> Mandatory values are not filled then also able to create atlas policy
> -
>
> Key: RANGER-2020
> URL: https://issues.apache.org/jira/browse/RANGER-2020
> Project: Ranger
>  Issue Type: Bug
>  Components: admin
>Affects Versions: 1.1.0
>Reporter: Nixon Rodrigues
>Assignee: Nixon Rodrigues
>Priority: Major
> Fix For: 1.1.0
>
> Attachments: RANGER-2020.patch
>
>
> Steps to reproduce:-
> try to create a ranger policy for Atlas without giving the mandatory fields:
> eg: type-name, entity classification, entity name etc.
> but then also ranger policy creation is allowed



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

[VOTE] Apache Ranger Release 1.0.0-rc1

2018-03-14 Thread Sailaja Polavarapu

Rangers:
Thank you for your contribution to Apache Ranger community. Apache Ranger 1.0.0 
release candidate #1 is now available for a vote within dev community. Links to 
release artifacts are given below. I kindly request all of the Rangers (dev & 
PMC members) to review and vote on this release.

Git tag for the release:

https://github.com/apache/ranger/tree/release-1.0.0-rc1 (last commit id:  
c79aad4362b6f806da47462ec84e35108ba8eb1f)


Sources for the release:
https://dist.apache.org/repos/dist/dev/ranger/1.0.0-rc1/apache-ranger-1.0.0.tar.gz


Source release verification:

PGP Signature:

https://dist.apache.org/repos/dist/dev/ranger/1.0.0-rc1/apache-ranger-1.0.0.tar.gz.asc


MD5/SHA Hash:

https://dist.apache.org/repos/dist/dev/ranger/1.0.0-rc1/apache-ranger-1.0.0.tar.gz.mds


Keys to verify the signature of the release artifact are available at:

https://dist.apache.org/repos/dist/release/ranger/KEYS


Release Notes:

   https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=75975356


Build verification steps can be found at:

   http://ranger.apache.org/quick_start_guide.html


The vote will be open for at least 72 hours or until necessary number of votes 
are reached.
[ ] +1  approve
[ ] +0  no opinion
[ ] -1  disapprove (and reason why)

Here is my +1

Thanks,
Sailaja.

Re: Review Request 65978: RANGER-2013 : Restrict updation of user source

2018-03-14 Thread Velmurugan Periasamy


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


Ship it!




Ship It!

- Velmurugan Periasamy


On March 8, 2018, 7:18 a.m., Fatima Khan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/65978/
> ---
> 
> (Updated March 8, 2018, 7:18 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-2013
> https://issues.apache.org/jira/browse/RANGER-2013
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> Improvise validation in user profile to handle retention of original user 
> source.
> 
> 
> Diffs
> -
> 
>   security-admin/src/main/java/org/apache/ranger/biz/XUserMgr.java 487fefa 
> 
> 
> Diff: https://reviews.apache.org/r/65978/diff/3/
> 
> 
> Testing
> ---
> 
> Tested and validated the update user Api.
> 
> 
> Thanks,
> 
> Fatima Khan
> 
>

Re: Review Request 65914: RANGER 1948 : Support for Read-only Ranger Admin users

2018-03-14 Thread Velmurugan Periasamy


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


Ship it!




Ship It!

- Velmurugan Periasamy


On March 13, 2018, 1:43 p.m., Fatima Khan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/65914/
> ---
> 
> (Updated March 13, 2018, 1:43 p.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-1948
> https://issues.apache.org/jira/browse/RANGER-1948
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> This Jira is to cater to need of Auditor roles in Ranger Admin.  
> 
> We can introduce Auditor Roles for both the Administrator Roles in Ranger 
> Admin. 
> * Auditor (Readonly privileges from current Admin role user )
> * KMS Auditor (Readonly privileges from current Keydmin role user )
> 
> 
> Diffs
> -
> 
>   security-admin/scripts/rolebasedusersearchutil.py d651461 
>   security-admin/src/main/java/org/apache/ranger/biz/AssetMgr.java 15937c7 
>   security-admin/src/main/java/org/apache/ranger/biz/KmsKeyMgr.java 03bcb60 
>   security-admin/src/main/java/org/apache/ranger/biz/RangerBizUtil.java 
> 224f1a0 
>   security-admin/src/main/java/org/apache/ranger/biz/ServiceDBStore.java 
> ecde444 
>   security-admin/src/main/java/org/apache/ranger/biz/ServiceMgr.java a989c84 
>   security-admin/src/main/java/org/apache/ranger/biz/SessionMgr.java 9eb8f1f 
>   security-admin/src/main/java/org/apache/ranger/biz/UserMgr.java a110035 
>   security-admin/src/main/java/org/apache/ranger/biz/XAuditMgr.java c2fac0b 
>   security-admin/src/main/java/org/apache/ranger/biz/XUserMgr.java 487fefa 
>   security-admin/src/main/java/org/apache/ranger/common/RangerConstants.java 
> e31e9d7 
>   security-admin/src/main/java/org/apache/ranger/common/UserSessionBase.java 
> bcf9080 
>   
> security-admin/src/main/java/org/apache/ranger/patch/cliutil/RoleBasedUserSearchUtil.java
>  d3a28f7 
>   security-admin/src/main/java/org/apache/ranger/rest/AssetREST.java 9f7cd26 
>   security-admin/src/main/java/org/apache/ranger/rest/ServiceREST.java 
> 229863e 
>   security-admin/src/main/java/org/apache/ranger/rest/XUserREST.java c81a6f3 
>   
> security-admin/src/main/java/org/apache/ranger/security/context/RangerPreAuthSecurityHandler.java
>  6951cbd 
>   security-admin/src/main/java/org/apache/ranger/service/XTrxLogService.java 
> 4227d85 
>   security-admin/src/main/resources/conf.dist/ranger-admin-default-site.xml 
> 87da9a0 
>   security-admin/src/test/java/org/apache/ranger/biz/TestUserMgr.java 4a8d88f 
>   unixauthservice/scripts/install.properties be8723c 
> 
> 
> Diff: https://reviews.apache.org/r/65914/diff/5/
> 
> 
> Testing
> ---
> 
> Tested scenario's:
> 1.Tested admin user is able to create User role user.
> 2.Tested admin user is able to create Auditor role user.
> 3.Tested admin user is not able to create kms auditor role user.
> 4.Tested keyadmin user is able to create kms auditor.
> 5.Tested auditor is able to only view policies, users, services and audits.
> 6.Tested kms auditor is able to only view policies, users, services, audits 
> and keys.
> 7.Tested auditor is able to see permission tab but kms auditor should not see 
> permission tab.
> 8.Auditor role users are  not allowed to import/export policies
> 9.Verified syncing of users from auditor role :: if we add them in properties 
> install.properties of usersync during initial start of usersync.Property 
> value in install.properties will be GROUP_BASED_ROLE_ASSIGNMENT_RULES= 
> _ADMIN_AUDITOR:u:userName_KEY_ADMIN_AUDITOR:u:userName_KEY_ADMIN_AUDITOR:g:groupName_ADMIN_AUDITOR:g:groupName
> 
> 
> Thanks,
> 
> Fatima Khan
> 
>

Re: [VOTE] Apache Ranger Release 1.0.0-rc1

2018-03-14 Thread Jianhua Peng

+1

On 2018/03/15 01:27:31, Sailaja Polavarapu  wrote: 
> Rangers:
> Thank you for your contribution to Apache Ranger community. Apache Ranger 
> 1.0.0 release candidate #1 is now available for a vote within dev community. 
> Links to release artifacts are given below. I kindly request all of the 
> Rangers (dev & PMC members) to review and vote on this release.
> 
> Git tag for the release:
> 
> https://github.com/apache/ranger/tree/release-1.0.0-rc1 (last commit id:  
> c79aad4362b6f806da47462ec84e35108ba8eb1f)
> 
> 
> Sources for the release:
> https://dist.apache.org/repos/dist/dev/ranger/1.0.0-rc1/apache-ranger-1.0.0.tar.gz
> 
> 
> Source release verification:
> 
> PGP Signature:
> 
> https://dist.apache.org/repos/dist/dev/ranger/1.0.0-rc1/apache-ranger-1.0.0.tar.gz.asc
> 
> 
> MD5/SHA Hash:
> 
> https://dist.apache.org/repos/dist/dev/ranger/1.0.0-rc1/apache-ranger-1.0.0.tar.gz.mds
> 
> 
> Keys to verify the signature of the release artifact are available at:
> 
> https://dist.apache.org/repos/dist/release/ranger/KEYS
> 
> 
> Release Notes:
> 
>https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=75975356
> 
> 
> Build verification steps can be found at:
> 
>http://ranger.apache.org/quick_start_guide.html
> 
> 
> The vote will be open for at least 72 hours or until necessary number of 
> votes are reached.
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
> 
> Here is my +1
> 
> Thanks,
> Sailaja.
> 
>

Re: Review Request 66061: RANGER-2020 - Mandatory values are not filled then also able to create atlas policy

2018-03-14 Thread Velmurugan Periasamy


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


Ship it!




Ship It!

- Velmurugan Periasamy


On March 14, 2018, 10:16 a.m., Nixon Rodrigues wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66061/
> ---
> 
> (Updated March 14, 2018, 10:16 a.m.)
> 
> 
> Review request for ranger, Madhan Neethiraj, Mehul Parikh, Nitin Galave, and 
> Pradeep Agrawal.
> 
> 
> Bugs: RANGER-2020
> https://issues.apache.org/jira/browse/RANGER-2020
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> This patch includes changes in ranger-servicedef-atlas.json to add mandatory 
> property as true.
> 
> 
> Diffs
> -
> 
>   agents-common/src/main/resources/service-defs/ranger-servicedef-atlas.json 
> 52371257 
> 
> 
> Diff: https://reviews.apache.org/r/66061/diff/1/
> 
> 
> Testing
> ---
> 
> Deleted existing atlas-servicedef and added the updated servicedef and tested 
> creating policies 
> without values, the UI validation is now preventing from submiting the form.
> 
> 
> Thanks,
> 
> Nixon Rodrigues
> 
>

Re: Review Request 66036: RANGER-1496 : Excel/csv exported file should have complete details of the policy

2018-03-14 Thread Velmurugan Periasamy


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


Ship it!




Ship It!

- Velmurugan Periasamy


On March 13, 2018, 12:04 p.m., Fatima Khan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66036/
> ---
> 
> (Updated March 13, 2018, 12:04 p.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-1496
> https://issues.apache.org/jira/browse/RANGER-1496
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> If export of the policy is done from the Reports page in excel/csv format 
> then we are not showing info like Isaudit enabled, delegate admin and row 
> filter and masking condition etc .
> Add following fields in exported excel / csv files : 
> 
> * policyType
> * delegateAdmin
> * isRecursiveValue
> * isExcludesValue
> * serviceName
> * description
> * isAuditEnabled
> * conditionKeyValue
> * policyConditionTypeValue
> * maskingInfo
> * filterExpr
> * policyLabel
> 
> 
> Diffs
> -
> 
>   security-admin/src/main/java/org/apache/ranger/biz/ServiceDBStore.java 
> ecde444 
> 
> 
> Diff: https://reviews.apache.org/r/66036/diff/1/
> 
> 
> Testing
> ---
> 
> Tested and validated the exported Excel.
> Tested and validated the exported CSV.
> 
> 
> Thanks,
> 
> Fatima Khan
> 
>

Re: Review Request 66072: RANGER-2022 - Atlas plugin install.properties is missing component location

2018-03-14 Thread Velmurugan Periasamy


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


Ship it!




Ship It!

- Velmurugan Periasamy


On March 14, 2018, 5:48 p.m., Colm O hEigeartaigh wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66072/
> ---
> 
> (Updated March 14, 2018, 5:48 p.m.)
> 
> 
> Review request for ranger.
> 
> 
> Bugs: RANGER-2022
> https://issues.apache.org/jira/browse/RANGER-2022
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> The Atlas plugin install.properties is missing the component location.
> 
> 
> Diffs
> -
> 
>   plugin-atlas/scripts/install.properties 0962ab07 
> 
> 
> Diff: https://reviews.apache.org/r/66072/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Colm O hEigeartaigh
> 
>

[jira] [Commented] (RANGER-2006) Fix problems detected by static code analysis in ranger usersync for ldap sync source

2018-03-14 Thread Velmurugan Periasamy (JIRA)


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

Velmurugan Periasamy commented on RANGER-2006:
--

[~spolavarapu] - +1 for the proposal to revert. 

> Fix problems detected by static code analysis in ranger usersync for ldap 
> sync source
> -
>
> Key: RANGER-2006
> URL: https://issues.apache.org/jira/browse/RANGER-2006
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger, usersync
>Affects Versions: 0.7.1
>Reporter: Sailaja Polavarapu
>Assignee: Sailaja Polavarapu
>Priority: Minor
> Fix For: 1.0.0, master
>
>
> 1. *Overview* : The method goUpGroupHierarchyLdap() invokes a dynamically 
> generated LDAP filter with unvalidated input, which could allow an attacker 
> to modify the statement's meaning.
> In the file LdapDeltaUserGroupBuilder.java similar issues were on line 
> numbers 913
> *Comments* : need to verify the search() parameters for validation
> 2. *Overview* : The method goUpGroupHierarchyLdap() invokes a dynamically 
> generated LDAP filter with unvalidated input, which could allow an attacker 
> to modify the statement's meaning.
> In the file LdapUserGroupBuilder.java similar issues were on line numbers 818
> *Comments* : need to verify the search() parameters for validation



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

Re: [VOTE] Apache Ranger Release 1.0.0-rc1

2018-03-14 Thread Qiang Zhang

+1

On 2018/03/15 01:27:31, Sailaja Polavarapu  wrote: 
> Rangers:
> Thank you for your contribution to Apache Ranger community. Apache Ranger 
> 1.0.0 release candidate #1 is now available for a vote within dev community. 
> Links to release artifacts are given below. I kindly request all of the 
> Rangers (dev & PMC members) to review and vote on this release.
> 
> Git tag for the release:
> 
> https://github.com/apache/ranger/tree/release-1.0.0-rc1 (last commit id:  
> c79aad4362b6f806da47462ec84e35108ba8eb1f)
> 
> 
> Sources for the release:
> https://dist.apache.org/repos/dist/dev/ranger/1.0.0-rc1/apache-ranger-1.0.0.tar.gz
> 
> 
> Source release verification:
> 
> PGP Signature:
> 
> https://dist.apache.org/repos/dist/dev/ranger/1.0.0-rc1/apache-ranger-1.0.0.tar.gz.asc
> 
> 
> MD5/SHA Hash:
> 
> https://dist.apache.org/repos/dist/dev/ranger/1.0.0-rc1/apache-ranger-1.0.0.tar.gz.mds
> 
> 
> Keys to verify the signature of the release artifact are available at:
> 
> https://dist.apache.org/repos/dist/release/ranger/KEYS
> 
> 
> Release Notes:
> 
>https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=75975356
> 
> 
> Build verification steps can be found at:
> 
>http://ranger.apache.org/quick_start_guide.html
> 
> 
> The vote will be open for at least 72 hours or until necessary number of 
> votes are reached.
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
> 
> Here is my +1
> 
> Thanks,
> Sailaja.
> 
>

Re: Review Request 65978: RANGER-2013 : Restrict updation of user source

2018-03-14 Thread Velmurugan Periasamy



> On March 15, 2018, 2:26 a.m., Velmurugan Periasamy wrote:
> > Ship It!

Please fix the comment before committing.


- Velmurugan


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


On March 8, 2018, 7:18 a.m., Fatima Khan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/65978/
> ---
> 
> (Updated March 8, 2018, 7:18 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-2013
> https://issues.apache.org/jira/browse/RANGER-2013
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> Improvise validation in user profile to handle retention of original user 
> source.
> 
> 
> Diffs
> -
> 
>   security-admin/src/main/java/org/apache/ranger/biz/XUserMgr.java 487fefa 
> 
> 
> Diff: https://reviews.apache.org/r/65978/diff/3/
> 
> 
> Testing
> ---
> 
> Tested and validated the update user Api.
> 
> 
> Thanks,
> 
> Fatima Khan
> 
>

[jira] [Resolved] (RANGER-2006) Fix problems detected by static code analysis in ranger usersync for ldap sync source

2018-03-14 Thread Sailaja Polavarapu (JIRA)


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

Sailaja Polavarapu resolved RANGER-2006.

Resolution: Fixed

Reverted changes from both ranger-1.0 branch and master

> Fix problems detected by static code analysis in ranger usersync for ldap 
> sync source
> -
>
> Key: RANGER-2006
> URL: https://issues.apache.org/jira/browse/RANGER-2006
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger, usersync
>Affects Versions: 0.7.1
>Reporter: Sailaja Polavarapu
>Assignee: Sailaja Polavarapu
>Priority: Minor
> Fix For: 1.0.0, master
>
>
> 1. *Overview* : The method goUpGroupHierarchyLdap() invokes a dynamically 
> generated LDAP filter with unvalidated input, which could allow an attacker 
> to modify the statement's meaning.
> In the file LdapDeltaUserGroupBuilder.java similar issues were on line 
> numbers 913
> *Comments* : need to verify the search() parameters for validation
> 2. *Overview* : The method goUpGroupHierarchyLdap() invokes a dynamically 
> generated LDAP filter with unvalidated input, which could allow an attacker 
> to modify the statement's meaning.
> In the file LdapUserGroupBuilder.java similar issues were on line numbers 818
> *Comments* : need to verify the search() parameters for validation



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

Re: Review Request 66072: RANGER-2022 - Atlas plugin install.properties is missing component location

2018-03-14 Thread Madhan Neethiraj


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


Ship it!




Ship It!

- Madhan Neethiraj


On March 14, 2018, 5:48 p.m., Colm O hEigeartaigh wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66072/
> ---
> 
> (Updated March 14, 2018, 5:48 p.m.)
> 
> 
> Review request for ranger.
> 
> 
> Bugs: RANGER-2022
> https://issues.apache.org/jira/browse/RANGER-2022
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> The Atlas plugin install.properties is missing the component location.
> 
> 
> Diffs
> -
> 
>   plugin-atlas/scripts/install.properties 0962ab07 
> 
> 
> Diff: https://reviews.apache.org/r/66072/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Colm O hEigeartaigh
> 
>

Some recent commits missing from master

2018-03-14 Thread Colm O hEigeartaigh

Hi all,

A few recent commits appear to have been made directly onto the 1.0 branch
instead of to master and then backporting

commit 3d341a4c2429cae259b831b112c6d65eaa12a2e1 (tag: release-1.0.0-rc0,
origin/ranger-1.0, ranger-1.0)
Author: pradeep 
Date:   Sat Mar 10 15:28:40 2018 +0530

RANGER-1991: Import policy failure fix caused by static code analysis
fix

commit 79d177be7bc6d511e8902d963802c9550608bebf
Author: ni3galave 
Date:   Sat Mar 10 20:35:25 2018 +0530

RANGER-2014: Unable to see policy detail in view policy mode after
updating recursive flag

Signed-off-by: pradeep 



-- 
Colm O hEigeartaigh

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

Review Request 66073: Create transaction log when policy validity schedule is updated

2018-03-14 Thread Abhay Kulkarni


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

Review request for ranger, Madhan Neethiraj, Nitin Galave, and Velmurugan 
Periasamy.


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


Repository: ranger


Description
---

Create transaction log for policy update when policy validity schedule is 
updated


Diffs
-

  
security-admin/src/main/java/org/apache/ranger/service/RangerPolicyService.java 
fb693e303 


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


Testing
---

Tested with local VM


Thanks,

Abhay Kulkarni

Review Request 66072: RANGER-2022 - Atlas plugin install.properties is missing component location

2018-03-14 Thread Colm O hEigeartaigh


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

Review request for ranger.


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


Repository: ranger


Description
---

The Atlas plugin install.properties is missing the component location.


Diffs
-

  plugin-atlas/scripts/install.properties 0962ab07 


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


Testing
---


Thanks,

Colm O hEigeartaigh

[jira] [Updated] (RANGER-2022) Atlas plugin install.properties is missing component location

2018-03-14 Thread Colm O hEigeartaigh (JIRA)


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

Colm O hEigeartaigh updated RANGER-2022:

Attachment: 0001-RANGER-2022-Atlas-plugin-install.properties-is-missi.patch

> Atlas plugin install.properties is missing component location
> -
>
> Key: RANGER-2022
> URL: https://issues.apache.org/jira/browse/RANGER-2022
> Project: Ranger
>  Issue Type: Improvement
>  Components: plugins
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
>Priority: Minor
> Fix For: 1.1.0
>
> Attachments: 
> 0001-RANGER-2022-Atlas-plugin-install.properties-is-missi.patch
>
>
> The Atlas plugin install.properties is missing the component location.



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

[jira] [Created] (RANGER-2022) Atlas plugin install.properties is missing component location

2018-03-14 Thread Colm O hEigeartaigh (JIRA)

Colm O hEigeartaigh created RANGER-2022:
---

 Summary: Atlas plugin install.properties is missing component 
location
 Key: RANGER-2022
 URL: https://issues.apache.org/jira/browse/RANGER-2022
 Project: Ranger
  Issue Type: Improvement
  Components: plugins
Reporter: Colm O hEigeartaigh
Assignee: Colm O hEigeartaigh
 Fix For: 1.1.0


The Atlas plugin install.properties is missing the component location.



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

Re: Review Request 66073: Create transaction log when policy validity schedule is updated

2018-03-14 Thread Madhan Neethiraj


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


Ship it!




Ship It!

- Madhan Neethiraj


On March 14, 2018, 5:58 p.m., Abhay Kulkarni wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66073/
> ---
> 
> (Updated March 14, 2018, 5:58 p.m.)
> 
> 
> Review request for ranger, Madhan Neethiraj, Nitin Galave, and Velmurugan 
> Periasamy.
> 
> 
> Bugs: RANGER-2000
> https://issues.apache.org/jira/browse/RANGER-2000
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> Create transaction log for policy update when policy validity schedule is 
> updated
> 
> 
> Diffs
> -
> 
>   
> security-admin/src/main/java/org/apache/ranger/service/RangerPolicyService.java
>  fb693e303 
> 
> 
> Diff: https://reviews.apache.org/r/66073/diff/1/
> 
> 
> Testing
> ---
> 
> Tested with local VM
> 
> 
> Thanks,
> 
> Abhay Kulkarni
> 
>

Re: Review Request 65920: Ranger Tagsync should use cookie based authentication for subsequent requests to Ranger admin

2018-03-14 Thread Velmurugan Periasamy


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


Ship it!




Ship It!

- Velmurugan Periasamy


On March 14, 2018, 6:31 a.m., Nikhil P wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/65920/
> ---
> 
> (Updated March 14, 2018, 6:31 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-2010
> https://issues.apache.org/jira/browse/RANGER-2010
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> Ranger Tagsync should use cookie based authentication for subsequent requests 
> to Ranger admin.
> 
> 
> Diffs
> -
> 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/util/RangerRESTClient.java
>  0d94edc 
>   tagsync/src/main/java/org/apache/ranger/tagsync/process/TagSyncConfig.java 
> 697c7cc 
>   
> tagsync/src/main/java/org/apache/ranger/tagsync/sink/tagadmin/TagAdminRESTSink.java
>  a1dc8f5 
>   tagsync/src/main/resources/ranger-tagsync-site.xml 3542ae2 
> 
> 
> Diff: https://reviews.apache.org/r/65920/diff/5/
> 
> 
> Testing
> ---
> 
> 1)verified if ranger tagsync works as expected.
> 2)verified if tagsync is not re-login for every notification if 
> "ranger.tagsync.cookie.enabled" is set as true.
> 
> 
> File Attachments
> 
> 
> 0003-RANGER-2010-Ranger-Tagsync-should-use-cookie-based-a.patch
>   
> https://reviews.apache.org/media/uploaded/files/2018/03/12/3f7133ab-72f9-413e-997c-4d9265f88cdc__0003-RANGER-2010-Ranger-Tagsync-should-use-cookie-based-a.patch
> 0005-RANGER-2010-Ranger-Tagsync-should-use-cookie-based-a.patch
>   
> https://reviews.apache.org/media/uploaded/files/2018/03/14/e8193a99-70e9-4124-b70a-bd9335665455__0005-RANGER-2010-Ranger-Tagsync-should-use-cookie-based-a.patch
> 
> 
> Thanks,
> 
> Nikhil P
> 
>

[jira] [Updated] (RANGER-2010) Ranger Tagsync should use cookie based authentication for subsequent requests to Ranger admin

2018-03-14 Thread Velmurugan Periasamy (JIRA)


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

Velmurugan Periasamy updated RANGER-2010:
-
Reporter: Sean Roberts  (was: Nikhil Purbhe)

> Ranger Tagsync should use cookie based authentication for subsequent requests 
> to Ranger admin
> -
>
> Key: RANGER-2010
> URL: https://issues.apache.org/jira/browse/RANGER-2010
> Project: Ranger
>  Issue Type: Improvement
>  Components: Ranger, tagsync
>Reporter: Sean Roberts
>Assignee: Nikhil Purbhe
>Priority: Major
> Fix For: 1.1.0
>
> Attachments: 
> 0002-RANGER-2010-Ranger-Tagsync-should-use-cookie-based-a.patch, 
> 0003-RANGER-2010-Ranger-Tagsync-should-use-cookie-based-a.patch, 
> RANGER-2010-Ranger-Tagsync-should-use-cookie-based-a.patch
>
>
> Ranger Tagsync should use cookie based authentication for subsequent requests 
> to Ranger admin.



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

[jira] [Commented] (RANGER-2010) Ranger Tagsync should use cookie based authentication for subsequent requests to Ranger admin

2018-03-14 Thread Pradeep Agrawal (JIRA)


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

Pradeep Agrawal commented on RANGER-2010:
-

Patch committed in Apache master branch : 
https://github.com/apache/ranger/commit/a7d51d496d860715577d1a77117313748c611397

> Ranger Tagsync should use cookie based authentication for subsequent requests 
> to Ranger admin
> -
>
> Key: RANGER-2010
> URL: https://issues.apache.org/jira/browse/RANGER-2010
> Project: Ranger
>  Issue Type: Improvement
>  Components: Ranger, tagsync
>Reporter: Sean Roberts
>Assignee: Nikhil Purbhe
>Priority: Major
> Fix For: 1.1.0
>
> Attachments: 
> 0002-RANGER-2010-Ranger-Tagsync-should-use-cookie-based-a.patch, 
> 0003-RANGER-2010-Ranger-Tagsync-should-use-cookie-based-a.patch, 
> RANGER-2010-Ranger-Tagsync-should-use-cookie-based-a.patch
>
>
> Ranger Tagsync should use cookie based authentication for subsequent requests 
> to Ranger admin.



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

[jira] [Comment Edited] (RANGER-2000) Policy effective dates to support time-bound and temporary authorization

2018-03-14 Thread Abhay Kulkarni (JIRA)


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

Abhay Kulkarni edited comment on RANGER-2000 at 3/14/18 6:56 PM:
-

Additional commits to fix issues:

Logging level fix - 
[https://git-wip-us.apache.org/repos/asf?p=ranger.git;a=commit;h=19d6ef464a39394869ddf49e49c8e39dce96a8a0]

Unit tests fix - 
[https://git-wip-us.apache.org/repos/asf?p=ranger.git;a=commit;h=1d4afbe57a86bf025b00b0e2c93793d355a9096d]

NPE when validating time-spec - 
[https://git-wip-us.apache.org/repos/asf?p=ranger.git;a=commit;h=aca4c3b5438e0e52b1e2d24a7e322278d36c7ffc]

Create transaction log for update to time-spec - 
https://git-wip-us.apache.org/repos/asf?p=ranger.git;a=commit;h=94d0566d21a64b795c9a4844354960605bc1f9d9


was (Author: abhayk):
Commit details:

https://git-wip-us.apache.org/repos/asf?p=ranger.git;a=commit;h=844315cdbc5e4589f5a4f873c33533d8f7bb014e

> Policy 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
>Assignee: Abhay Kulkarni
>Priority: Major
> Fix For: master, 1.1.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 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  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 is effective.



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

Re: Some recent commits missing from master

2018-03-14 Thread Velmurugan Periasamy

Thank you Colm. 

1] For now, I have committed this additional fix
(3d341a4c2429cae259b831b112c6d65eaa12a2e1) for RANGER-1991 into master.
Actual fix for RANGER-2016
  is still pending.

2] RANGER-2014 changes seem to be already there in master via below commit.
So it should be fine.

commit b6285fba7373df8b00a0dd5b0ac0c4b17aea
Author: ni3galave 
Date:   Thu Mar 8 20:03:48 2018 +0530

RANGER-1985: [UI] Auditing for Ranger Usersync operations

Signed-off-by: pradeep 


From:  Colm O hEigeartaigh 
Reply-To:  "dev@ranger.apache.org" ,
"cohei...@apache.org" 
Date:  Wednesday, March 14, 2018 at 2:00 PM
To:  "dev@ranger.apache.org" 
Subject:  Some recent commits missing from master

Hi all,

A few recent commits appear to have been made directly onto the 1.0 branch
instead of to master and then backporting

commit 3d341a4c2429cae259b831b112c6d65eaa12a2e1 (tag: release-1.0.0-rc0,
origin/ranger-1.0, ranger-1.0)
Author: pradeep 
Date:   Sat Mar 10 15:28:40 2018 +0530

RANGER-1991: Import policy failure fix caused by static code analysis
fix

commit 79d177be7bc6d511e8902d963802c9550608bebf
Author: ni3galave 
Date:   Sat Mar 10 20:35:25 2018 +0530

RANGER-2014: Unable to see policy detail in view policy mode after
updating recursive flag

Signed-off-by: pradeep 



-- 
Colm O hEigeartaigh

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

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

2018-03-14 Thread Velmurugan Periasamy (JIRA)


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

Velmurugan Periasamy commented on RANGER-1991:
--

I have committed this into master also - 
[https://git-wip-us.apache.org/repos/asf?p=ranger.git;a=commit;h=ad426c24c04e36ff6b7fc286501b4b737b317ad3]
 so that it is in sync. CC [~pradeep.agrawal]/[~coheig]

[~zsombor] - you can revise this when you commit RANGER-2016 fix. Thanks. 

> 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: Blocker
>  Labels: code-cleanup, findbugs
> Fix For: 1.0.0
>
> Attachments: 
> 0001-RANGER-1991-Import-policy-failure-fix-caused-by-stat.patch, 
> RANGER-1991-fix.patch, 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] [Commented] (RANGER-2006) Fix problems detected by static code analysis in ranger usersync for ldap sync source

2018-03-14 Thread Sailaja Polavarapu (JIRA)


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

Sailaja Polavarapu commented on RANGER-2006:


Ranger usersync uses DirContecxt API for ldap search and according to the 
documentation looks like API already handles the escaping of special 
characters. 

[https://docs.oracle.com/javase/7/docs/api/javax/naming/directory/DirContext.html#search(javax.naming.Name,%20java.lang.String,%20javax.naming.directory.SearchControls)]

_"When a string-valued filter argument is substituted for a variable, the 
filter is interpreted as if the string were given in place of the variable, 
with any characters having special significance within filters (such as 
{{'*'}}) having been escaped according to the rules of RFC 2254."_ 

 

Hence proposing to revert the change.

> Fix problems detected by static code analysis in ranger usersync for ldap 
> sync source
> -
>
> Key: RANGER-2006
> URL: https://issues.apache.org/jira/browse/RANGER-2006
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger, usersync
>Affects Versions: 0.7.1
>Reporter: Sailaja Polavarapu
>Assignee: Sailaja Polavarapu
>Priority: Minor
> Fix For: 1.0.0, master
>
>
> 1. *Overview* : The method goUpGroupHierarchyLdap() invokes a dynamically 
> generated LDAP filter with unvalidated input, which could allow an attacker 
> to modify the statement's meaning.
> In the file LdapDeltaUserGroupBuilder.java similar issues were on line 
> numbers 913
> *Comments* : need to verify the search() parameters for validation
> 2. *Overview* : The method goUpGroupHierarchyLdap() invokes a dynamically 
> generated LDAP filter with unvalidated input, which could allow an attacker 
> to modify the statement's meaning.
> In the file LdapUserGroupBuilder.java similar issues were on line numbers 818
> *Comments* : need to verify the search() parameters for validation



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

42 matches

Mail list logo