Re: Review Request 70932: Ranger-2482: use Solr API to upload config set (during bootstrapping)

[Mehul Parikh]

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


Ship it!




Ship It!

- Mehul Parikh


On June 27, 2019, 5:11 a.m., Fatima Khan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/70932/
> ---
> 
> (Updated June 27, 2019, 5:11 a.m.)
> 
> 
> Review request for ranger, Gautam Borad, Kevin Risden, Oliver Szabo, Pradeep 
> Agrawal, and Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-2482
> https://issues.apache.org/jira/browse/RANGER-2482
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> We are using Solr config set API to Upload Configuration and to Create 
> Collection.
> 
> 
> Diffs
> -
> 
>   
> embeddedwebserver/src/main/java/org/apache/ranger/server/tomcat/EmbeddedServer.java
>  5ef354b 
>   
> embeddedwebserver/src/main/java/org/apache/ranger/server/tomcat/SolrCollectionBoostrapper.java
>  8a417a0 
>   
> embeddedwebserver/src/main/java/org/apache/ranger/server/tomcat/SolrCollectionBootstrapper.java
>  PRE-CREATION 
>   pom.xml 5b1eb65 
>   src/main/assembly/solr_audit_conf.xml PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/70932/diff/4/
> 
> 
> Testing
> ---
> 
> Tested Below Scenario in ranger
> 1.Solr configuration were uploaded successfully
> 2.Solr collections were created successfully
> 
> 
> Thanks,
> 
> Fatima Khan
> 
>

Re: Review Request 70932: Ranger-2482: use Solr API to upload config set (during bootstrapping)

[Fatima Khan]

> On June 26, 2019, 7:36 p.m., Oliver Szabo wrote:
> > embeddedwebserver/src/main/java/org/apache/ranger/server/tomcat/SolrCollectionBootstrapper.java
> > Lines 309 (patched)
> > 
> >
> > what about "https"?
> 
> Pradeep Agrawal wrote:
> I have created RANGER-2490

Yes we will be handling that in RANGER-2490


- Fatima


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


On June 27, 2019, 5:11 a.m., Fatima Khan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/70932/
> ---
> 
> (Updated June 27, 2019, 5:11 a.m.)
> 
> 
> Review request for ranger, Gautam Borad, Kevin Risden, Oliver Szabo, Pradeep 
> Agrawal, and Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-2482
> https://issues.apache.org/jira/browse/RANGER-2482
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> We are using Solr config set API to Upload Configuration and to Create 
> Collection.
> 
> 
> Diffs
> -
> 
>   
> embeddedwebserver/src/main/java/org/apache/ranger/server/tomcat/EmbeddedServer.java
>  5ef354b 
>   
> embeddedwebserver/src/main/java/org/apache/ranger/server/tomcat/SolrCollectionBoostrapper.java
>  8a417a0 
>   
> embeddedwebserver/src/main/java/org/apache/ranger/server/tomcat/SolrCollectionBootstrapper.java
>  PRE-CREATION 
>   pom.xml 5b1eb65 
>   src/main/assembly/solr_audit_conf.xml PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/70932/diff/4/
> 
> 
> Testing
> ---
> 
> Tested Below Scenario in ranger
> 1.Solr configuration were uploaded successfully
> 2.Solr collections were created successfully
> 
> 
> Thanks,
> 
> Fatima Khan
> 
>

Re: Review Request 70932: Ranger-2482: use Solr API to upload config set (during bootstrapping)

[Fatima Khan]

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

(Updated June 27, 2019, 5:11 a.m.)


Review request for ranger, Gautam Borad, Kevin Risden, Oliver Szabo, Pradeep 
Agrawal, and Velmurugan Periasamy.


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


Repository: ranger


Description
---

We are using Solr config set API to Upload Configuration and to Create 
Collection.


Diffs (updated)
-

  
embeddedwebserver/src/main/java/org/apache/ranger/server/tomcat/EmbeddedServer.java
 5ef354b 
  
embeddedwebserver/src/main/java/org/apache/ranger/server/tomcat/SolrCollectionBoostrapper.java
 8a417a0 
  
embeddedwebserver/src/main/java/org/apache/ranger/server/tomcat/SolrCollectionBootstrapper.java
 PRE-CREATION 
  pom.xml 5b1eb65 
  src/main/assembly/solr_audit_conf.xml PRE-CREATION 


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

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


Testing
---

Tested Below Scenario in ranger
1.Solr configuration were uploaded successfully
2.Solr collections were created successfully


Thanks,

Fatima Khan

Re: Review Request 70932: Ranger-2482: use Solr API to upload config set (during bootstrapping)

[Fatima Khan]

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

(Updated June 27, 2019, 5:11 a.m.)


Review request for ranger, Gautam Borad, Kevin Risden, Oliver Szabo, Pradeep 
Agrawal, and Velmurugan Periasamy.


Summary (updated)
-

Ranger-2482: use Solr API to upload config set (during bootstrapping)


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


Repository: ranger


Description
---

We are using Solr config set API to Upload Configuration and to Create 
Collection.


Diffs (updated)
-

  
embeddedwebserver/src/main/java/org/apache/ranger/server/tomcat/EmbeddedServer.java
 5ef354b 
  
embeddedwebserver/src/main/java/org/apache/ranger/server/tomcat/SolrCollectionBoostrapper.java
 8a417a0 
  
embeddedwebserver/src/main/java/org/apache/ranger/server/tomcat/SolrCollectionBootstrapper.java
 PRE-CREATION 
  pom.xml 5b1eb65 
  src/main/assembly/solr_audit_conf.xml PRE-CREATION 


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

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


Testing
---

Tested Below Scenario in ranger
1.Solr configuration were uploaded successfully
2.Solr collections were created successfully


Thanks,

Fatima Khan

[jira] [Updated] (RANGER-2482) Ranger: use Solr API to upload config set (during bootstrapping)

[Fatima Amjad Khan (JIRA)]

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

Fatima Amjad Khan updated RANGER-2482:
--
Attachment: RANGER-2482.patch

> Ranger: use Solr API to upload config set (during bootstrapping)
> 
>
> Key: RANGER-2482
> URL: https://issues.apache.org/jira/browse/RANGER-2482
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Affects Versions: 2.0.0
>Reporter: Fatima Amjad Khan
>Assignee: Fatima Amjad Khan
>Priority: Major
> Fix For: 2.0.0
>
> Attachments: RANGER-2482.patch
>
>
> Ranger:
>  - remove ZK znode check 
>  - remove ZK config set upload 
>  - remove ZK acl set
>  - use Solr config set API 
> ([https://lucene.apache.org/solr/guide/7_4/config-sets.html]) to upload the 
> config sets (only if it does not exists ... also probably Solr4J should have 
> this call)
>  



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

[jira] [Created] (RANGER-2490) Add https support while using Solr API to upload config set

[Pradeep Agrawal (JIRA)]

Pradeep Agrawal created RANGER-2490:
---

 Summary: Add https support while using Solr API to upload config 
set
 Key: RANGER-2490
 URL: https://issues.apache.org/jira/browse/RANGER-2490
 Project: Ranger
  Issue Type: Bug
  Components: Ranger
Affects Versions: 2.0.0
Reporter: Pradeep Agrawal
Assignee: Fatima Amjad Khan
 Fix For: 2.0.0






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

[jira] [Updated] (RANGER-2482) Ranger: use Solr API to upload config set (during bootstrapping)

[Pradeep Agrawal (JIRA)]

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

Pradeep Agrawal updated RANGER-2482:

Fix Version/s: (was: master)
   2.0.0

> Ranger: use Solr API to upload config set (during bootstrapping)
> 
>
> Key: RANGER-2482
> URL: https://issues.apache.org/jira/browse/RANGER-2482
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Affects Versions: master
>Reporter: Fatima Amjad Khan
>Assignee: Fatima Amjad Khan
>Priority: Major
> Fix For: 2.0.0
>
>
> Ranger:
>  - remove ZK znode check 
>  - remove ZK config set upload 
>  - remove ZK acl set
>  - use Solr config set API 
> ([https://lucene.apache.org/solr/guide/7_4/config-sets.html]) to upload the 
> config sets (only if it does not exists ... also probably Solr4J should have 
> this call)
>  



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

[jira] [Updated] (RANGER-2482) Ranger: use Solr API to upload config set (during bootstrapping)

[Pradeep Agrawal (JIRA)]

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

Pradeep Agrawal updated RANGER-2482:

Affects Version/s: (was: master)
   2.0.0

> Ranger: use Solr API to upload config set (during bootstrapping)
> 
>
> Key: RANGER-2482
> URL: https://issues.apache.org/jira/browse/RANGER-2482
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Affects Versions: 2.0.0
>Reporter: Fatima Amjad Khan
>Assignee: Fatima Amjad Khan
>Priority: Major
> Fix For: 2.0.0
>
>
> Ranger:
>  - remove ZK znode check 
>  - remove ZK config set upload 
>  - remove ZK acl set
>  - use Solr config set API 
> ([https://lucene.apache.org/solr/guide/7_4/config-sets.html]) to upload the 
> config sets (only if it does not exists ... also probably Solr4J should have 
> this call)
>  



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

Re: Review Request 70940: RANGER-2481:Create a tag service when a resource service is created and link it to resource service

[Madhan Neethiraj]

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


Ship it!




Ship It!

- Madhan Neethiraj


On June 26, 2019, 9:53 p.m., Abhay Kulkarni wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/70940/
> ---
> 
> (Updated June 26, 2019, 9:53 p.m.)
> 
> 
> Review request for ranger, Madhan Neethiraj, Ramesh Mani, and Velmurugan 
> Periasamy.
> 
> 
> Bugs: RANGER-2481
> https://issues.apache.org/jira/browse/RANGER-2481
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> Ranger supports tag-based policies out of the box. However, there are a few 
> configuration steps that need to be performed in order to set up Ranger to 
> perform tag-based authorization. As these steps are often missed, it will be 
> useful to provide a commonly used/structured way of automatically creating 
> tag service and linking it to resource service.
> 
> This may be controlled through few configuration parameters:
> 
> tag.service.auto.create= ==> If tag-service needs to be created 
> when resource-service is created.
> 
> tag.service.name= ==> If tag-service needs to be 
> created, how is it named (automatically or user-specified)
> 
> tag.service.auto.link= ==> If resource-service needs to be linked 
> to the tag-service
> 
> 
> Diffs
> -
> 
>   security-admin/src/main/java/org/apache/ranger/rest/ServiceREST.java 
> 1d9391f20 
>   security-admin/src/test/java/org/apache/ranger/rest/TestServiceREST.java 
> 321d1c522 
> 
> 
> Diff: https://reviews.apache.org/r/70940/diff/4/
> 
> 
> Testing
> ---
> 
> Tested by creating a resource service, and ensuring that corresponding tag 
> service is created and linked with resource service
> 
> 
> Thanks,
> 
> Abhay Kulkarni
> 
>

Re: Review Request 70940: RANGER-2481:Create a tag service when a resource service is created and link it to resource service

[Abhay Kulkarni]

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

(Updated June 26, 2019, 9:53 p.m.)


Review request for ranger, Madhan Neethiraj, Ramesh Mani, and Velmurugan 
Periasamy.


Changes
---

RangerTransactionService class is now used to wire up function to create and 
link tag service. With this design, only changes needed are local to 
ServiceREST class. Changes are retested and verified for various configuration 
settings described in the JIRA for correctness.


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


Repository: ranger


Description
---

Ranger supports tag-based policies out of the box. However, there are a few 
configuration steps that need to be performed in order to set up Ranger to 
perform tag-based authorization. As these steps are often missed, it will be 
useful to provide a commonly used/structured way of automatically creating tag 
service and linking it to resource service.

This may be controlled through few configuration parameters:

tag.service.auto.create= ==> If tag-service needs to be created 
when resource-service is created.

tag.service.name= ==> If tag-service needs to be 
created, how is it named (automatically or user-specified)

tag.service.auto.link= ==> If resource-service needs to be linked 
to the tag-service


Diffs (updated)
-

  security-admin/src/main/java/org/apache/ranger/rest/ServiceREST.java 
1d9391f20 
  security-admin/src/test/java/org/apache/ranger/rest/TestServiceREST.java 
321d1c522 


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

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


Testing
---

Tested by creating a resource service, and ensuring that corresponding tag 
service is created and linked with resource service


Thanks,

Abhay Kulkarni

[jira] [Updated] (RANGER-2480) Hive URL Policy doesn't match if recursive flag is on for the url resource

[Ramesh Mani (JIRA)]

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

Ramesh Mani updated RANGER-2480:

Description: 
Hive URL Policy doesn't match if recursive flag is on for the url resource
Solution is to have the "recursive flag" off as the matcher rewrites the path 
like "s3a://test/*" to "s3a:/test/*"
or we need to have a new URLMatcher to handle this.
So we should have the default behavior for URL match to be with no recursive 
flag.

  was:
Hive URL Policy doesn't match if recursive flag is on for the url resource
Solution is to have the "recursive flag" off as the matcher rewrites the path 
like "s3a://test/*" to "s3a:/test/*"
So we should have the default behavior for URL match to be with no recursive 
flag.


> Hive URL Policy doesn't match if recursive flag is on for the url resource
> --
>
> Key: RANGER-2480
> URL: https://issues.apache.org/jira/browse/RANGER-2480
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Reporter: Ramesh Mani
>Assignee: Ramesh Mani
>Priority: Major
> Fix For: 2.0.0
>
>
> Hive URL Policy doesn't match if recursive flag is on for the url resource
> Solution is to have the "recursive flag" off as the matcher rewrites the path 
> like "s3a://test/*" to "s3a:/test/*"
> or we need to have a new URLMatcher to handle this.
> So we should have the default behavior for URL match to be with no recursive 
> flag.



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

[jira] [Assigned] (RANGER-2480) Hive URL Policy doesn't match if recursive flag is on for the url resource

[Ramesh Mani (JIRA)]

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

Ramesh Mani reassigned RANGER-2480:
---

Assignee: Ramesh Mani

> Hive URL Policy doesn't match if recursive flag is on for the url resource
> --
>
> Key: RANGER-2480
> URL: https://issues.apache.org/jira/browse/RANGER-2480
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Reporter: Ramesh Mani
>Assignee: Ramesh Mani
>Priority: Major
> Fix For: 2.0.0
>
>
> Hive URL Policy doesn't match if recursive flag is on for the url resource
> Solution is to have the "recursive flag" off as the matcher rewrites the path 
> like "s3a://test/*" to "s3a:/test/*"
> So we should have the default behavior for URL match to be with no recursive 
> flag.



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

[jira] [Updated] (RANGER-2481) Create a tag service when a resource service is created and link it to resource service

[Abhay Kulkarni (JIRA)]

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

Abhay Kulkarni updated RANGER-2481:
---
Description: 
Ranger supports tag-based policies out of the box. However, there are a few 
configuration steps that need to be performed in order to set up Ranger to 
perform tag-based authorization. As these steps are often missed, it will be 
useful to provide a commonly used/structured way of automatically creating tag 
service and linking it to resource service.

This may be controlled through few configuration parameters:

ranger.tagservice.auto.create= ==> If tag-service needs to be 
created when resource-service is created.

ranger.tagservice.auto.name= ==> If value is specified, then 
it is used to name the tag-service, otherwise the name of tag-service is 
constructed from the name of the resource-service (by replacing the part after 
last '_' by string 'tag', and if there is no '_' character in the 
resource-service name, then tag-service is not created/linked with 
resource-service).

ranger.tagservice.auto.link= ==> Used only if 
ranger.tagservice.auto.create is true. Set to true only if resource-service 
needs to be linked to the tag-service

 

  was:
Ranger supports tag-based policies out of the box. However, there are a few 
configuration steps that need to be performed in order to set up Ranger to 
perform tag-based authorization. As these steps are often missed, it will be 
useful to provide a commonly used/structured way of automatically creating tag 
service and linking it to resource service.

This may be controlled through few configuration parameters:

ranger.tagservice.auto.create= ==> If tag-service needs to be 
created when resource-service is created.

ranger.tagservice.auto.name= ==> If value is specified, then 
it is used to name the tag-service, otherwise the name of tag-service is 
constructed from the name of the resource-service (by replacing the part after 
last '_' by string 'tag', and if there is no '_' character in the 
resource-service name, then tag-service is not created/linked with 
resource-service).

ranger.tagservice.auto.link= ==> If resource-service needs to be 
linked to the tag-service

 


> Create a tag service when a resource service is created and link it to 
> resource service
> ---
>
> Key: RANGER-2481
> URL: https://issues.apache.org/jira/browse/RANGER-2481
> Project: Ranger
>  Issue Type: Improvement
>  Components: Ranger
>Affects Versions: master
>Reporter: Abhay Kulkarni
>Assignee: Abhay Kulkarni
>Priority: Major
> Fix For: 2.0.0
>
>
> Ranger supports tag-based policies out of the box. However, there are a few 
> configuration steps that need to be performed in order to set up Ranger to 
> perform tag-based authorization. As these steps are often missed, it will be 
> useful to provide a commonly used/structured way of automatically creating 
> tag service and linking it to resource service.
> This may be controlled through few configuration parameters:
> ranger.tagservice.auto.create= ==> If tag-service needs to be 
> created when resource-service is created.
> ranger.tagservice.auto.name= ==> If value is specified, 
> then it is used to name the tag-service, otherwise the name of tag-service is 
> constructed from the name of the resource-service (by replacing the part 
> after last '_' by string 'tag', and if there is no '_' character in the 
> resource-service name, then tag-service is not created/linked with 
> resource-service).
> ranger.tagservice.auto.link= ==> Used only if 
> ranger.tagservice.auto.create is true. Set to true only if resource-service 
> needs to be linked to the tag-service
>  



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

Re: Review Request 70932: Ranger: use Solr API to upload config set (during bootstrapping)

[Oliver Szabo]

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




embeddedwebserver/src/main/java/org/apache/ranger/server/tomcat/SolrCollectionBootstrapper.java
Lines 309 (patched)


what about "https"?


- Oliver Szabo


On June 25, 2019, 10:18 a.m., Fatima Khan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/70932/
> ---
> 
> (Updated June 25, 2019, 10:18 a.m.)
> 
> 
> Review request for ranger, Gautam Borad, Kevin Risden, Oliver Szabo, Pradeep 
> Agrawal, and Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-2482
> https://issues.apache.org/jira/browse/RANGER-2482
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> We are using Solr config set API to Upload Configuration and to Create 
> Collection.
> 
> 
> Diffs
> -
> 
>   
> embeddedwebserver/src/main/java/org/apache/ranger/server/tomcat/EmbeddedServer.java
>  5ef354b 
>   
> embeddedwebserver/src/main/java/org/apache/ranger/server/tomcat/SolrCollectionBoostrapper.java
>  8a417a0 
>   
> embeddedwebserver/src/main/java/org/apache/ranger/server/tomcat/SolrCollectionBootstrapper.java
>  PRE-CREATION 
>   pom.xml 5b1eb65 
>   src/main/assembly/solr_audit_conf.xml PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/70932/diff/2/
> 
> 
> Testing
> ---
> 
> Tested Below Scenario in ranger
> 1.Solr configuration were uploaded successfully
> 2.Solr collections were created successfully
> 
> 
> Thanks,
> 
> Fatima Khan
> 
>

[jira] [Created] (RANGER-2489) Missing dependencies in assembly for Presto plugin

[Bolke de Bruin (JIRA)]

Bolke de Bruin created RANGER-2489:
--

 Summary: Missing dependencies in assembly for Presto plugin
 Key: RANGER-2489
 URL: https://issues.apache.org/jira/browse/RANGER-2489
 Project: Ranger
  Issue Type: Improvement
  Components: plugins
Reporter: Bolke de Bruin
Assignee: Bolke de Bruin


If invoking with hostnames rather than ips extra dependencies are required by 
the plugin for Presto.

commons-codec commons-codec-1.12
com.kstruct gethostname4j-0.0.3
com.sun jna-3.0.9.jar



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

[jira] [Updated] (RANGER-2488) Ranger Kafka list consumer groups permission

[Hari Sekhon (JIRA)]

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

Hari Sekhon updated RANGER-2488:

Description: 
In a kerberized environment with Ranger, Kafka client is unable to list 
consumer groups to iterate over if the user only has Describe permission on 
their own topics rather than on all topics.
{code:java}
/usr/hdp/current/kafka-broker/bin/kafka-consumer-groups.sh --bootstrap-server 
 --list{code}
It ends up with a blank output instead of the list of consumer groups.

If you then grant Describe permission to all topics, that command then gives 
you a list of consumer groups as expected.

I believe Kafka permissions have been improved to be more granular in 
KAFKA-6058.

Ranger needs to be updated to reflect these more granular Kafka permissions to 
allow listing consumer groups without having to also have describe permissions 
to all topics.

Interestingly I can still describe a consumer group after I have revoked my own 
permissions and agent policy has been updated if I know the name of the 
consumer group, but it omits the topic for which I no longer have permission.
{code:java}
/usr/hdp/current/kafka-broker/bin/kafka-consumer-groups.sh --bootstrap-server 
 --describe --group .{code}

  was:
In a kerberized environment, Kafka client is unable to list consumer groups to 
iterate over if the user only has Describe permission on their own topics 
rather than on all topics.
{code:java}
/usr/hdp/current/kafka-broker/bin/kafka-consumer-groups.sh --bootstrap-server 
 --list{code}
It ends up with a blank output instead of the list of consumer groups.

If you then grant Describe permission to all topics, that command then gives 
you a list of consumer groups as expected.

I believe Kafka permissions have been improved to be more granular in 
KAFKA-6058.

Ranger needs to be updated to reflect these more granular Kafka permissions.

Interestingly I can still describe a consumer group after I have revoked my own 
permissions and agent policy has been updated if I know the name of the 
consumer group, but it omits the topic for which I no longer have permission.
{code:java}
/usr/hdp/current/kafka-broker/bin/kafka-consumer-groups.sh --bootstrap-server 
 --describe --group .{code}


> Ranger Kafka list consumer groups permission
> 
>
> Key: RANGER-2488
> URL: https://issues.apache.org/jira/browse/RANGER-2488
> Project: Ranger
>  Issue Type: Bug
>  Components: plugins, Ranger
>Affects Versions: 0.7.0
> Environment: HDP 2.6.5 + Kerberos
>Reporter: Hari Sekhon
>Priority: Major
>
> In a kerberized environment with Ranger, Kafka client is unable to list 
> consumer groups to iterate over if the user only has Describe permission on 
> their own topics rather than on all topics.
> {code:java}
> /usr/hdp/current/kafka-broker/bin/kafka-consumer-groups.sh --bootstrap-server 
>  --list{code}
> It ends up with a blank output instead of the list of consumer groups.
> If you then grant Describe permission to all topics, that command then gives 
> you a list of consumer groups as expected.
> I believe Kafka permissions have been improved to be more granular in 
> KAFKA-6058.
> Ranger needs to be updated to reflect these more granular Kafka permissions 
> to allow listing consumer groups without having to also have describe 
> permissions to all topics.
> Interestingly I can still describe a consumer group after I have revoked my 
> own permissions and agent policy has been updated if I know the name of the 
> consumer group, but it omits the topic for which I no longer have permission.
> {code:java}
> /usr/hdp/current/kafka-broker/bin/kafka-consumer-groups.sh --bootstrap-server 
>  --describe --group .{code}



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

[jira] [Updated] (RANGER-2488) Ranger Kafka list consumer groups permission

[Hari Sekhon (JIRA)]

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

Hari Sekhon updated RANGER-2488:

Description: 
In a kerberized environment, Kafka client is unable to list consumer groups to 
iterate over if the user only has Describe permission on their own topics 
rather than on all topics.
{code:java}
/usr/hdp/current/kafka-broker/bin/kafka-consumer-groups.sh --bootstrap-server 
 --list{code}
It ends up with a blank output instead of the list of consumer groups.

If you then grant Describe permission to all topics, that command then gives 
you a list of consumer groups as expected.

I believe Kafka permissions have been improved to be more granular in 
KAFKA-6058.

Ranger needs to be updated to reflect these more granular Kafka permissions.

Interestingly I can still describe a consumer group after I have revoked my own 
permissions and agent policy has been updated if I know the name of the 
consumer group, but it omits the topic for which I no longer have permission.
{code:java}
/usr/hdp/current/kafka-broker/bin/kafka-consumer-groups.sh --bootstrap-server 
 --describe --group .{code}

  was:
In a kerberized environment, Kafka client is unable to list consumer groups to 
iterate over if the user only has Describe permission on their own topics 
rather than on all topics.
{code:java}
/usr/hdp/current/kafka-broker/bin/kafka-consumer-groups.sh --list 
--bootstrap-server {code}
It ends up with a blank output instead of the list of consumer groups.

If you then grant Describe permission to all topics, that command then gives 
you a list of consumer groups as expected.

I believe Kafka permissions have been improved to be more granular in 
KAFKA-6058.

Ranger needs to be updated to reflect these more granular Kafka permissions.

Interestingly I can still describe a consumer group after I have revoked my own 
permissions and agent policy has been updated if I know the name of the 
consumer group, but it omits the topic for which I no longer have permission.
{code:java}
/usr/hdp/current/kafka-broker/bin/kafka-consumer-groups.sh --bootstrap-server 
 --describe --group .{code}


> Ranger Kafka list consumer groups permission
> 
>
> Key: RANGER-2488
> URL: https://issues.apache.org/jira/browse/RANGER-2488
> Project: Ranger
>  Issue Type: Bug
>  Components: plugins, Ranger
>Affects Versions: 0.7.0
> Environment: HDP 2.6.5 + Kerberos
>Reporter: Hari Sekhon
>Priority: Major
>
> In a kerberized environment, Kafka client is unable to list consumer groups 
> to iterate over if the user only has Describe permission on their own topics 
> rather than on all topics.
> {code:java}
> /usr/hdp/current/kafka-broker/bin/kafka-consumer-groups.sh --bootstrap-server 
>  --list{code}
> It ends up with a blank output instead of the list of consumer groups.
> If you then grant Describe permission to all topics, that command then gives 
> you a list of consumer groups as expected.
> I believe Kafka permissions have been improved to be more granular in 
> KAFKA-6058.
> Ranger needs to be updated to reflect these more granular Kafka permissions.
> Interestingly I can still describe a consumer group after I have revoked my 
> own permissions and agent policy has been updated if I know the name of the 
> consumer group, but it omits the topic for which I no longer have permission.
> {code:java}
> /usr/hdp/current/kafka-broker/bin/kafka-consumer-groups.sh --bootstrap-server 
>  --describe --group .{code}



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

[jira] [Updated] (RANGER-2488) Ranger Kafka list consumer groups permission

[Hari Sekhon (JIRA)]

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

Hari Sekhon updated RANGER-2488:

Description: 
In a kerberized environment, Kafka client is unable to list consumer groups to 
iterate over if the user only has Describe permission on their own topics 
rather than on all topics.
{code:java}
/usr/hdp/current/kafka-broker/bin/kafka-consumer-groups.sh --list 
--bootstrap-server {code}
It ends up with a blank output instead of the list of consumer groups.

If you then grant Describe permission to all topics, that command then gives 
you a list of consumer groups as expected.

I believe Kafka permissions have been improved to be more granular in 
KAFKA-6058.

Ranger needs to be updated to reflect these more granular Kafka permissions.

Interestingly I can still describe a consumer group after I have revoked my own 
permissions and agent policy has been updated if I know the name of the 
consumer group, but it omits the topic for which I no longer have permission.
{code:java}
/usr/hdp/current/kafka-broker/bin/kafka-consumer-groups.sh --bootstrap-server 
 --describe --group .{code}

  was:
In a kerberized environment, Kafka client is unable to list consumer groups to 
iterate over if the user only has Describe permission on their own topics 
rather than on all topics.
{code:java}
/usr/hdp/current/kafka-broker/bin/kafka-consumer-groups.sh --list 
--bootstrap-server {code}
It ends up with a blank output instead of the list of consumer groups.

If you then grant Describe permission to all topics, that command then gives 
you a list of consumer groups as expected.

I believe Kafka permissions have been improved to be more granular in 
KAFKA-6058.

Ranger needs to be updated to reflect these more granular Kafka permissions.

Interestingly I can still describe a consumer group after I have revoked my own 
permissions and agent policy has been updated if I know the name of the 
consumer group, but it omits the topic for which I no longer have permission.


> Ranger Kafka list consumer groups permission
> 
>
> Key: RANGER-2488
> URL: https://issues.apache.org/jira/browse/RANGER-2488
> Project: Ranger
>  Issue Type: Bug
>  Components: plugins, Ranger
>Affects Versions: 0.7.0
> Environment: HDP 2.6.5 + Kerberos
>Reporter: Hari Sekhon
>Priority: Major
>
> In a kerberized environment, Kafka client is unable to list consumer groups 
> to iterate over if the user only has Describe permission on their own topics 
> rather than on all topics.
> {code:java}
> /usr/hdp/current/kafka-broker/bin/kafka-consumer-groups.sh --list 
> --bootstrap-server {code}
> It ends up with a blank output instead of the list of consumer groups.
> If you then grant Describe permission to all topics, that command then gives 
> you a list of consumer groups as expected.
> I believe Kafka permissions have been improved to be more granular in 
> KAFKA-6058.
> Ranger needs to be updated to reflect these more granular Kafka permissions.
> Interestingly I can still describe a consumer group after I have revoked my 
> own permissions and agent policy has been updated if I know the name of the 
> consumer group, but it omits the topic for which I no longer have permission.
> {code:java}
> /usr/hdp/current/kafka-broker/bin/kafka-consumer-groups.sh --bootstrap-server 
>  --describe --group .{code}



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

[jira] [Updated] (RANGER-2488) Ranger Kafka list consumer groups permission

[Hari Sekhon (JIRA)]

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

Hari Sekhon updated RANGER-2488:

Description: 
In a kerberized environment, Kafka client is unable to list consumer groups to 
iterate over if the user only has Describe permission on their own topics 
rather than on all topics.
{code:java}
/usr/hdp/current/kafka-broker/bin/kafka-consumer-groups.sh --list 
--bootstrap-server {code}
It ends up with a blank output instead of the list of consumer groups.

If you then grant Describe permission to all topics, that command then gives 
you a list of consumer groups as expected.

I believe Kafka permissions have been improved to be more granular in 
KAFKA-6058.

Ranger needs to be updated to reflect these more granular Kafka permissions.

Interestingly I can still describe a consumer group after I have revoked my own 
permissions and agent policy has been updated if I know the name of the 
consumer group, but it omits the topic for which I no longer have permission.

  was:
In a kerberized environment, Kafka client is unable to list consumer groups to 
iterate over if the user only has Describe permission on their own topics 
rather than on all topics.
{code:java}
/usr/hdp/current/kafka-broker/bin/kafka-consumer-groups.sh --list 
--bootstrap-server {code}
It ends up with a blank output instead of the list of consumer groups.

If you then grant Describe permission to all topics, that command then gives 
you a list of consumer groups as expected.

I believe Kafka permissions have been improved to be more granular in 
KAFKA-6058.

Ranger needs to be updated to reflect these more granular Kafka permissions.

Interestingly after revoking all permissions to topics for my user I was still 
able to list the offsets for a known consumer group.


> Ranger Kafka list consumer groups permission
> 
>
> Key: RANGER-2488
> URL: https://issues.apache.org/jira/browse/RANGER-2488
> Project: Ranger
>  Issue Type: Bug
>  Components: plugins, Ranger
>Affects Versions: 0.7.0
> Environment: HDP 2.6.5 + Kerberos
>Reporter: Hari Sekhon
>Priority: Major
>
> In a kerberized environment, Kafka client is unable to list consumer groups 
> to iterate over if the user only has Describe permission on their own topics 
> rather than on all topics.
> {code:java}
> /usr/hdp/current/kafka-broker/bin/kafka-consumer-groups.sh --list 
> --bootstrap-server {code}
> It ends up with a blank output instead of the list of consumer groups.
> If you then grant Describe permission to all topics, that command then gives 
> you a list of consumer groups as expected.
> I believe Kafka permissions have been improved to be more granular in 
> KAFKA-6058.
> Ranger needs to be updated to reflect these more granular Kafka permissions.
> Interestingly I can still describe a consumer group after I have revoked my 
> own permissions and agent policy has been updated if I know the name of the 
> consumer group, but it omits the topic for which I no longer have permission.



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

[jira] [Updated] (RANGER-2488) Ranger Kafka list consumer groups permission

[Hari Sekhon (JIRA)]

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

Hari Sekhon updated RANGER-2488:

Description: 
In a kerberized environment, Kafka client is unable to list consumer groups to 
iterate over if the user only has Describe permission on their own topics 
rather than on all topics.
{code:java}
/usr/hdp/current/kafka-broker/bin/kafka-consumer-groups.sh --list 
--bootstrap-server {code}
It ends up with a blank output instead of the list of consumer groups.

If you then grant Describe permission to all topics, that command then gives 
you a list of consumer groups as expected.

I believe Kafka permissions have been improved to be more granular in 
KAFKA-6058.

Ranger needs to be updated to reflect these more granular Kafka permissions.

Interestingly after revoking all permissions to topics for my user I was still 
able to list the offsets for a known consumer group.

  was:
In a kerberized environment, Kafka client is unable to list consumer groups to 
iterate over if the user only have describe permission on their own topics 
rather than on all topics.
{code:java}
/usr/hdp/current/kafka-broker/bin/kafka-consumer-groups.sh --list 
--bootstrap-server {code}
It ends up with a blank output instead of the list of consumer groups.

If you then grant Describe permission to all topics, that command then gives 
you a list of consumer groups as expected.

I believe Kafka permissions have been improved to be more granular in 
KAFKA-6058.

Ranger needs to be updated to reflect these more granular Kafka permissions.

Interestingly after revoking all permissions to topics from my user I was still 
able to list the offsets for a known consumer group.


> Ranger Kafka list consumer groups permission
> 
>
> Key: RANGER-2488
> URL: https://issues.apache.org/jira/browse/RANGER-2488
> Project: Ranger
>  Issue Type: Bug
>  Components: plugins, Ranger
>Affects Versions: 0.7.0
> Environment: HDP 2.6.5 + Kerberos
>Reporter: Hari Sekhon
>Priority: Major
>
> In a kerberized environment, Kafka client is unable to list consumer groups 
> to iterate over if the user only has Describe permission on their own topics 
> rather than on all topics.
> {code:java}
> /usr/hdp/current/kafka-broker/bin/kafka-consumer-groups.sh --list 
> --bootstrap-server {code}
> It ends up with a blank output instead of the list of consumer groups.
> If you then grant Describe permission to all topics, that command then gives 
> you a list of consumer groups as expected.
> I believe Kafka permissions have been improved to be more granular in 
> KAFKA-6058.
> Ranger needs to be updated to reflect these more granular Kafka permissions.
> Interestingly after revoking all permissions to topics for my user I was 
> still able to list the offsets for a known consumer group.



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

[jira] [Created] (RANGER-2488) Ranger Kafka list consumer groups permission

[Hari Sekhon (JIRA)]

Hari Sekhon created RANGER-2488:
---

 Summary: Ranger Kafka list consumer groups permission
 Key: RANGER-2488
 URL: https://issues.apache.org/jira/browse/RANGER-2488
 Project: Ranger
  Issue Type: Bug
  Components: plugins, Ranger
Affects Versions: 0.7.0
 Environment: HDP 2.6.5 + Kerberos
Reporter: Hari Sekhon


In a kerberized environment, Kafka client is unable to list consumer groups to 
iterate over if the user only have describe permission on their own topics 
rather than on all topics.
{code:java}
/usr/hdp/current/kafka-broker/bin/kafka-consumer-groups.sh --list 
--bootstrap-server {code}
It ends up with a blank output instead of the list of consumer groups.

If you then grant Describe permission to all topics, that command then gives 
you a list of consumer groups as expected.

I believe Kafka permissions have been improved to be more granular in 
KAFKA-6058.

Ranger needs to be updated to reflect these more granular Kafka permissions.

Interestingly after revoking all permissions to topics from my user I was still 
able to list the offsets for a known consumer group.



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

Review Request 70954: RANGER-2487 : Resource policy names with a characters that are typically HTML escaped mutate and grow as they are saved.

[Nitin Galave]

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

Review request for ranger, Gautam Borad, Mehul Parikh, Pradeep Agrawal, and 
Velmurugan Periasamy.


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


Repository: ranger


Description
---

If a resource based policy is given a name that contains a character that is 
typically HTML escape, such as the greater than sign '>', which is HTML escaped 
'>', then whenever that policy is saved, the name of the policy will be changed 
by the ranger you to contain the HTML escape characters.

For example, if I name a policy mydb->mytable, then when that policy is edited 
and saved in the UI, its name will change to mydb-mytable. Because the 
ampersand is itself an HTML escaped character, if I save the policy again, this 
name will be changed to mydb-gt;mytable.Etc..


Diffs
-

  security-admin/src/main/webapp/scripts/models/RangerPolicy.js 30e36ac 
  security-admin/src/main/webapp/scripts/modules/globalize/message/en.js 
8d921f7 
  security-admin/src/main/webapp/scripts/utils/XAUtils.js 79f397e 
  security-admin/src/main/webapp/scripts/views/policies/RangerPolicyForm.js 
b82654e 


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


Testing
---

Verified CRUD operation for policy.


Thanks,

Nitin Galave

[jira] [Updated] (RANGER-2487) Resource policy names with a characters that are typically HTML escaped mutate and grow as they are saved.

[Nitin Galave (JIRA)]

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

Nitin Galave updated RANGER-2487:
-
Attachment: 0001-RANGER-2487.patch

> Resource policy names with a characters that are typically HTML escaped 
> mutate and grow as they are saved.
> --
>
> Key: RANGER-2487
> URL: https://issues.apache.org/jira/browse/RANGER-2487
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Reporter: Nitin Galave
>Assignee: Nitin Galave
>Priority: Major
> Attachments: 0001-RANGER-2487.patch
>
>
> If a resource based policy is given a name that contains a character that is 
> typically HTML escape, such as the greater than sign '>', which is HTML 
> escaped '>', then whenever that policy is saved, the name of the policy will 
> be changed by the ranger you to contain the HTML escape characters.
> For example, if I name a policy mydb->mytable, then when that policy is 
> edited and saved in the UI, its name will change to mydb-mytable. Because 
> the ampersand is itself an HTML escaped character, if I save the policy 
> again, this name will be changed to mydb-gt;mytable.Etc..



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

[jira] [Updated] (RANGER-2458) Cluster property name changes in Ranger Plugin code

[Velmurugan Periasamy (JIRA)]

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

Velmurugan Periasamy updated RANGER-2458:
-
Fix Version/s: 2.0.0

> Cluster property name changes in Ranger Plugin code
> ---
>
> Key: RANGER-2458
> URL: https://issues.apache.org/jira/browse/RANGER-2458
> Project: Ranger
>  Issue Type: Improvement
>  Components: Ranger
>Reporter: bhavik patel
>Assignee: bhavik patel
>Priority: Major
> Fix For: 2.0.0
>
> Attachments: RANGER-2458-01.patch, RANGER-2458-02.patch, 
> RANGER-2458.patch
>
>
> – Property ranger.plugin.hive.ambari.cluster.name is added in 
> ranger-hive-audit.xml; consider moving it to ranger-hive-security.xml.
> – The property name should be renamed to something like: 
> ranger.plugin.hive.access.cluster.name. i.e. replace ‘ambari’ with ‘access’.
> – Also "ambari.service.check.user" config used during service creation needs 
> to remove "ambari" from it.



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

[jira] [Updated] (RANGER-2467) similar to clusterName custom condition, add clusterType custom condition.

[Velmurugan Periasamy (JIRA)]

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

Velmurugan Periasamy updated RANGER-2467:
-
Description: 
add clusterType custome condition,This will help with custom conditions like 
“Accessed from cluster type?”

Similar to https://issues.apache.org/jira/browse/RANGER-2436

  was:add clusterType custome condition,This will help with custom conditions 
like “Accessed from cluster type?”


> similar to clusterName custom condition, add clusterType custom condition.
> --
>
> Key: RANGER-2467
> URL: https://issues.apache.org/jira/browse/RANGER-2467
> Project: Ranger
>  Issue Type: Improvement
>  Components: Ranger
>Reporter: Nikhil Purbhe
>Assignee: Mateen Mansoori
>Priority: Major
> Fix For: 2.0.0
>
>
> add clusterType custome condition,This will help with custom conditions like 
> “Accessed from cluster type?”
> Similar to https://issues.apache.org/jira/browse/RANGER-2436



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

[jira] [Updated] (RANGER-2467) similar to clusterName custom condition, add clusterType custom condition.

[Velmurugan Periasamy (JIRA)]

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

Velmurugan Periasamy updated RANGER-2467:
-
Summary: similar to clusterName custom condition, add clusterType custom 
condition.  (was: similar to clusterName custom condition, add clusterType 
custome condition.)

> similar to clusterName custom condition, add clusterType custom condition.
> --
>
> Key: RANGER-2467
> URL: https://issues.apache.org/jira/browse/RANGER-2467
> Project: Ranger
>  Issue Type: Improvement
>  Components: Ranger
>Reporter: Nikhil Purbhe
>Assignee: Mateen Mansoori
>Priority: Major
> Fix For: 2.0.0
>
>
> add clusterType custome condition,This will help with custom conditions like 
> “Accessed from cluster type?”



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

[jira] [Updated] (RANGER-2466) Improvement in setting cluster Name in RangerAccessRequest

[Velmurugan Periasamy (JIRA)]

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

Velmurugan Periasamy updated RANGER-2466:
-
Fix Version/s: 2.0.0

> Improvement in setting cluster Name in RangerAccessRequest
> --
>
> Key: RANGER-2466
> URL: https://issues.apache.org/jira/browse/RANGER-2466
> Project: Ranger
>  Issue Type: Improvement
>  Components: Ranger
>Reporter: Nikhil Purbhe
>Assignee: Nikhil Purbhe
>Priority: Major
> Fix For: 2.0.0
>
> Attachments: 
> RANGER-2466-Improvement-in-setting-cluster-Name-in-R.patch
>
>
> handling Clustername setting part during Policy engine instantiation.



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

[jira] [Created] (RANGER-2487) Resource policy names with a characters that are typically HTML escaped mutate and grow as they are saved.

[Nitin Galave (JIRA)]

Nitin Galave created RANGER-2487:


 Summary: Resource policy names with a characters that are 
typically HTML escaped mutate and grow as they are saved.
 Key: RANGER-2487
 URL: https://issues.apache.org/jira/browse/RANGER-2487
 Project: Ranger
  Issue Type: Bug
  Components: Ranger
Reporter: Nitin Galave
Assignee: Nitin Galave


If a resource based policy is given a name that contains a character that is 
typically HTML escape, such as the greater than sign '>', which is HTML escaped 
'>', then whenever that policy is saved, the name of the policy will be changed 
by the ranger you to contain the HTML escape characters.

For example, if I name a policy mydb->mytable, then when that policy is edited 
and saved in the UI, its name will change to mydb-mytable. Because the 
ampersand is itself an HTML escaped character, if I save the policy again, this 
name will be changed to mydb-gt;mytable.Etc..



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

[jira] [Updated] (RANGER-2467) similar to clusterName custom condition, add clusterType custome condition.

[Velmurugan Periasamy (JIRA)]

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

Velmurugan Periasamy updated RANGER-2467:
-
Fix Version/s: 2.0.0

> similar to clusterName custom condition, add clusterType custome condition.
> ---
>
> Key: RANGER-2467
> URL: https://issues.apache.org/jira/browse/RANGER-2467
> Project: Ranger
>  Issue Type: Improvement
>  Components: Ranger
>Reporter: Nikhil Purbhe
>Assignee: Mateen Mansoori
>Priority: Major
> Fix For: 2.0.0
>
>
> add clusterType custome condition,This will help with custom conditions like 
> “Accessed from cluster type?”



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

[jira] [Commented] (RANGER-2452) Release Ranger 2.0.0

[Velmurugan Periasamy (JIRA)]

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

Velmurugan Periasamy commented on RANGER-2452:
--

Hello [~pengbo] - waiting for JIRAs to be resolved. Once done, I will start the 
release activities. Thanks. 

> Release Ranger 2.0.0
> 
>
> Key: RANGER-2452
> URL: https://issues.apache.org/jira/browse/RANGER-2452
> Project: Ranger
>  Issue Type: Task
>  Components: Ranger
>Reporter: Velmurugan Periasamy
>Assignee: Velmurugan Periasamy
>Priority: Major
> Fix For: 2.0.0
>
>
> Track release activities for Ranger 2.0.0



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

[jira] [Updated] (RANGER-2425) Enhance ranger hive plugin to support sql role commands

[Velmurugan Periasamy (JIRA)]

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

Velmurugan Periasamy updated RANGER-2425:
-
Fix Version/s: 2.0.0

> Enhance ranger hive plugin to support sql role commands
> ---
>
> Key: RANGER-2425
> URL: https://issues.apache.org/jira/browse/RANGER-2425
> Project: Ranger
>  Issue Type: New Feature
>  Components: Ranger
>Reporter: Sailaja Polavarapu
>Assignee: Sailaja Polavarapu
>Priority: Major
> Fix For: 2.0.0
>
>
> As an extension to https://issues.apache.org/jira/browse/RANGER-2414, enhance 
> ranger hive plugin to support sql role commands:
> [https://cwiki.apache.org/confluence/display/Hive/SQL+Standard+Based+Hive+Authorization#SQLStandardBasedHiveAuthorization-UsersandRoles]



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

[jira] [Created] (RANGER-2486) ranger-tagsync tags.json file multi-service-rules

[Konstantin Tsypin (JIRA)]

Konstantin Tsypin created RANGER-2486:
-

 Summary: ranger-tagsync tags.json file multi-service-rules
 Key: RANGER-2486
 URL: https://issues.apache.org/jira/browse/RANGER-2486
 Project: Ranger
  Issue Type: Wish
  Components: tagsync
Reporter: Konstantin Tsypin


Hi there!

I'd try to made the ranger-tagsync file with multiple rules.

For example, at the one hand, next case is work correct for HIVE-service at 
practice:

{code}

{
 "op": "add_or_update",
 "serviceName": "AUTH_HIVE",
 "tagVersion": 3,
 "tagDefinitions": {
 "1":\{"id":1, "guid":"tagdef-1", "name":"PAD", "attributeDefs":[], "owner":0},
 "2":\{"id":2, "guid":"tagdef-2", "name":"PII", "attributeDefs":[], "owner":0}
 },
 "tags": {
 "1": {
 "type": "PAD",
 "attributes": {},
 "id": 1,
 "guid": "tag-pad-1-guid"
 },
 "2": {
 "type": "PII",
 "attributes": {},
 "id": 2,
 "guid": "tag-pii-2-guid"
 }
 },
 "serviceResources": [
 {
 "serviceName": "AUTH_HIVE",
 "resourceElements": {
 "database": \{ "values": [ "default" ] },
 "table": \{ "values": [ "personal_data" ] },
 "column": \{ "values": [ "address" ] }
 },
 "id": 1,
 "guid": "employee.personal.address-guid"
 },
 {
 "serviceName": "AUTH_HIVE",
 "resourceElements": {
 "database": \{ "values": [ "default" ] },
 "table": \{ "values": [ "personal_data" ] },
 "column": \{ "values": [ "phone" ] }
 },
 "id": 2,
 "guid": "employee.personal.phone-guid"
 }
 ],
 "resourceToTagIds": {
 "1": [ 1 ],
 "2": [ 2 ]
 }
 }

{code}

 

on the other hand, next case work correct for HBASE-service:

{code}

{
 "op": "add_or_update",
 "serviceName": "AUTH_HBASE",
 "tagVersion": 3,
 "tagDefinitions": {
 "1":\{"id":1, "guid":"tagdef-hb1", "name":"PII", "attributeDefs":[], "owner":0}
 },
 "tags": {
 "1": {
 "type": "PII",
 "attributes": {},
 "id": 1,
 "guid": "tag-pii-hb1-guid"
 }
 },
 "serviceResources": [
 {
 "serviceName": "AUTH_HBASE",
 "resourceElements": {
 "table": \{ "values": [ "default:weblog" ] },
 "column-family": \{ "values": [ "user_profile" ] }
 },
 "id": 1,
 "guid": "weblog.user.profile-guid"
 }
 ],
 "resourceToTagIds": {
 "1": [ 1 ]
 }
 }

{code}

 

anyway, i'm prefer to concatenate this json-strings to independent tagsync.json 
file, and cant understand union-rules.

The:

[\{hive},\{hbase}] scheme does not work.

Does it work? Do you have any expirience, advices, or documentation to resolve 
this?

l'll be pretty gratitude.



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

[jira] [Commented] (RANGER-2452) Release Ranger 2.0.0

[peng bo (JIRA)]

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

peng bo commented on RANGER-2452:
-

Hello [~vperiasamy],

Any update on 2.0.0 release please? 

> Release Ranger 2.0.0
> 
>
> Key: RANGER-2452
> URL: https://issues.apache.org/jira/browse/RANGER-2452
> Project: Ranger
>  Issue Type: Task
>  Components: Ranger
>Reporter: Velmurugan Periasamy
>Assignee: Velmurugan Periasamy
>Priority: Major
> Fix For: 2.0.0
>
>
> Track release activities for Ranger 2.0.0



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

[jira] [Updated] (RANGER-2485) Security zone filter is causing Ranger audit access request waiting for longer

[Pradeep Agrawal (JIRA)]

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

Pradeep Agrawal updated RANGER-2485:

Attachment: 0001-RANGER-2485-Security-zone-filter-is-causing-Ranger-a.patch

> Security zone filter is causing Ranger audit access request waiting for longer
> --
>
> Key: RANGER-2485
> URL: https://issues.apache.org/jira/browse/RANGER-2485
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Affects Versions: 2.0.0
>Reporter: Pradeep Agrawal
>Assignee: Pradeep Agrawal
>Priority: Major
> Fix For: 2.0.0
>
> Attachments: 
> 0001-RANGER-2485-Security-zone-filter-is-causing-Ranger-a.patch
>
>




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

[jira] [Updated] (RANGER-2484) Improve import API to merge the policies if resources are exactly same

[Pradeep Agrawal (JIRA)]

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

Pradeep Agrawal updated RANGER-2484:

Attachment: 0001-RANGER-2484-Improve-import-API-to-merge-the-policies.patch

> Improve import API to merge the policies if resources are exactly same
> --
>
> Key: RANGER-2484
> URL: https://issues.apache.org/jira/browse/RANGER-2484
> Project: Ranger
>  Issue Type: Improvement
>  Components: Ranger
>Affects Versions: 2.0.0
>Reporter: Pradeep Agrawal
>Assignee: Pradeep Agrawal
>Priority: Major
> Fix For: 2.0.0
>
> Attachments: 
> 0001-RANGER-2484-Improve-import-API-to-merge-the-policies.patch
>
>
> Observing failure while importing permissions into ranger using ranger import 
> API( /service/plugins/policies/importPoliciesFromFile?updateIfExists=true).
> *Precondition:*
>  * Create a ranger policy for resource "db1/table1/column1" with policy name 
> policy-1 in service hivedev.
> *Reproduction Steps:*
>  * Import permissions for resource "db1/table1/column1" which has policy name 
> policy-2 into hivedev service using import API mentioned above.
> This results in below failure
> {noformat}
>  Validation failure: error code[3010], reason[Another policy already exists 
> for matching resource: policy-name=[policy-1], service=[hivedev]], 
> field[resources], subfield[null], type[semantically incorrect] 
> {noformat}
> This issue will be seen only when there is a policy that already exists for 
> the resource with *different policy name* from the one that is being 
> imported. If the policy names match, the policy is updated properly.



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

[jira] [Created] (RANGER-2485) Security zone filter is causing Ranger audit access request waiting for longer

[Pradeep Agrawal (JIRA)]

Pradeep Agrawal created RANGER-2485:
---

 Summary: Security zone filter is causing Ranger audit access 
request waiting for longer
 Key: RANGER-2485
 URL: https://issues.apache.org/jira/browse/RANGER-2485
 Project: Ranger
  Issue Type: Bug
  Components: Ranger
Affects Versions: 2.0.0
Reporter: Pradeep Agrawal
Assignee: Pradeep Agrawal
 Fix For: 2.0.0






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

[jira] [Updated] (RANGER-2484) Improve import API to merge the policies if resources are exactly same

[Pradeep Agrawal (JIRA)]

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

Pradeep Agrawal updated RANGER-2484:

Description: 
Observing failure while importing permissions into ranger using ranger import 
API( /service/plugins/policies/importPoliciesFromFile?updateIfExists=true).

*Precondition:*
 * Create a ranger policy for resource "db1/table1/column1" with policy name 
policy-1 in service hivedev.

*Reproduction Steps:*
 * Import permissions for resource "db1/table1/column1" which has policy name 
policy-2 into hivedev service using import API mentioned above.

This results in below failure
{noformat}
 Validation failure: error code[3010], reason[Another policy already exists for 
matching resource: policy-name=[policy-1], service=[hivedev]], 
field[resources], subfield[null], type[semantically incorrect] 
{noformat}
This issue will be seen only when there is a policy that already exists for the 
resource with *different policy name* from the one that is being imported. If 
the policy names match, the policy is updated properly.

> Improve import API to merge the policies if resources are exactly same
> --
>
> Key: RANGER-2484
> URL: https://issues.apache.org/jira/browse/RANGER-2484
> Project: Ranger
>  Issue Type: Improvement
>  Components: Ranger
>Affects Versions: 2.0.0
>Reporter: Pradeep Agrawal
>Assignee: Pradeep Agrawal
>Priority: Major
> Fix For: 2.0.0
>
>
> Observing failure while importing permissions into ranger using ranger import 
> API( /service/plugins/policies/importPoliciesFromFile?updateIfExists=true).
> *Precondition:*
>  * Create a ranger policy for resource "db1/table1/column1" with policy name 
> policy-1 in service hivedev.
> *Reproduction Steps:*
>  * Import permissions for resource "db1/table1/column1" which has policy name 
> policy-2 into hivedev service using import API mentioned above.
> This results in below failure
> {noformat}
>  Validation failure: error code[3010], reason[Another policy already exists 
> for matching resource: policy-name=[policy-1], service=[hivedev]], 
> field[resources], subfield[null], type[semantically incorrect] 
> {noformat}
> This issue will be seen only when there is a policy that already exists for 
> the resource with *different policy name* from the one that is being 
> imported. If the policy names match, the policy is updated properly.



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

[jira] [Created] (RANGER-2484) Improve import API to merge the policies if resources are exactly same

[Pradeep Agrawal (JIRA)]

Pradeep Agrawal created RANGER-2484:
---

 Summary: Improve import API to merge the policies if resources are 
exactly same
 Key: RANGER-2484
 URL: https://issues.apache.org/jira/browse/RANGER-2484
 Project: Ranger
  Issue Type: Improvement
  Components: Ranger
Affects Versions: 2.0.0
Reporter: Pradeep Agrawal
Assignee: Pradeep Agrawal
 Fix For: 2.0.0






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

[jira] [Commented] (RANGER-2458) Cluster property name changes in Ranger Plugin code

[Pradeep Agrawal (JIRA)]

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

Pradeep Agrawal commented on RANGER-2458:
-

[https://github.com/apache/ranger/commit/9d8e5274f60b0104a0788a028b9ab91ba72e8d73]

> Cluster property name changes in Ranger Plugin code
> ---
>
> Key: RANGER-2458
> URL: https://issues.apache.org/jira/browse/RANGER-2458
> Project: Ranger
>  Issue Type: Improvement
>  Components: Ranger
>Reporter: bhavik patel
>Assignee: bhavik patel
>Priority: Major
> Attachments: RANGER-2458-01.patch, RANGER-2458-02.patch, 
> RANGER-2458.patch
>
>
> – Property ranger.plugin.hive.ambari.cluster.name is added in 
> ranger-hive-audit.xml; consider moving it to ranger-hive-security.xml.
> – The property name should be renamed to something like: 
> ranger.plugin.hive.access.cluster.name. i.e. replace ‘ambari’ with ‘access’.
> – Also "ambari.service.check.user" config used during service creation needs 
> to remove "ambari" from it.



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