[jira] [Commented] (RANGER-2599) Add more audit data to HBase grant/revoke events
[
https://issues.apache.org/jira/browse/RANGER-2599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16945922#comment-16945922
]
Zsombor Gegesy commented on RANGER-2599:
Thanks for your patch, the commit is merged to
[master|https://github.com/apache/ranger/commit/0011a441d0151c9eeec78ab1e5b9e3e3262129b8]
> Add more audit data to HBase grant/revoke events
>
>
> Key: RANGER-2599
> URL: https://issues.apache.org/jira/browse/RANGER-2599
> Project: Ranger
> Issue Type: Improvement
> Components: audit
>Affects Versions: 2.0.0
>Reporter: Andor Molnar
>Priority: Major
> Labels: patch-available
> Fix For: 2.1.0
>
>
> Currently {{RangerAuthorizationCoprocessor}} correctly captures all data from
> HBase grant and revoke events, but {{RangerBasePlugin}} only copies certain
> fields to RangerAccessEvent.
> {{RequestData}} is one the fields which are copied to the final entity and
> currently not being used by the co-processor. I'd like to add some missing
> information to this field and make it available on the UI similarly how Hive
> queries are shown in a small pop-up.
> First, I change the co-processor to populate {{RequestData}} with additional
> grant/revoke information.
> Second, I modify JS to show the RequestData pop-up on HBase audit events too.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (RANGER-2599) Add more audit data to HBase grant/revoke events
[
https://issues.apache.org/jira/browse/RANGER-2599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16941845#comment-16941845
]
Zsombor Gegesy commented on RANGER-2599:
Sorry, I can't assign this ticket to you, Andor.
> Add more audit data to HBase grant/revoke events
>
>
> Key: RANGER-2599
> URL: https://issues.apache.org/jira/browse/RANGER-2599
> Project: Ranger
> Issue Type: Improvement
> Components: audit
>Affects Versions: 2.0.0
>Reporter: Andor Molnar
>Priority: Major
> Fix For: 2.1.0
>
>
> Currently {{RangerAuthorizationCoprocessor}} correctly captures all data from
> HBase grant and revoke events, but {{RangerBasePlugin}} only copies certain
> fields to RangerAccessEvent.
> {{RequestData}} is one the fields which are copied to the final entity and
> currently not being used by the co-processor. I'd like to add some missing
> information to this field and make it available on the UI similarly how Hive
> queries are shown in a small pop-up.
> First, I change the co-processor to populate {{RequestData}} with additional
> grant/revoke information.
> Second, I modify JS to show the RequestData pop-up on HBase audit events too.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (RANGER-2599) Add more audit data to HBase grant/revoke events
[
https://issues.apache.org/jira/browse/RANGER-2599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zsombor Gegesy updated RANGER-2599:
---
Fix Version/s: 2.1.0
> Add more audit data to HBase grant/revoke events
>
>
> Key: RANGER-2599
> URL: https://issues.apache.org/jira/browse/RANGER-2599
> Project: Ranger
> Issue Type: Improvement
> Components: audit
>Affects Versions: 2.0.0
>Reporter: Andor Molnar
>Priority: Major
> Fix For: 2.1.0
>
>
> Currently {{RangerAuthorizationCoprocessor}} correctly captures all data from
> HBase grant and revoke events, but {{RangerBasePlugin}} only copies certain
> fields to RangerAccessEvent.
> {{RequestData}} is one the fields which are copied to the final entity and
> currently not being used by the co-processor. I'd like to add some missing
> information to this field and make it available on the UI similarly how Hive
> queries are shown in a small pop-up.
> First, I change the co-processor to populate {{RequestData}} with additional
> grant/revoke information.
> Second, I modify JS to show the RequestData pop-up on HBase audit events too.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (RANGER-2599) Add more audit data to HBase grant/revoke events
[
https://issues.apache.org/jira/browse/RANGER-2599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zsombor Gegesy updated RANGER-2599:
---
Affects Version/s: 2.0.0
> Add more audit data to HBase grant/revoke events
>
>
> Key: RANGER-2599
> URL: https://issues.apache.org/jira/browse/RANGER-2599
> Project: Ranger
> Issue Type: Improvement
> Components: audit
>Affects Versions: 2.0.0
>Reporter: Andor Molnar
>Priority: Major
>
> Currently {{RangerAuthorizationCoprocessor}} correctly captures all data from
> HBase grant and revoke events, but {{RangerBasePlugin}} only copies certain
> fields to RangerAccessEvent.
> {{RequestData}} is one the fields which are copied to the final entity and
> currently not being used by the co-processor. I'd like to add some missing
> information to this field and make it available on the UI similarly how Hive
> queries are shown in a small pop-up.
> First, I change the co-processor to populate {{RequestData}} with additional
> grant/revoke information.
> Second, I modify JS to show the RequestData pop-up on HBase audit events too.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (RANGER-2394) Filter/exclude multiple users in audit search
[ https://issues.apache.org/jira/browse/RANGER-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy resolved RANGER-2394. Resolution: Fixed Merged into [master|https://github.com/apache/ranger/commit/444db6edb092f23de89813503dae04f909e5325e] > Filter/exclude multiple users in audit search > - > > Key: RANGER-2394 > URL: https://issues.apache.org/jira/browse/RANGER-2394 > Project: Ranger > Issue Type: Improvement > Components: admin >Affects Versions: master >Reporter: Zsombor Gegesy >Assignee: Zsombor Gegesy >Priority: Major > Labels: admin, solr > Fix For: 2.0.0 > > Attachments: RANGER-2394-5.patch, RANGER-2394-6.patch, > RANGER-2394.patch > > > Currently the audit search only allows to: > * filter to one user's activity > * exclude all 'service users' from every user's activity. > If there were way to search for multiple users or exclude multiple users from > the search list, it would make debugging complex interactions simpler, for > example only look for actions for 'alice' and 'hive' and 'yarn' -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (RANGER-2394) Filter/exclude multiple users in audit search
[ https://issues.apache.org/jira/browse/RANGER-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy updated RANGER-2394: --- Attachment: RANGER-2394-6.patch > Filter/exclude multiple users in audit search > - > > Key: RANGER-2394 > URL: https://issues.apache.org/jira/browse/RANGER-2394 > Project: Ranger > Issue Type: Improvement > Components: admin >Affects Versions: master >Reporter: Zsombor Gegesy >Assignee: Zsombor Gegesy >Priority: Major > Labels: admin, solr > Fix For: 2.0.0 > > Attachments: RANGER-2394-5.patch, RANGER-2394-6.patch, > RANGER-2394.patch > > > Currently the audit search only allows to: > * filter to one user's activity > * exclude all 'service users' from every user's activity. > If there were way to search for multiple users or exclude multiple users from > the search list, it would make debugging complex interactions simpler, for > example only look for actions for 'alice' and 'hive' and 'yarn' -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (RANGER-2394) Filter/exclude multiple users in audit search
[ https://issues.apache.org/jira/browse/RANGER-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy updated RANGER-2394: --- Attachment: RANGER-2394-5.patch > Filter/exclude multiple users in audit search > - > > Key: RANGER-2394 > URL: https://issues.apache.org/jira/browse/RANGER-2394 > Project: Ranger > Issue Type: Improvement > Components: admin >Affects Versions: master >Reporter: Zsombor Gegesy >Assignee: Zsombor Gegesy >Priority: Major > Labels: admin, solr > Fix For: 2.0.0 > > Attachments: RANGER-2394-5.patch, RANGER-2394.patch > > > Currently the audit search only allows to: > * filter to one user's activity > * exclude all 'service users' from every user's activity. > If there were way to search for multiple users or exclude multiple users from > the search list, it would make debugging complex interactions simpler, for > example only look for actions for 'alice' and 'hive' and 'yarn' -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (RANGER-2421) Solr audit fails in Atlas plugin
[
https://issues.apache.org/jira/browse/RANGER-2421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zsombor Gegesy updated RANGER-2421:
---
Attachment: RANGER-2421.patch
> Solr audit fails in Atlas plugin
>
>
> Key: RANGER-2421
> URL: https://issues.apache.org/jira/browse/RANGER-2421
> Project: Ranger
> Issue Type: Bug
> Components: audit, plugins
>Reporter: Zsombor Gegesy
>Assignee: Zsombor Gegesy
>Priority: Major
> Labels: atlas, audit, plugin
> Attachments: RANGER-2421.patch
>
>
> Due to http client version difference, and the lack of httpclient-4.5.3.jar
> inside the ranger-atlas-plugin/lib/ranger-atlas-plugin-impl/ folder, the
> following exception can be seen:
> {code}
> ava.lang.NoSuchMethodError:
> org.apache.http.impl.client.HttpClientBuilder.evictIdleConnections(JLjava/util/concurrent/TimeUnit;)Lorg/apache/http/impl/client/HttpClientBuilder;
> at
> org.apache.solr.client.solrj.impl.HttpClientUtil.createClient(HttpClientUtil.java:311)
> at
> org.apache.solr.client.solrj.impl.HttpClientUtil.createClient(HttpClientUtil.java:330)
> at
> org.apache.solr.client.solrj.impl.HttpClientUtil.createClient(HttpClientUtil.java:268)
> at
> org.apache.solr.client.solrj.impl.HttpClientUtil.createClient(HttpClientUtil.java:255)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.(CloudSolrClient.java:280)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient$Builder.build(CloudSolrClient.java:1600)
> at
> org.apache.ranger.audit.destination.SolrAuditDestination$1.run(SolrAuditDestination.java:126)
> at
> org.apache.ranger.audit.destination.SolrAuditDestination$1.run(SolrAuditDestination.java:123)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1730)
> at
> org.apache.ranger.audit.provider.MiscUtil.executePrivilegedAction(MiscUtil.java:516)
> at
> org.apache.ranger.audit.destination.SolrAuditDestination.connect(SolrAuditDestination.java:123)
> at
> org.apache.ranger.audit.destination.SolrAuditDestination.init(SolrAuditDestination.java:72)
> at
> org.apache.ranger.audit.provider.AuditProviderFactory.init(AuditProviderFactory.java:179)
> at
> org.apache.ranger.plugin.service.RangerBasePlugin.init(RangerBasePlugin.java:217)
> {code}
> Atlas has a httpclient-4.4.x, which lacks the needed method.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (RANGER-2421) Solr audit fails in Atlas plugin
Zsombor Gegesy created RANGER-2421:
--
Summary: Solr audit fails in Atlas plugin
Key: RANGER-2421
URL: https://issues.apache.org/jira/browse/RANGER-2421
Project: Ranger
Issue Type: Bug
Components: audit, plugins
Reporter: Zsombor Gegesy
Assignee: Zsombor Gegesy
Due to http client version difference, and the lack of httpclient-4.5.3.jar
inside the ranger-atlas-plugin/lib/ranger-atlas-plugin-impl/ folder, the
following exception can be seen:
{code}
ava.lang.NoSuchMethodError:
org.apache.http.impl.client.HttpClientBuilder.evictIdleConnections(JLjava/util/concurrent/TimeUnit;)Lorg/apache/http/impl/client/HttpClientBuilder;
at
org.apache.solr.client.solrj.impl.HttpClientUtil.createClient(HttpClientUtil.java:311)
at
org.apache.solr.client.solrj.impl.HttpClientUtil.createClient(HttpClientUtil.java:330)
at
org.apache.solr.client.solrj.impl.HttpClientUtil.createClient(HttpClientUtil.java:268)
at
org.apache.solr.client.solrj.impl.HttpClientUtil.createClient(HttpClientUtil.java:255)
at
org.apache.solr.client.solrj.impl.CloudSolrClient.(CloudSolrClient.java:280)
at
org.apache.solr.client.solrj.impl.CloudSolrClient$Builder.build(CloudSolrClient.java:1600)
at
org.apache.ranger.audit.destination.SolrAuditDestination$1.run(SolrAuditDestination.java:126)
at
org.apache.ranger.audit.destination.SolrAuditDestination$1.run(SolrAuditDestination.java:123)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:422)
at
org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1730)
at
org.apache.ranger.audit.provider.MiscUtil.executePrivilegedAction(MiscUtil.java:516)
at
org.apache.ranger.audit.destination.SolrAuditDestination.connect(SolrAuditDestination.java:123)
at
org.apache.ranger.audit.destination.SolrAuditDestination.init(SolrAuditDestination.java:72)
at
org.apache.ranger.audit.provider.AuditProviderFactory.init(AuditProviderFactory.java:179)
at
org.apache.ranger.plugin.service.RangerBasePlugin.init(RangerBasePlugin.java:217)
{code}
Atlas has a httpclient-4.4.x, which lacks the needed method.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (RANGER-2394) Filter/exclude multiple users in audit search
[ https://issues.apache.org/jira/browse/RANGER-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy updated RANGER-2394: --- Attachment: RANGER-2394.patch > Filter/exclude multiple users in audit search > - > > Key: RANGER-2394 > URL: https://issues.apache.org/jira/browse/RANGER-2394 > Project: Ranger > Issue Type: Improvement > Components: admin >Affects Versions: master >Reporter: Zsombor Gegesy >Assignee: Zsombor Gegesy >Priority: Major > Labels: admin, solr > Fix For: 2.0.0 > > Attachments: RANGER-2394.patch > > > Currently the audit search only allows to: > * filter to one user's activity > * exclude all 'service users' from every user's activity. > If there were way to search for multiple users or exclude multiple users from > the search list, it would make debugging complex interactions simpler, for > example only look for actions for 'alice' and 'hive' and 'yarn' -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (RANGER-2394) Filter/exclude multiple users in audit search
Zsombor Gegesy created RANGER-2394: -- Summary: Filter/exclude multiple users in audit search Key: RANGER-2394 URL: https://issues.apache.org/jira/browse/RANGER-2394 Project: Ranger Issue Type: Improvement Components: admin Affects Versions: master Reporter: Zsombor Gegesy Assignee: Zsombor Gegesy Fix For: 2.0.0 Currently the audit search only allows to: * filter to one user's activity * exclude all 'service users' from every user's activity. If there were way to search for multiple users or exclude multiple users from the search list, it would make debugging complex interactions simpler, for example only look for actions for 'alice' and 'hive' and 'yarn' -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (RANGER-2386) Code duplication due to RangerCredentialProvider.getCredentialString returns char[]
[ https://issues.apache.org/jira/browse/RANGER-2386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy updated RANGER-2386: --- Attachment: RANGER-2386.patch > Code duplication due to RangerCredentialProvider.getCredentialString returns > char[] > --- > > Key: RANGER-2386 > URL: https://issues.apache.org/jira/browse/RANGER-2386 > Project: Ranger > Issue Type: Improvement > Components: plugins >Affects Versions: master >Reporter: Zsombor Gegesy >Assignee: Zsombor Gegesy >Priority: Major > Fix For: 2.0.0 > > Attachments: RANGER-2386.patch > > > The same code appears in lot's of places, because > RangerCredentialProvider.getCredentialString returns a char array, which > needs to be converted to String. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (RANGER-2386) Code duplication due to RangerCredentialProvider.getCredentialString returns char[]
Zsombor Gegesy created RANGER-2386: -- Summary: Code duplication due to RangerCredentialProvider.getCredentialString returns char[] Key: RANGER-2386 URL: https://issues.apache.org/jira/browse/RANGER-2386 Project: Ranger Issue Type: Improvement Components: plugins Affects Versions: master Reporter: Zsombor Gegesy Assignee: Zsombor Gegesy Fix For: 2.0.0 The same code appears in lot's of places, because RangerCredentialProvider.getCredentialString returns a char array, which needs to be converted to String. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (RANGER-2378) KeySecure HSM Integration is not compatible with Java9
Zsombor Gegesy created RANGER-2378:
--
Summary: KeySecure HSM Integration is not compatible with Java9
Key: RANGER-2378
URL: https://issues.apache.org/jira/browse/RANGER-2378
Project: Ranger
Issue Type: Bug
Components: kms
Reporter: Zsombor Gegesy
The patch introduced in RANGER-2331 relies on internal
sun.security.pkcs11.SunPKCS11 class, unfortunately this class changed between
Java 8 and 9, so the code no longer compiles on Java9+.
The Java8 way of doing (documented
[here|https://docs.oracle.com/javase/8/docs/technotes/guides/security/p11guide.html]
) is:
{code}
Provider p = new sun.security.pkcs11.SunPKCS11(configName);
Security.addProvider(p);
{code}
However, in Java 9, sun.security.pkcs11.SunPKCS11 doesn't have a constructor
with a String parameter, and the documentation
[suggests|https://docs.oracle.com/javase/9/security/pkcs11-reference-guide1.htm]
suggest to use:
{code}
Provider p = Security.getProvider("SunPKCS11");
p = p.configure(configName);
Security.addProvider(p);
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (RANGER-2317) Enable compilation on JDK11
[ https://issues.apache.org/jira/browse/RANGER-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy resolved RANGER-2317. Resolution: Fixed Merged to [master|https://github.com/apache/ranger/commit/08f32cd35824399eaac573f47338fbe8433ed97e] > Enable compilation on JDK11 > --- > > Key: RANGER-2317 > URL: https://issues.apache.org/jira/browse/RANGER-2317 > Project: Ranger > Issue Type: Improvement > Components: admin, plugins >Reporter: Zsombor Gegesy >Assignee: Zsombor Gegesy >Priority: Major > Fix For: master > > Attachments: RANGER-2317-2.patch, RANGER-2317-3.patch > > > Currently, Ranger can be compiled only with JDK 8, however JDK 11 is the > current LTS release for Java, it is essential to support it. As a first step, > we need to ensure that Ranger can be compiled on JDK 11. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (RANGER-2356) External user's email address can be edited
[ https://issues.apache.org/jira/browse/RANGER-2356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy resolved RANGER-2356. Resolution: Fixed Merged to [master|https://github.com/apache/ranger/commit/3e04f089c9ad5b8e749c3faa08447cbe04be6dba] - Thanks for the fix ! > External user's email address can be edited > --- > > Key: RANGER-2356 > URL: https://issues.apache.org/jira/browse/RANGER-2356 > Project: Ranger > Issue Type: Bug > Components: admin >Affects Versions: master >Reporter: László Dénes Terjéki >Priority: Major > Labels: email > Attachments: > 0001-RANGER-2356-Ranger-UI-disable-email-editing-for-Exte.patch, Screenshot > 2019-03-12 at 13.30.46.png > > > In Settings -> Users/Groups clicking on an external user the email field is > editable while the "User Name", "First Name" and "Last Name" fields are > disabled. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (RANGER-2336) Ranger HBase plugin should pack guava lib as a dependency.
[
https://issues.apache.org/jira/browse/RANGER-2336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16778605#comment-16778605
]
Zsombor Gegesy commented on RANGER-2336:
In [this
commit|https://github.com/apache/ranger/commit/092320830f89bc426e68e4fe8a3e5e3255693571]
(for RANGER-2232), all the MoreObjects usage was removed - so I think, the
original
[fix|https://github.com/apache/ranger/commit/a5d212871588211870b711cd6ec5f3650c14079d]
can be reverted.
> Ranger HBase plugin should pack guava lib as a dependency.
> --
>
> Key: RANGER-2336
> URL: https://issues.apache.org/jira/browse/RANGER-2336
> Project: Ranger
> Issue Type: Bug
> Components: Ranger
>Affects Versions: master, 2.0.0
>Reporter: Ramesh Mani
>Assignee: Ramesh Mani
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments:
> 0001-RANGER-2336-Ranger-HBase-plugin-should-pack-guava-li.patch
>
>
> Ranger HBase plugin should pack guava lib as a dependency. This is avoid run
> time exception in debug mode, which crashes HBase
>
> {code:java}
> ABORTING region server
> ctr-e139-1542663976389-66118-01-09.hwx.site,16020,1550008218797: The
> coprocessor
> org.apache.ranger.authorization.hbase.RangerAuthorizationCoprocessor threw
> java.lang.NoClassDefFoundError: com/google/common/base/MoreObjects *
> Cause:
> java.lang.NoClassDefFoundError: com/google/common/base/MoreObjects
> at
> org.apache.ranger.authorization.hbase.RangerAuthorizationCoprocessor$ColumnFamilyAccessResult.toString(RangerAuthorizationCoprocessor.java:288)
> at
> org.apache.ranger.authorization.hbase.RangerAuthorizationCoprocessor.evaluateAccess(RangerAuthorizationCoprocessor.java:330)
> at
> org.apache.ranger.authorization.hbase.RangerAuthorizationCoprocessor.authorizeAccess(RangerAuthorizationCoprocessor.java:531)
> at
> org.apache.ranger.authorization.hbase.RangerAuthorizationCoprocessor.preGetOp(RangerAuthorizationCoprocessor.java:1130)
> at
> org.apache.ranger.authorization.hbase.RangerAuthorizationCoprocessor.preGetOp(RangerAuthorizationCoprocessor.java:927)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost$19.call(RegionCoprocessorHost.java:831)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost$19.call(RegionCoprocessorHost.java:828)
> at
> org.apache.hadoop.hbase.coprocessor.CoprocessorHost$ObserverOperationWithoutResult.callObserver(CoprocessorHost.java:540)
> at
> org.apache.hadoop.hbase.coprocessor.CoprocessorHost.execOperation(CoprocessorHost.java:614)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.preGet(RegionCoprocessorHost.java:828)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.get(RSRpcServices.java:2530)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.get(RSRpcServices.java:2470)
> at
> org.apache.hadoop.hbase.shaded.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:41998)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:413)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:131)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:324)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:304)
> Caused by: java.lang.ClassNotFoundException:
> com.google.common.base.MoreObjects
> at java.lang.ClassLoader.findClass(ClassLoader.java:530)
> at
> org.apache.ranger.plugin.classloader.RangerPluginClassLoader$MyClassLoader.findClass(RangerPluginClassLoader.java:272)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at
> org.apache.ranger.plugin.classloader.RangerPluginClassLoader.loadClass(RangerPluginClassLoader.java:125)
> .{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (RANGER-2317) Enable compilation on JDK11
[ https://issues.apache.org/jira/browse/RANGER-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy updated RANGER-2317: --- Attachment: RANGER-2317-3.patch > Enable compilation on JDK11 > --- > > Key: RANGER-2317 > URL: https://issues.apache.org/jira/browse/RANGER-2317 > Project: Ranger > Issue Type: Improvement > Components: admin, plugins >Reporter: Zsombor Gegesy >Assignee: Zsombor Gegesy >Priority: Major > Fix For: master > > Attachments: RANGER-2317-2.patch, RANGER-2317-3.patch > > > Currently, Ranger can be compiled only with JDK 8, however JDK 11 is the > current LTS release for Java, it is essential to support it. As a first step, > we need to ensure that Ranger can be compiled on JDK 11. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (RANGER-2287) Improve and optimize db_setup.py file code
[ https://issues.apache.org/jira/browse/RANGER-2287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16749768#comment-16749768 ] Zsombor Gegesy commented on RANGER-2287: Awesome, you removed nearly 4000 lines of code, I'm impressed ! > Improve and optimize db_setup.py file code > -- > > Key: RANGER-2287 > URL: https://issues.apache.org/jira/browse/RANGER-2287 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Reporter: Pradeep Agrawal >Assignee: Pradeep Agrawal >Priority: Major > Fix For: 2.0.0 > > Attachments: > 0001-RANGER-2287-Improve-and-optimize-db_setup.py-file-co.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (RANGER-2321) Docker build fails due to PhantomJS dependency
[
https://issues.apache.org/jira/browse/RANGER-2321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zsombor Gegesy updated RANGER-2321:
---
Fix Version/s: 2.0.0
> Docker build fails due to PhantomJS dependency
> --
>
> Key: RANGER-2321
> URL: https://issues.apache.org/jira/browse/RANGER-2321
> Project: Ranger
> Issue Type: Bug
> Components: admin
>Affects Versions: 2.0.0
>Reporter: Csaba Koncz
>Assignee: Csaba Koncz
>Priority: Major
> Fix For: 2.0.0
>
> Attachments:
> 0001-RANGER-2321-Docker-build-fails-due-to-PhantomJS-depe.patch
>
>
> Docker build fails in an early phase do to the PhantomJS dependency
> introduced in RANGER-2255. E.g. running
> {code:java}
> ./build_ranger_using_docker.sh mvn clean verify -am -pl security-admin{code}
> results in
> {code:java}
> [INFO] < org.apache.ranger:security-admin-web
> >
> [INFO] Building Security Admin Web Application 2.0.0-SNAPSHOT [7/7]
> [INFO] [ war
> ]-
> [INFO]
> [INFO] --- maven-clean-plugin:2.6.1:clean (default-clean) @
> security-admin-web ---
> [INFO]
> [INFO] --- maven-enforcer-plugin:1.4.1:enforce (enforce-maven-version) @
> security-admin-web ---
> [INFO]
> [INFO] --- maven-enforcer-plugin:1.4.1:enforce (enforce-versions) @
> security-admin-web ---
> [INFO]
> [INFO] --- maven-resources-plugin:2.7:copy-resources (copy-resources) @
> security-admin-web ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 2 resources
> [INFO]
> [INFO] --- maven-remote-resources-plugin:1.5:process
> (process-resource-bundles) @ security-admin-web ---
> [INFO]
> [INFO] --- maven-resources-plugin:2.7:resources (default-resources) @
> security-admin-web ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 22 resources
> [INFO] Copying 3 resources
> [INFO]
> [INFO] --- maven-antrun-plugin:1.7:run (default) @ security-admin-web ---
> [INFO] Executing tasks
> main:
> [INFO] Executed tasks
> [INFO]
> [INFO] --- frontend-maven-plugin:1.6:install-node-and-npm (install node and
> npm) @ security-admin-web ---
> [INFO] Installing node version v8.12.0
> [INFO] Unpacking
> /home/builder/.m2/repository/com/github/eirslett/node/8.12.0/node-8.12.0-linux-x64.tar.gz
> into /ranger/security-admin/target/node/tmp
> [INFO] Copying node binary from
> /ranger/security-admin/target/node/tmp/node-v8.12.0-linux-x64/bin/node to
> /ranger/security-admin/target/node/node
> [INFO] Installed node locally.
> [INFO] Installing npm version 6.4.1
> [INFO] Unpacking
> /home/builder/.m2/repository/com/github/eirslett/npm/6.4.1/npm-6.4.1.tar.gz
> into /ranger/security-admin/target/node/node_modules
> [INFO] Installed npm locally.
> [INFO]
> [INFO] --- frontend-maven-plugin:1.6:npm (npm install) @ security-admin-web
> ---
> [INFO] Running 'npm install' in /ranger/security-admin/target
> [INFO]
> [INFO] > phantomjs-prebuilt@2.1.16 install
> /ranger/security-admin/target/node_modules/karma-phantomjs-launcher/node_modules/phantomjs-prebuilt
> [INFO] > node install.js
> [INFO]
> [INFO] PhantomJS not found on PATH
> [INFO] Downloading
> https://github.com/Medium/phantomjs/releases/download/v2.1.1/phantomjs-2.1.1-linux-x86_64.tar.bz2
> [INFO] Saving to /tmp/phantomjs/phantomjs-2.1.1-linux-x86_64.tar.bz2
> [INFO] Receiving...
> [INFO]
> [INFO] Received 22866K total.
> [INFO] Extracting tar contents (via spawned process)
> [ERROR] Error extracting archive
> [ERROR] Phantom installation failed { Error: Command failed: tar jxf
> /tmp/phantomjs/phantomjs-2.1.1-linux-x86_64.tar.bz2
> [ERROR] tar (child): bzip2: Cannot exec: No such file or directory
> [ERROR] tar (child): Error is not recoverable: exiting now
> [ERROR] tar: Child returned status 2
> [ERROR] tar: Error is not recoverable: exiting now
> [ERROR]
> [ERROR] at ChildProcess.exithandler (child_process.js:276:12)
> [ERROR] at emitTwo (events.js:126:13)
> [ERROR] at ChildProcess.emit (events.js:214:7)
> [ERROR] at maybeClose (internal/child_process.js:915:16)
> [ERROR] at Socket.stream.socket.on (internal/child_process.js:336:11)
> [ERROR] at emitOne (events.js:116:13)
> [ERROR] at Socket.emit (events.js:211:7)
> [ERROR] at Pipe._handle.close [as _onclose] (net.js:561:12)
> [ERROR] killed: false,
> [ERROR] code: 2,
> [ERROR] signal: null,
> [ERROR] cmd: 'tar jxf /tmp/phantomjs/phantomjs-2.1.1-linux-x86_64.tar.bz2' }
> Error: Command failed: tar jxf
> /tmp/phantomjs/phantomjs-2.1.1-linux-x86_64.tar.bz2
> [ERROR] tar (child): bzip2: Cannot exec: No such file or directory
> [ERROR] tar (child): Error is not recoverable: exiting now
> [ERROR] tar: Child returned status 2
> [ERROR] tar: Error is not recoverable: exiting now
> [ERROR]
> [ERROR] at
[jira] [Resolved] (RANGER-2321) Docker build fails due to PhantomJS dependency
[
https://issues.apache.org/jira/browse/RANGER-2321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zsombor Gegesy resolved RANGER-2321.
Resolution: Fixed
Thanks for the patch, it has been merged to
[master|https://github.com/apache/ranger/commit/2a7782db30f983ddacf9ea3fa53302a37a8b965c]
> Docker build fails due to PhantomJS dependency
> --
>
> Key: RANGER-2321
> URL: https://issues.apache.org/jira/browse/RANGER-2321
> Project: Ranger
> Issue Type: Bug
> Components: admin
>Affects Versions: 2.0.0
>Reporter: Csaba Koncz
>Assignee: Csaba Koncz
>Priority: Major
> Attachments:
> 0001-RANGER-2321-Docker-build-fails-due-to-PhantomJS-depe.patch
>
>
> Docker build fails in an early phase do to the PhantomJS dependency
> introduced in RANGER-2255. E.g. running
> {code:java}
> ./build_ranger_using_docker.sh mvn clean verify -am -pl security-admin{code}
> results in
> {code:java}
> [INFO] < org.apache.ranger:security-admin-web
> >
> [INFO] Building Security Admin Web Application 2.0.0-SNAPSHOT [7/7]
> [INFO] [ war
> ]-
> [INFO]
> [INFO] --- maven-clean-plugin:2.6.1:clean (default-clean) @
> security-admin-web ---
> [INFO]
> [INFO] --- maven-enforcer-plugin:1.4.1:enforce (enforce-maven-version) @
> security-admin-web ---
> [INFO]
> [INFO] --- maven-enforcer-plugin:1.4.1:enforce (enforce-versions) @
> security-admin-web ---
> [INFO]
> [INFO] --- maven-resources-plugin:2.7:copy-resources (copy-resources) @
> security-admin-web ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 2 resources
> [INFO]
> [INFO] --- maven-remote-resources-plugin:1.5:process
> (process-resource-bundles) @ security-admin-web ---
> [INFO]
> [INFO] --- maven-resources-plugin:2.7:resources (default-resources) @
> security-admin-web ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 22 resources
> [INFO] Copying 3 resources
> [INFO]
> [INFO] --- maven-antrun-plugin:1.7:run (default) @ security-admin-web ---
> [INFO] Executing tasks
> main:
> [INFO] Executed tasks
> [INFO]
> [INFO] --- frontend-maven-plugin:1.6:install-node-and-npm (install node and
> npm) @ security-admin-web ---
> [INFO] Installing node version v8.12.0
> [INFO] Unpacking
> /home/builder/.m2/repository/com/github/eirslett/node/8.12.0/node-8.12.0-linux-x64.tar.gz
> into /ranger/security-admin/target/node/tmp
> [INFO] Copying node binary from
> /ranger/security-admin/target/node/tmp/node-v8.12.0-linux-x64/bin/node to
> /ranger/security-admin/target/node/node
> [INFO] Installed node locally.
> [INFO] Installing npm version 6.4.1
> [INFO] Unpacking
> /home/builder/.m2/repository/com/github/eirslett/npm/6.4.1/npm-6.4.1.tar.gz
> into /ranger/security-admin/target/node/node_modules
> [INFO] Installed npm locally.
> [INFO]
> [INFO] --- frontend-maven-plugin:1.6:npm (npm install) @ security-admin-web
> ---
> [INFO] Running 'npm install' in /ranger/security-admin/target
> [INFO]
> [INFO] > phantomjs-prebuilt@2.1.16 install
> /ranger/security-admin/target/node_modules/karma-phantomjs-launcher/node_modules/phantomjs-prebuilt
> [INFO] > node install.js
> [INFO]
> [INFO] PhantomJS not found on PATH
> [INFO] Downloading
> https://github.com/Medium/phantomjs/releases/download/v2.1.1/phantomjs-2.1.1-linux-x86_64.tar.bz2
> [INFO] Saving to /tmp/phantomjs/phantomjs-2.1.1-linux-x86_64.tar.bz2
> [INFO] Receiving...
> [INFO]
> [INFO] Received 22866K total.
> [INFO] Extracting tar contents (via spawned process)
> [ERROR] Error extracting archive
> [ERROR] Phantom installation failed { Error: Command failed: tar jxf
> /tmp/phantomjs/phantomjs-2.1.1-linux-x86_64.tar.bz2
> [ERROR] tar (child): bzip2: Cannot exec: No such file or directory
> [ERROR] tar (child): Error is not recoverable: exiting now
> [ERROR] tar: Child returned status 2
> [ERROR] tar: Error is not recoverable: exiting now
> [ERROR]
> [ERROR] at ChildProcess.exithandler (child_process.js:276:12)
> [ERROR] at emitTwo (events.js:126:13)
> [ERROR] at ChildProcess.emit (events.js:214:7)
> [ERROR] at maybeClose (internal/child_process.js:915:16)
> [ERROR] at Socket.stream.socket.on (internal/child_process.js:336:11)
> [ERROR] at emitOne (events.js:116:13)
> [ERROR] at Socket.emit (events.js:211:7)
> [ERROR] at Pipe._handle.close [as _onclose] (net.js:561:12)
> [ERROR] killed: false,
> [ERROR] code: 2,
> [ERROR] signal: null,
> [ERROR] cmd: 'tar jxf /tmp/phantomjs/phantomjs-2.1.1-linux-x86_64.tar.bz2' }
> Error: Command failed: tar jxf
> /tmp/phantomjs/phantomjs-2.1.1-linux-x86_64.tar.bz2
> [ERROR] tar (child): bzip2: Cannot exec: No such file or directory
> [ERROR] tar (child): Error is not recoverable: exiting now
> [ERROR] tar: Child returned
[jira] [Resolved] (RANGER-2319) Remove deprecated phantomjs NPM package
[
https://issues.apache.org/jira/browse/RANGER-2319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zsombor Gegesy resolved RANGER-2319.
Resolution: Fixed
Fix Version/s: 2.0.0
Thanks for the patch, applied to
[master|https://github.com/apache/ranger/commit/a3394a19f98cea04dc2824fdaa4e3a3fdbd6beb3]
> Remove deprecated phantomjs NPM package
> ---
>
> Key: RANGER-2319
> URL: https://issues.apache.org/jira/browse/RANGER-2319
> Project: Ranger
> Issue Type: Wish
> Components: admin
>Affects Versions: 2.0.0
>Reporter: Csaba Koncz
>Assignee: Csaba Koncz
>Priority: Major
> Fix For: 2.0.0
>
>
> [Phantomjs|https://github.com/apache/ranger/blob/e1b0105eee67bb73c56b66b2dda1c3424555ab3e/security-admin/src/main/webapp/package.json#L15]
> NPM package is deprecated.
> {code:java}
> $ npm show phantomjs
> phantomjs@2.1.7 | Apache-2.0 | deps: 8 | versions: 81
> Headless WebKit with JS API
> https://github.com/Medium/phantomjs
> DEPRECATED ⚠️ - Package renamed to phantomjs-prebuilt. Please update
> 'phantomjs' package references to 'phantomjs-prebuilt'{code}
> Worse, karma-phantomjs-launcher brings in its version as phantomjs-prebuilt
> which results in Phantomjs binaries being downloaded twice.
> Build would speed up if only one Phantomjs version is downloaded.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (RANGER-2317) Enable compilation on JDK11
[ https://issues.apache.org/jira/browse/RANGER-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy updated RANGER-2317: --- Attachment: (was: RANGER-2317.patch) > Enable compilation on JDK11 > --- > > Key: RANGER-2317 > URL: https://issues.apache.org/jira/browse/RANGER-2317 > Project: Ranger > Issue Type: Improvement > Components: admin, plugins >Reporter: Zsombor Gegesy >Assignee: Zsombor Gegesy >Priority: Major > Fix For: master > > Attachments: RANGER-2317-2.patch > > > Currently, Ranger can be compiled only with JDK 8, however JDK 11 is the > current LTS release for Java, it is essential to support it. As a first step, > we need to ensure that Ranger can be compiled on JDK 11. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (RANGER-2317) Enable compilation on JDK11
[ https://issues.apache.org/jira/browse/RANGER-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy updated RANGER-2317: --- Attachment: RANGER-2317-2.patch > Enable compilation on JDK11 > --- > > Key: RANGER-2317 > URL: https://issues.apache.org/jira/browse/RANGER-2317 > Project: Ranger > Issue Type: Improvement > Components: admin, plugins >Reporter: Zsombor Gegesy >Assignee: Zsombor Gegesy >Priority: Major > Fix For: master > > Attachments: RANGER-2317-2.patch > > > Currently, Ranger can be compiled only with JDK 8, however JDK 11 is the > current LTS release for Java, it is essential to support it. As a first step, > we need to ensure that Ranger can be compiled on JDK 11. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (RANGER-2255) Add JavaScript unit tests
[ https://issues.apache.org/jira/browse/RANGER-2255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy resolved RANGER-2255. Resolution: Fixed Commited to [master|https://github.com/apache/ranger/commit/e1b0105eee67bb73c56b66b2dda1c3424555ab3e], thanks for your contribution [~Koncz] ! > Add JavaScript unit tests > - > > Key: RANGER-2255 > URL: https://issues.apache.org/jira/browse/RANGER-2255 > Project: Ranger > Issue Type: Wish > Components: admin >Affects Versions: 0.7.0, 2.0.0, 1.2.1 >Reporter: Csaba Koncz >Assignee: Csaba Koncz >Priority: Minor > Fix For: 2.0.0 > > > It would be nice if the admin-ui project would have JavaScript unit tests. > As with RANGER-2220 JavaScript minification was introduced, that can lead to > new type of loading errors that were not seen before. > It would be nice if there was an automatic check that validates the minified > output. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (RANGER-2318) Incorrect git url on the homepage
[ https://issues.apache.org/jira/browse/RANGER-2318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16734101#comment-16734101 ] Zsombor Gegesy commented on RANGER-2318: Commited to [master|https://github.com/apache/ranger/commit/ead451a3383f33630f59c1996c478ddb6f6fb39f] > Incorrect git url on the homepage > - > > Key: RANGER-2318 > URL: https://issues.apache.org/jira/browse/RANGER-2318 > Project: Ranger > Issue Type: Bug > Components: documentation >Reporter: Zsombor Gegesy >Assignee: Zsombor Gegesy >Priority: Minor > Labels: homepage > Fix For: master > > Attachments: RANGER-2318.patch > > > On http://ranger.apache.org/ the link for the git repository is pointing to > https://git.apache.org/ranger.git/ instead of gitbox and github. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (RANGER-2318) Incorrect git url on the homepage
[ https://issues.apache.org/jira/browse/RANGER-2318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy updated RANGER-2318: --- Attachment: RANGER-2318.patch > Incorrect git url on the homepage > - > > Key: RANGER-2318 > URL: https://issues.apache.org/jira/browse/RANGER-2318 > Project: Ranger > Issue Type: Bug > Components: documentation >Reporter: Zsombor Gegesy >Assignee: Zsombor Gegesy >Priority: Minor > Labels: homepage > Attachments: RANGER-2318.patch > > > On http://ranger.apache.org/ the link for the git repository is pointing to > https://git.apache.org/ranger.git/ instead of gitbox and github. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (RANGER-2318) Incorrect git url on the homepage
Zsombor Gegesy created RANGER-2318: -- Summary: Incorrect git url on the homepage Key: RANGER-2318 URL: https://issues.apache.org/jira/browse/RANGER-2318 Project: Ranger Issue Type: Bug Components: documentation Reporter: Zsombor Gegesy Assignee: Zsombor Gegesy On http://ranger.apache.org/ the link for the git repository is pointing to https://git.apache.org/ranger.git/ instead of gitbox and github. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (RANGER-2317) Enable compilation on JDK11
[ https://issues.apache.org/jira/browse/RANGER-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy updated RANGER-2317: --- Attachment: RANGER-2317.patch > Enable compilation on JDK11 > --- > > Key: RANGER-2317 > URL: https://issues.apache.org/jira/browse/RANGER-2317 > Project: Ranger > Issue Type: Improvement > Components: admin, plugins >Reporter: Zsombor Gegesy >Assignee: Zsombor Gegesy >Priority: Major > Fix For: master > > Attachments: RANGER-2317.patch > > > Currently, Ranger can be compiled only with JDK 8, however JDK 11 is the > current LTS release for Java, it is essential to support it. As a first step, > we need to ensure that Ranger can be compiled on JDK 11. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (RANGER-2317) Enable compilation on JDK11
Zsombor Gegesy created RANGER-2317: -- Summary: Enable compilation on JDK11 Key: RANGER-2317 URL: https://issues.apache.org/jira/browse/RANGER-2317 Project: Ranger Issue Type: Improvement Components: admin, plugins Reporter: Zsombor Gegesy Assignee: Zsombor Gegesy Fix For: master Currently, Ranger can be compiled only with JDK 8, however JDK 11 is the current LTS release for Java, it is essential to support it. As a first step, we need to ensure that Ranger can be compiled on JDK 11. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (RANGER-2307) Native code can segfault or return misleading error messages
[ https://issues.apache.org/jira/browse/RANGER-2307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy updated RANGER-2307: --- Attachment: RANGER-2307-native-fixes.patch > Native code can segfault or return misleading error messages > > > Key: RANGER-2307 > URL: https://issues.apache.org/jira/browse/RANGER-2307 > Project: Ranger > Issue Type: Bug > Components: usersync >Affects Versions: 1.2.0 >Reporter: Zsombor Gegesy >Assignee: Zsombor Gegesy >Priority: Major > Labels: native, pam, unix > Attachments: RANGER-2307-native-fixes.patch > > > Currently credValidator and pamCredValidator don't handle well configuration > problems - when the user doesn't have permission to read /etc/shadow or > access pam, or when the shadow file is not filled properly. This could cause > 'core dumps', and hard to fix deployment issues -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (RANGER-2307) Native code can segfault or return misleading error messages
Zsombor Gegesy created RANGER-2307: -- Summary: Native code can segfault or return misleading error messages Key: RANGER-2307 URL: https://issues.apache.org/jira/browse/RANGER-2307 Project: Ranger Issue Type: Bug Components: usersync Affects Versions: 1.2.0 Reporter: Zsombor Gegesy Assignee: Zsombor Gegesy Currently credValidator and pamCredValidator don't handle well configuration problems - when the user doesn't have permission to read /etc/shadow or access pam, or when the shadow file is not filled properly. This could cause 'core dumps', and hard to fix deployment issues -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (RANGER-2144) Refactor DAO usage
[ https://issues.apache.org/jira/browse/RANGER-2144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy updated RANGER-2144: --- Attachment: RANGER-2144-3.patch > Refactor DAO usage > -- > > Key: RANGER-2144 > URL: https://issues.apache.org/jira/browse/RANGER-2144 > Project: Ranger > Issue Type: Improvement > Components: admin >Affects Versions: 1.0.0 >Reporter: Zsombor Gegesy >Assignee: Zsombor Gegesy >Priority: Major > Labels: code-cleanup > Attachments: RANGER-2144-3.patch > > > Currently, RangerDaoManagerBase is used to construct new DAO instances, > instead of relying on Spring to provide one for it. This would reduce the > code to write and run, and make it less interdependent, and simplifies the > tests, as less code would be needed to mock. > As RangerDaoManagerBase is used everywhere, and to avoid having huge > patches, it would be better do it in smaller steps. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (RANGER-2144) Refactor DAO usage
[ https://issues.apache.org/jira/browse/RANGER-2144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy updated RANGER-2144: --- Attachment: (was: RANGER-2144.patch) > Refactor DAO usage > -- > > Key: RANGER-2144 > URL: https://issues.apache.org/jira/browse/RANGER-2144 > Project: Ranger > Issue Type: Improvement > Components: admin >Affects Versions: 1.0.0 >Reporter: Zsombor Gegesy >Assignee: Zsombor Gegesy >Priority: Major > Labels: code-cleanup > Attachments: RANGER-2144-3.patch > > > Currently, RangerDaoManagerBase is used to construct new DAO instances, > instead of relying on Spring to provide one for it. This would reduce the > code to write and run, and make it less interdependent, and simplifies the > tests, as less code would be needed to mock. > As RangerDaoManagerBase is used everywhere, and to avoid having huge > patches, it would be better do it in smaller steps. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (RANGER-1951) build problems with the saveVersion.py script
[ https://issues.apache.org/jira/browse/RANGER-1951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16559651#comment-16559651 ] Zsombor Gegesy commented on RANGER-1951: Patch merged to [master|https://github.com/apache/ranger/commit/4308c8aecbd7c537469475e6f456c0ab043ea931] > build problems with the saveVersion.py script > - > > Key: RANGER-1951 > URL: https://issues.apache.org/jira/browse/RANGER-1951 > Project: Ranger > Issue Type: Bug > Components: build-infra >Affects Versions: 0.7.1 >Reporter: Zsombor Gegesy >Assignee: Zsombor Gegesy >Priority: Major > Fix For: 2.0.0 > > Attachments: RANGER-1951-1.patch, RANGER-1951-2.patch > > > Currently the saveVersion.py has the following problems: > * it doesn't work with python3 due to 'inconsistent whitespace usage' and > because in python3 the byte array is different from a string > * The checksum is generated from all the java source files from > ranger-util/target, which contains at most one java file - a previously > generated ranger-util/target/gen/org/apache/ranger/common/package-info.java > * -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (RANGER-1951) build problems with the saveVersion.py script
[ https://issues.apache.org/jira/browse/RANGER-1951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy resolved RANGER-1951. Resolution: Fixed > build problems with the saveVersion.py script > - > > Key: RANGER-1951 > URL: https://issues.apache.org/jira/browse/RANGER-1951 > Project: Ranger > Issue Type: Bug > Components: build-infra >Affects Versions: 0.7.1 >Reporter: Zsombor Gegesy >Assignee: Zsombor Gegesy >Priority: Major > Fix For: 2.0.0 > > Attachments: RANGER-1951-1.patch, RANGER-1951-2.patch > > > Currently the saveVersion.py has the following problems: > * it doesn't work with python3 due to 'inconsistent whitespace usage' and > because in python3 the byte array is different from a string > * The checksum is generated from all the java source files from > ranger-util/target, which contains at most one java file - a previously > generated ranger-util/target/gen/org/apache/ranger/common/package-info.java > * -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (RANGER-1951) build problems with the saveVersion.py script
[ https://issues.apache.org/jira/browse/RANGER-1951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16534167#comment-16534167 ] Zsombor Gegesy commented on RANGER-1951: New patch added! > build problems with the saveVersion.py script > - > > Key: RANGER-1951 > URL: https://issues.apache.org/jira/browse/RANGER-1951 > Project: Ranger > Issue Type: Bug > Components: build-infra >Affects Versions: 0.7.1 >Reporter: Zsombor Gegesy >Assignee: Zsombor Gegesy >Priority: Major > Fix For: 2.0.0 > > Attachments: RANGER-1951-1.patch, RANGER-1951-2.patch > > > Currently the saveVersion.py has the following problems: > * it doesn't work with python3 due to 'inconsistent whitespace usage' and > because in python3 the byte array is different from a string > * The checksum is generated from all the java source files from > ranger-util/target, which contains at most one java file - a previously > generated ranger-util/target/gen/org/apache/ranger/common/package-info.java > * -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (RANGER-1951) build problems with the saveVersion.py script
[ https://issues.apache.org/jira/browse/RANGER-1951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy updated RANGER-1951: --- Attachment: RANGER-1951-2.patch > build problems with the saveVersion.py script > - > > Key: RANGER-1951 > URL: https://issues.apache.org/jira/browse/RANGER-1951 > Project: Ranger > Issue Type: Bug > Components: build-infra >Affects Versions: 0.7.1 >Reporter: Zsombor Gegesy >Assignee: Zsombor Gegesy >Priority: Major > Fix For: 2.0.0 > > Attachments: RANGER-1951-1.patch, RANGER-1951-2.patch > > > Currently the saveVersion.py has the following problems: > * it doesn't work with python3 due to 'inconsistent whitespace usage' and > because in python3 the byte array is different from a string > * The checksum is generated from all the java source files from > ranger-util/target, which contains at most one java file - a previously > generated ranger-util/target/gen/org/apache/ranger/common/package-info.java > * -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (RANGER-2144) Refactor DAO usage
[ https://issues.apache.org/jira/browse/RANGER-2144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy updated RANGER-2144: --- Attachment: RANGER-2144.patch > Refactor DAO usage > -- > > Key: RANGER-2144 > URL: https://issues.apache.org/jira/browse/RANGER-2144 > Project: Ranger > Issue Type: Improvement > Components: admin >Affects Versions: 1.0.0 >Reporter: Zsombor Gegesy >Assignee: Zsombor Gegesy >Priority: Major > Labels: code-cleanup > Attachments: RANGER-2144.patch > > > Currently, RangerDaoManagerBase is used to construct new DAO instances, > instead of relying on Spring to provide one for it. This would reduce the > code to write and run, and make it less interdependent, and simplifies the > tests, as less code would be needed to mock. > As RangerDaoManagerBase is used everywhere, and to avoid having huge > patches, it would be better do it in smaller steps. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (RANGER-2144) Refactor DAO usage
Zsombor Gegesy created RANGER-2144: -- Summary: Refactor DAO usage Key: RANGER-2144 URL: https://issues.apache.org/jira/browse/RANGER-2144 Project: Ranger Issue Type: Improvement Components: admin Affects Versions: 1.0.0 Reporter: Zsombor Gegesy Assignee: Zsombor Gegesy Currently, RangerDaoManagerBase is used to construct new DAO instances, instead of relying on Spring to provide one for it. This would reduce the code to write and run, and make it less interdependent, and simplifies the tests, as less code would be needed to mock. As RangerDaoManagerBase is used everywhere, and to avoid having huge patches, it would be better do it in smaller steps. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (RANGER-2135) BaseClient forces Hadoop login
[ https://issues.apache.org/jira/browse/RANGER-2135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16515200#comment-16515200 ] Zsombor Gegesy commented on RANGER-2135: Implementing a BaseClient subclass is not required for having a service plugin, it's just a convention, which currently all the connector implementation follows. If you don't need kerberos for accessing your service, then you can safely create your own CephClient, which doesn't extends BaseClient. Maybe moving the current login code into a 'BaseHadoopClient' child class from BaseClient, and changing the parent class in every connector's Client class would be a good idea. What do you think? Do you want to contribute a patch for it? > BaseClient forces Hadoop login > -- > > Key: RANGER-2135 > URL: https://issues.apache.org/jira/browse/RANGER-2135 > Project: Ranger > Issue Type: Bug > Components: plugins >Affects Versions: 1.0.0 >Reporter: Bolke de Bruin >Priority: Major > > BaseClient does a login on instantiation that is bound to Hadoop. This > requires service plugins to require a username/password, which is > undocumented. It also limits the functionality to the Hadoop ecosystem. > Suggestion: > * Provide a default constructor > * Make init() protected > * Make serviceName protected > * Make defaultConfigFile protected > Note: I encountered this when writing a S3/Ceph plugin -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (RANGER-2107) Use Spring to inject DAOs
[ https://issues.apache.org/jira/browse/RANGER-2107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy updated RANGER-2107: --- Attachment: RANGER-2107-2.patch > Use Spring to inject DAOs > - > > Key: RANGER-2107 > URL: https://issues.apache.org/jira/browse/RANGER-2107 > Project: Ranger > Issue Type: Bug > Components: admin >Affects Versions: 1.0.0 >Reporter: Zsombor Gegesy >Assignee: Zsombor Gegesy >Priority: Major > Labels: code-cleanup, codehealth > Fix For: 1.1.0 > > Attachments: RANGER-2107-2.patch > > > Currently, instead of relying on Spring to inject the DAOs internally, Ranger > use a RangerDaoManager to create and acquire objects, which lead to a lot of > unnecessary generic code which complicates the code. > Instead of this, all the 'DAO' needs a simple '@Service' annotation, and > RangerBaseModelService.entityDao and AbstractBaseResourceService.entityDao > can be marked as @Autowired - and Spring will do her job. (Spring before <4.0 > were unable to autowire fields based on the generic parameters). > Later all the RangerDaoManagerBase method could be removed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (RANGER-2107) Use Spring to inject DAOs
[ https://issues.apache.org/jira/browse/RANGER-2107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy updated RANGER-2107: --- Attachment: (was: RANGER-2107.patch) > Use Spring to inject DAOs > - > > Key: RANGER-2107 > URL: https://issues.apache.org/jira/browse/RANGER-2107 > Project: Ranger > Issue Type: Bug > Components: admin >Affects Versions: 1.0.0 >Reporter: Zsombor Gegesy >Assignee: Zsombor Gegesy >Priority: Major > Labels: code-cleanup, codehealth > Fix For: 1.1.0 > > Attachments: RANGER-2107-2.patch > > > Currently, instead of relying on Spring to inject the DAOs internally, Ranger > use a RangerDaoManager to create and acquire objects, which lead to a lot of > unnecessary generic code which complicates the code. > Instead of this, all the 'DAO' needs a simple '@Service' annotation, and > RangerBaseModelService.entityDao and AbstractBaseResourceService.entityDao > can be marked as @Autowired - and Spring will do her job. (Spring before <4.0 > were unable to autowire fields based on the generic parameters). > Later all the RangerDaoManagerBase method could be removed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (RANGER-2107) Use Spring to inject DAOs
[ https://issues.apache.org/jira/browse/RANGER-2107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy updated RANGER-2107: --- Attachment: RANGER-2107.patch > Use Spring to inject DAOs > - > > Key: RANGER-2107 > URL: https://issues.apache.org/jira/browse/RANGER-2107 > Project: Ranger > Issue Type: Bug > Components: admin >Affects Versions: 1.0.0 >Reporter: Zsombor Gegesy >Assignee: Zsombor Gegesy >Priority: Major > Labels: code-cleanup, codehealth > Fix For: 1.1.0 > > Attachments: RANGER-2107.patch > > > Currently, instead of relying on Spring to inject the DAOs internally, Ranger > use a RangerDaoManager to create and acquire objects, which lead to a lot of > unnecessary generic code which complicates the code. > Instead of this, all the 'DAO' needs a simple '@Service' annotation, and > RangerBaseModelService.entityDao and AbstractBaseResourceService.entityDao > can be marked as @Autowired - and Spring will do her job. (Spring before <4.0 > were unable to autowire fields based on the generic parameters). > Later all the RangerDaoManagerBase method could be removed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (RANGER-2107) Use Spring to inject DAOs
Zsombor Gegesy created RANGER-2107: -- Summary: Use Spring to inject DAOs Key: RANGER-2107 URL: https://issues.apache.org/jira/browse/RANGER-2107 Project: Ranger Issue Type: Bug Components: admin Affects Versions: 1.0.0 Reporter: Zsombor Gegesy Assignee: Zsombor Gegesy Fix For: 1.1.0 Currently, instead of relying on Spring to inject the DAOs internally, Ranger use a RangerDaoManager to create and acquire objects, which lead to a lot of unnecessary generic code which complicates the code. Instead of this, all the 'DAO' needs a simple '@Service' annotation, and RangerBaseModelService.entityDao and AbstractBaseResourceService.entityDao can be marked as @Autowired - and Spring will do her job. (Spring before <4.0 were unable to autowire fields based on the generic parameters). Later all the RangerDaoManagerBase method could be removed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (RANGER-2096) Remove dead code from AbstractBaseResourceService and RangerBizUtil
[ https://issues.apache.org/jira/browse/RANGER-2096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy resolved RANGER-2096. Resolution: Fixed Commit pushed to [master|https://github.com/apache/ranger/commit/5ab18c4ddd5bda99a7f1722728bed41b84de788c] > Remove dead code from AbstractBaseResourceService and RangerBizUtil > --- > > Key: RANGER-2096 > URL: https://issues.apache.org/jira/browse/RANGER-2096 > Project: Ranger > Issue Type: Bug > Components: admin >Affects Versions: 1.0.0 >Reporter: Zsombor Gegesy >Assignee: Zsombor Gegesy >Priority: Major > Labels: code-cleanup > Fix For: 1.1.0 > > Attachments: RANGER-2096-2.patch > > > There is unnecessary dead code in AbstractBaseResourceService.java, which > stores the child services in a service map, which is only called from > RangerBizUtil.getVObject/getMObject methods, which are only called from test > method. > This can be removed safely. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (RANGER-2096) Remove dead code from AbstractBaseResourceService and RangerBizUtil
[ https://issues.apache.org/jira/browse/RANGER-2096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy updated RANGER-2096: --- Attachment: RANGER-2096-2.patch > Remove dead code from AbstractBaseResourceService and RangerBizUtil > --- > > Key: RANGER-2096 > URL: https://issues.apache.org/jira/browse/RANGER-2096 > Project: Ranger > Issue Type: Bug > Components: admin >Affects Versions: 1.0.0 >Reporter: Zsombor Gegesy >Assignee: Zsombor Gegesy >Priority: Major > Labels: code-cleanup > Fix For: 1.1.0 > > Attachments: RANGER-2096-2.patch > > > There is unnecessary dead code in AbstractBaseResourceService.java, which > stores the child services in a service map, which is only called from > RangerBizUtil.getVObject/getMObject methods, which are only called from test > method. > This can be removed safely. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (RANGER-2096) Remove dead code from AbstractBaseResourceService and RangerBizUtil
[ https://issues.apache.org/jira/browse/RANGER-2096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy updated RANGER-2096: --- Attachment: RANGER-2096.patch > Remove dead code from AbstractBaseResourceService and RangerBizUtil > --- > > Key: RANGER-2096 > URL: https://issues.apache.org/jira/browse/RANGER-2096 > Project: Ranger > Issue Type: Bug > Components: admin >Affects Versions: 1.0.0 >Reporter: Zsombor Gegesy >Assignee: Zsombor Gegesy >Priority: Major > Labels: code-cleanup > Fix For: 1.1.0 > > Attachments: RANGER-2096.patch > > > There is unnecessary dead code in AbstractBaseResourceService.java, which > stores the child services in a service map, which is only called from > RangerBizUtil.getVObject/getMObject methods, which are only called from test > method. > This can be removed safely. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (RANGER-2096) Remove dead code from AbstractBaseResourceService and RangerBizUtil
Zsombor Gegesy created RANGER-2096: -- Summary: Remove dead code from AbstractBaseResourceService and RangerBizUtil Key: RANGER-2096 URL: https://issues.apache.org/jira/browse/RANGER-2096 Project: Ranger Issue Type: Bug Components: admin Affects Versions: 1.0.0 Reporter: Zsombor Gegesy Assignee: Zsombor Gegesy Fix For: 1.1.0 There is unnecessary dead code in AbstractBaseResourceService.java, which stores the child services in a service map, which is only called from RangerBizUtil.getVObject/getMObject methods, which are only called from test method. This can be removed safely. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (RANGER-2077) Service deletion could fail on Oracle due to 'ORA-01000: maximum open cursors exceeded'
Zsombor Gegesy created RANGER-2077:
--
Summary: Service deletion could fail on Oracle due to 'ORA-01000:
maximum open cursors exceeded'
Key: RANGER-2077
URL: https://issues.apache.org/jira/browse/RANGER-2077
Project: Ranger
Issue Type: Bug
Components: admin, Ranger
Affects Versions: 0.7.1, 1.0.0
Reporter: Zsombor Gegesy
Deleting services seems to use a lot of cursors, which could result in
exceptions like this:
{code}
[http-bio-6080-exec-11] ERROR org.apache.ranger.rest.ServiceREST
(ServiceREST.java:771) - deleteService(22) failed
javax.persistence.PersistenceException: Exception [EclipseLink-4002] (Eclipse
Persistence Services - 2.5.2.v20140319-9ad6abd):
org.eclipse.persistence.exceptions.DatabaseException
Internal Exception: java.sql.SQLException: ORA-00604: error occurred at
recursive SQL level 1
ORA-01000: maximum open cursors exceeded
ORA-00604: error occurred at recursive SQL level 1
ORA-01000: maximum open cursors exceeded
Error Code: 604
Call: delete from x_policy_item_group_perm where policy_item_id=99
Query: DataModifyQuery(sql="delete from x_policy_item_group_perm where
policy_item_id=99")
at
org.eclipse.persistence.internal.jpa.QueryImpl.executeUpdate(QueryImpl.java:308)
at
org.apache.ranger.common.db.BaseDao.deletePolicyIDReference(BaseDao.java:261)
at
org.apache.ranger.biz.ServiceDBStore.deleteExistingPolicyItemsNative(ServiceDBStore.java:3337)
at
org.apache.ranger.biz.ServiceDBStore.deletePolicy(ServiceDBStore.java:2022)
at
org.apache.ranger.biz.ServiceDBStore.deleteService(ServiceDBStore.java:1676)
at
org.apache.ranger.rest.ServiceREST.deleteService(ServiceREST.java:767)
at
org.apache.ranger.rest.ServiceREST$$FastClassBySpringCGLIB$$92dab672.invoke()
at
org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:204)
at
org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:701)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at
org.springframework.security.access.intercept.aopalliance.MethodSecurityInterceptor.invoke(MethodSecurityInterceptor.java:64)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at
org.springframework.transaction.interceptor.TransactionInterceptor$1.proceedWithInvocation(TransactionInterceptor.java:96)
at
org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:260)
at
org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:94)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at
org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:633)
at
org.apache.ranger.rest.ServiceREST$$EnhancerBySpringCGLIB$$8fa8bfff.deleteService()
at
org.apache.ranger.rest.PublicAPIsv2.deleteServiceByName(PublicAPIsv2.java:276)
at
org.apache.ranger.rest.PublicAPIsv2$$FastClassBySpringCGLIB$$b2e69455.invoke()
at
org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:204)
{code}
Or
{code}
WARN com.mchange.v2.c3p0.impl.NewPooledConnection
(NewPooledConnection.java:486) - [c3p0] A PooledConnection that has already
signalled a Connection error is still in use!
2018-04-22 05:38:13,592 [http-bio-6080-exec-18] WARN
com.mchange.v2.c3p0.impl.NewPooledConnection (NewPooledConnection.java:487) -
[c3p0] Another error has occurred [ java.sql.SQLException: ORA-01000: maximum
open cursors exceeded
] which will not be reported to listeners!
java.sql.SQLException: ORA-01000: maximum open cursors exceeded
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:450)
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:399)
at oracle.jdbc.driver.T4C8Oall.processError(T4C8Oall.java:1059)
at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:522)
at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:257)
at oracle.jdbc.driver.T4C8Oall.doOALL(T4C8Oall.java:587)
at
oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:225)
at
oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:53)
at
oracle.jdbc.driver.T4CPreparedStatement.executeForDescribe(T4CPreparedStatement.java:774)
at
oracle.jdbc.driver.OracleStatement.executeMaybeDescribe(OracleStatement.java:925)
at
oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:)
at
[jira] [Commented] (RANGER-1951) build problems with the saveVersion.py script
[ https://issues.apache.org/jira/browse/RANGER-1951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415128#comment-16415128 ] Zsombor Gegesy commented on RANGER-1951: Patch merged to master: https://github.com/apache/ranger/commit/b2295a5e2e8b4848c60e6ed9929147748f5d44cb > build problems with the saveVersion.py script > - > > Key: RANGER-1951 > URL: https://issues.apache.org/jira/browse/RANGER-1951 > Project: Ranger > Issue Type: Bug > Components: build-infra >Affects Versions: 0.7.1 >Reporter: Zsombor Gegesy >Assignee: Zsombor Gegesy >Priority: Major > Fix For: 1.1.0 > > Attachments: RANGER-1951-1.patch > > > Currently the saveVersion.py has the following problems: > * it doesn't work with python3 due to 'inconsistent whitespace usage' and > because in python3 the byte array is different from a string > * The checksum is generated from all the java source files from > ranger-util/target, which contains at most one java file - a previously > generated ranger-util/target/gen/org/apache/ranger/common/package-info.java > * -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (RANGER-2016) Fix null passed in as a HttpServletRequest - into the deletePoliciesProvidedInServiceMap method.
[ https://issues.apache.org/jira/browse/RANGER-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16413608#comment-16413608 ] Zsombor Gegesy commented on RANGER-2016: Commit merged to master: https://github.com/apache/ranger/commit/ab0b91fd666feb034a7a3c06d419d915f8c6721d > Fix null passed in as a HttpServletRequest - into the > deletePoliciesProvidedInServiceMap method. > > > Key: RANGER-2016 > URL: https://issues.apache.org/jira/browse/RANGER-2016 > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: Velmurugan Periasamy >Assignee: Zsombor Gegesy >Priority: Major > Fix For: 1.1.0 > > Attachments: RANGER-2016.patch > > > Refer https://issues.apache.org/jira/browse/RANGER-1991 for details. > This issue is to get [~zsombor]'s fix into master and 1.1.0 release. CC > [~pradeepagrawal8184] > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (RANGER-2035) Errors accessing servicedefs with empty implClass with Oracle backend
[ https://issues.apache.org/jira/browse/RANGER-2035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy updated RANGER-2035: --- Attachment: RANGER-2035-0.7-fix-the-null-implClass-h.patch > Errors accessing servicedefs with empty implClass with Oracle backend > - > > Key: RANGER-2035 > URL: https://issues.apache.org/jira/browse/RANGER-2035 > Project: Ranger > Issue Type: Bug > Components: admin >Affects Versions: 1.0.0, 0.7.1 > Environment: Oracle DB >Reporter: Zsombor Gegesy >Assignee: Zsombor Gegesy >Priority: Major > Labels: admin, oracle > Fix For: 0.7.2, 1.1.0, 1.0.1 > > Attachments: > 0001-RANGER-2035-fix-handling-of-null-implClass-in-servic.patch, > RANGER-2035-0.7-fix-the-null-implClass-h.patch > > > Oracle treats empty strings and nulls as equals - if an empty string is > inserted, later, it returns as NULL. > This cause problems when a service def is created, with implementation > classname specified as a zero length string. However, when later it is > retrieved or updated or delete, Ranger throws various exceptions. In 1.0.0 a > couple of exceptions are fixed, because of RANGER-1377, however in 0.7, there > is more NPE. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (RANGER-1951) build problems with the saveVersion.py script
[ https://issues.apache.org/jira/browse/RANGER-1951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16411155#comment-16411155 ] Zsombor Gegesy commented on RANGER-1951: Can someone have a look? > build problems with the saveVersion.py script > - > > Key: RANGER-1951 > URL: https://issues.apache.org/jira/browse/RANGER-1951 > Project: Ranger > Issue Type: Bug > Components: build-infra >Affects Versions: 0.7.1 >Reporter: Zsombor Gegesy >Assignee: Zsombor Gegesy >Priority: Major > Fix For: 1.1.0 > > Attachments: RANGER-1951-1.patch > > > Currently the saveVersion.py has the following problems: > * it doesn't work with python3 due to 'inconsistent whitespace usage' and > because in python3 the byte array is different from a string > * The checksum is generated from all the java source files from > ranger-util/target, which contains at most one java file - a previously > generated ranger-util/target/gen/org/apache/ranger/common/package-info.java > * -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (RANGER-1994) Tomcat Security Vulnerability Alert. The version of the tomcat for ranger should upgrade to 7.0.85.
[ https://issues.apache.org/jira/browse/RANGER-1994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy resolved RANGER-1994. Resolution: Fixed > Tomcat Security Vulnerability Alert. The version of the tomcat for ranger > should upgrade to 7.0.85. > --- > > Key: RANGER-1994 > URL: https://issues.apache.org/jira/browse/RANGER-1994 > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: Qiang Zhang >Assignee: Qiang Zhang >Priority: Major > Labels: patch > Fix For: 1.1.0 > > Attachments: > 0001-RANGER-1994-Tomcat-Security-Vulnerability-Alert.-The.patch > > > [SECURITY] CVE-2018-1305 Security constraint annotations applied too late > CVE-2018-1305 Security constraint annotations applied too late > Severity: High > Versions Affected: Apache Tomcat 9.0.0.M1 to 9.0.4 Apache Tomcat 8.5.0 to > 8.5.27 Apache Tomcat 8.0.0.RC1 to 8.0.49 Apache Tomcat 7.0.0 to 7.0.84 > Description: Security constraints defined by annotations of Servlets were > only applied once a Servlet had been loaded. Because security constraints > defined in this way apply to the URL pattern and any URLs below that point, > it was possible - depending on the order Servlets were loaded - for some > security constraints not to be applied. This could have exposed resources to > users who were not authorised to access them. > Mitigation: Users of the affected versions should apply one of the following > mitigations. Upgrade to: - Apache Tomcat 9.0.5 or later - Apache Tomcat > 8.5.28 or later - Apache Tomcat 8.0.50 or later - Apache Tomcat 7.0.85 or > later > References:https://lists.apache.org/thread.html/d3354bb0a4eda4acc0a66f3eb24a213fdb75d12c7d16060b23e65781@%3Cannounce.tomcat.apache.org%3E -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (RANGER-1994) Tomcat Security Vulnerability Alert. The version of the tomcat for ranger should upgrade to 7.0.85.
[ https://issues.apache.org/jira/browse/RANGER-1994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16411103#comment-16411103 ] Zsombor Gegesy commented on RANGER-1994: Commit merged for master: https://github.com/apache/ranger/commit/44e4269b194a2714e8f01802e1c7d6a6c9d0ae0e Thanks > Tomcat Security Vulnerability Alert. The version of the tomcat for ranger > should upgrade to 7.0.85. > --- > > Key: RANGER-1994 > URL: https://issues.apache.org/jira/browse/RANGER-1994 > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: Qiang Zhang >Assignee: Qiang Zhang >Priority: Major > Labels: patch > Fix For: 1.1.0 > > Attachments: > 0001-RANGER-1994-Tomcat-Security-Vulnerability-Alert.-The.patch > > > [SECURITY] CVE-2018-1305 Security constraint annotations applied too late > CVE-2018-1305 Security constraint annotations applied too late > Severity: High > Versions Affected: Apache Tomcat 9.0.0.M1 to 9.0.4 Apache Tomcat 8.5.0 to > 8.5.27 Apache Tomcat 8.0.0.RC1 to 8.0.49 Apache Tomcat 7.0.0 to 7.0.84 > Description: Security constraints defined by annotations of Servlets were > only applied once a Servlet had been loaded. Because security constraints > defined in this way apply to the URL pattern and any URLs below that point, > it was possible - depending on the order Servlets were loaded - for some > security constraints not to be applied. This could have exposed resources to > users who were not authorised to access them. > Mitigation: Users of the affected versions should apply one of the following > mitigations. Upgrade to: - Apache Tomcat 9.0.5 or later - Apache Tomcat > 8.5.28 or later - Apache Tomcat 8.0.50 or later - Apache Tomcat 7.0.85 or > later > References:https://lists.apache.org/thread.html/d3354bb0a4eda4acc0a66f3eb24a213fdb75d12c7d16060b23e65781@%3Cannounce.tomcat.apache.org%3E -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (RANGER-1994) Tomcat Security Vulnerability Alert. The version of the tomcat for ranger should upgrade to 7.0.85.
[ https://issues.apache.org/jira/browse/RANGER-1994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy updated RANGER-1994: --- Fix Version/s: 1.1.0 > Tomcat Security Vulnerability Alert. The version of the tomcat for ranger > should upgrade to 7.0.85. > --- > > Key: RANGER-1994 > URL: https://issues.apache.org/jira/browse/RANGER-1994 > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: Qiang Zhang >Assignee: Qiang Zhang >Priority: Major > Labels: patch > Fix For: 1.1.0 > > Attachments: > 0001-RANGER-1994-Tomcat-Security-Vulnerability-Alert.-The.patch > > > [SECURITY] CVE-2018-1305 Security constraint annotations applied too late > CVE-2018-1305 Security constraint annotations applied too late > Severity: High > Versions Affected: Apache Tomcat 9.0.0.M1 to 9.0.4 Apache Tomcat 8.5.0 to > 8.5.27 Apache Tomcat 8.0.0.RC1 to 8.0.49 Apache Tomcat 7.0.0 to 7.0.84 > Description: Security constraints defined by annotations of Servlets were > only applied once a Servlet had been loaded. Because security constraints > defined in this way apply to the URL pattern and any URLs below that point, > it was possible - depending on the order Servlets were loaded - for some > security constraints not to be applied. This could have exposed resources to > users who were not authorised to access them. > Mitigation: Users of the affected versions should apply one of the following > mitigations. Upgrade to: - Apache Tomcat 9.0.5 or later - Apache Tomcat > 8.5.28 or later - Apache Tomcat 8.0.50 or later - Apache Tomcat 7.0.85 or > later > References:https://lists.apache.org/thread.html/d3354bb0a4eda4acc0a66f3eb24a213fdb75d12c7d16060b23e65781@%3Cannounce.tomcat.apache.org%3E -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (RANGER-2035) Errors accessing servicedefs with empty implClass with Oracle backend
[ https://issues.apache.org/jira/browse/RANGER-2035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy updated RANGER-2035: --- Attachment: 0001-RANGER-2035-fix-handling-of-null-implClass-in-servic.patch > Errors accessing servicedefs with empty implClass with Oracle backend > - > > Key: RANGER-2035 > URL: https://issues.apache.org/jira/browse/RANGER-2035 > Project: Ranger > Issue Type: Bug > Components: admin >Affects Versions: 1.0.0, 0.7.1 > Environment: Oracle DB >Reporter: Zsombor Gegesy >Assignee: Zsombor Gegesy >Priority: Major > Labels: admin, oracle > Fix For: 0.7.2, 1.1.0, 1.0.1 > > Attachments: > 0001-RANGER-2035-fix-handling-of-null-implClass-in-servic.patch > > > Oracle treats empty strings and nulls as equals - if an empty string is > inserted, later, it returns as NULL. > This cause problems when a service def is created, with implementation > classname specified as a zero length string. However, when later it is > retrieved or updated or delete, Ranger throws various exceptions. In 1.0.0 a > couple of exceptions are fixed, because of RANGER-1377, however in 0.7, there > is more NPE. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (RANGER-2035) Errors accessing servicedefs with empty implClass with Oracle backend
Zsombor Gegesy created RANGER-2035: -- Summary: Errors accessing servicedefs with empty implClass with Oracle backend Key: RANGER-2035 URL: https://issues.apache.org/jira/browse/RANGER-2035 Project: Ranger Issue Type: Bug Components: admin Affects Versions: 0.7.1, 1.0.0 Environment: Oracle DB Reporter: Zsombor Gegesy Assignee: Zsombor Gegesy Fix For: 0.7.2, 1.1.0, 1.0.1 Oracle treats empty strings and nulls as equals - if an empty string is inserted, later, it returns as NULL. This cause problems when a service def is created, with implementation classname specified as a zero length string. However, when later it is retrieved or updated or delete, Ranger throws various exceptions. In 1.0.0 a couple of exceptions are fixed, because of RANGER-1377, however in 0.7, there is more NPE. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (RANGER-2028) Fix release build scripts to conform to latest Apache release guidelines
[ https://issues.apache.org/jira/browse/RANGER-2028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16409310#comment-16409310 ] Zsombor Gegesy commented on RANGER-2028: Commit merged: https://github.com/apache/ranger/commit/4970af966b1b29db729002f4e8130595be4c28db > Fix release build scripts to conform to latest Apache release guidelines > > > Key: RANGER-2028 > URL: https://issues.apache.org/jira/browse/RANGER-2028 > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: Colm O hEigeartaigh >Assignee: Velmurugan Periasamy >Priority: Major > Fix For: 1.1.0 > > > Fix the release build scripts to conform to the Apache release guidelines > surrounding hashes: > [http://www.apache.org/dev/release-distribution#sigs-and-sums] > The names of signature and checksum files MUST be formed by adding to the > name of the artifact the following suffixes: > - .asc for a (ASCII armored) PGP signature > - .sha1 for a SHA-1 checksum > - .sha256 for a SHA-256 checksum > - .sha512 for a SHA-512 checksum > - .md5 for a MD5 checksum > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (RANGER-2016) Fix null passed in as a HttpServletRequest - into the deletePoliciesProvidedInServiceMap method.
[ https://issues.apache.org/jira/browse/RANGER-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy updated RANGER-2016: --- Attachment: RANGER-2016.patch > Fix null passed in as a HttpServletRequest - into the > deletePoliciesProvidedInServiceMap method. > > > Key: RANGER-2016 > URL: https://issues.apache.org/jira/browse/RANGER-2016 > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: Velmurugan Periasamy >Assignee: Zsombor Gegesy >Priority: Major > Fix For: 1.1.0 > > Attachments: RANGER-2016.patch > > > Refer https://issues.apache.org/jira/browse/RANGER-1991 for details. > This issue is to get [~zsombor]'s fix into master and 1.1.0 release. CC > [~pradeepagrawal8184] > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (RANGER-1991) Fix problems detected by static code analysis
[
https://issues.apache.org/jira/browse/RANGER-1991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zsombor Gegesy updated RANGER-1991:
---
Attachment: RANGER-1991-fix.patch
> 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] [Updated] (RANGER-1512) Ranger installer fails if hostname contains upper case letter
[ https://issues.apache.org/jira/browse/RANGER-1512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy updated RANGER-1512: --- Fix Version/s: (was: master) 1.0.0 > Ranger installer fails if hostname contains upper case letter > -- > > Key: RANGER-1512 > URL: https://issues.apache.org/jira/browse/RANGER-1512 > Project: Ranger > Issue Type: Bug > Components: Ranger >Affects Versions: master >Reporter: Attila Csoma >Priority: Minor > Labels: newbie > Fix For: 1.0.0 > > Attachments: > 0001-RANGER-1512-Convert-hostnames-to-lowercase-when-usin.patch > > > Installing Ranger with Ambari 2.4.2 Web UI fails if hostname contains upper > case letter due to that mysql stores uppercase hostnames in lowercase format. > Traceback: > resource_management.core.exceptions.ExecutionFailed: Execution of > 'ambari-python-wrap /usr/hdp/current/ranger-admin/dba_script.py -q' > ... > 2017-04-12 13:05:46,559 [I] Verifying user rangeradmin for Host > os-r6-EU-253TO255-Kerberized-2.openstacklocal > 2017-04-12 13:05:46,559 [JISQL] /usr/jdk64/jdk1.8.0_112/bin/java -cp > /usr/hdp/2.5.3.0-37/ranger-admin/ews/lib/mysql-connector-java.jar:/usr/hdp/current/ranger-admin/jisql/lib/* > org.apache.util.sql.Jisql -driver mysqlconj -cstring > jdbc:mysql://os-r6-EU-253TO255-Kerberized-2.openstacklocal/mysql -u root2 -p > '' -noheader -trim -c \; -query "select user from mysql.user where > user='rangeradmin' and host='os-r6-EU-253TO255-Kerberized-2.openstacklocal';" > 2017-04-12 13:05:47,225 [I] MySQL user rangeradmin does not exists for host > os-r6-EU-253TO255-Kerberized-2.openstacklocal > 2017-04-12 13:05:47,225 [JISQL] /usr/jdk64/jdk1.8.0_112/bin/java -cp > /usr/hdp/2.5.3.0-37/ranger-admin/ews/lib/mysql-connector-java.jar:/usr/hdp/current/ranger-admin/jisql/lib/* > org.apache.util.sql.Jisql -driver mysqlconj -cstring > jdbc:mysql://os-r6-EU-253TO255-Kerberized-2.openstacklocal/mysql -u root2 -p > '' -noheader -trim -c \; -query "create user > 'rangeradmin'@'os-r6-EU-253TO255-Kerberized-2.openstacklocal' identified by > '';" > 2017-04-12 13:05:47,892 [I] Verifying user rangeradmin for Host > os-r6-EU-253TO255-Kerberized-2.openstacklocal > 2017-04-12 13:05:47,893 [JISQL] /usr/jdk64/jdk1.8.0_112/bin/java -cp > /usr/hdp/2.5.3.0-37/ranger-admin/ews/lib/mysql-connector-java.jar:/usr/hdp/current/ranger-admin/jisql/lib/* > org.apache.util.sql.Jisql -driver mysqlconj -cstring > jdbc:mysql://os-r6-EU-253TO255-Kerberized-2.openstacklocal/mysql -u root2 -p > '' -noheader -trim -c \; -query "select user from mysql.user where > user='rangeradmin' and host='os-r6-EU-253TO255-Kerberized-2.openstacklocal';" > 2017-04-12 13:05:48,563 [E] Creating MySQL user rangeradmin failed.. > However in mysql: > mysql> select user, host from mysql.user; > +-+---+ > | user| host | > +-+---+ > ... > | rangeradmin | os-r6-eu-253to255-kerberized-2.openstacklocal | > +-+---+ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (RANGER-1368) different service on the same machine would make the shared audit local buffer directory access confilct when using hdfs to store audit log
[ https://issues.apache.org/jira/browse/RANGER-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy resolved RANGER-1368. Resolution: Won't Fix > different service on the same machine would make the shared audit local > buffer directory access confilct when using hdfs to store audit log > --- > > Key: RANGER-1368 > URL: https://issues.apache.org/jira/browse/RANGER-1368 > Project: Ranger > Issue Type: Bug > Components: audit >Affects Versions: 0.6.0, 0.7.0 > Environment: linux centos 6,ranger 0.6.0 >Reporter: zhangxiong >Priority: Major > Attachments: > 0002-make-the-common-dir-created-for-audit-log-local-file.patch > > > when configured hdfs to store ranger audit log, different service on the same > machine would make the shared audit local buffer directory access confilct. > detail: > suppose that we have a server S with one hdfs NameNode NN and yarn > ResourceManager RM deployed on it, and ranger configured hdfs as audit log > storage backend and configured a local log buffer directory /tmp/ranger/log/ > via 'xasecure.audit.hdfs.config.local.buffer.directory' . > first ,namenode started and find the directory /tmp/ranger/log/ doesn't > exists, so NN created the dir with access mod 700 and continues its own work > . then resourcemanager started and need to store its audit log to the already > exist dir ,unfortunately RM has no access authz to the dir and cannot work > well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (RANGER-1368) different service on the same machine would make the shared audit local buffer directory access confilct when using hdfs to store audit log
[ https://issues.apache.org/jira/browse/RANGER-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16388081#comment-16388081 ] Zsombor Gegesy edited comment on RANGER-1368 at 3/6/18 4:46 PM: This should be handled by the installation scripts, not by Ranger startup code. And making a directory world readable is generally a very bad idea. You should configure the local spool directory to be separate folders. was (Author: zsombor): This should be handled by the installation scripts, not by Ranger startup code. And making a directory world readable is generally a very bad idea. > different service on the same machine would make the shared audit local > buffer directory access confilct when using hdfs to store audit log > --- > > Key: RANGER-1368 > URL: https://issues.apache.org/jira/browse/RANGER-1368 > Project: Ranger > Issue Type: Bug > Components: audit >Affects Versions: 0.6.0, 0.7.0 > Environment: linux centos 6,ranger 0.6.0 >Reporter: zhangxiong >Priority: Major > Attachments: > 0002-make-the-common-dir-created-for-audit-log-local-file.patch > > > when configured hdfs to store ranger audit log, different service on the same > machine would make the shared audit local buffer directory access confilct. > detail: > suppose that we have a server S with one hdfs NameNode NN and yarn > ResourceManager RM deployed on it, and ranger configured hdfs as audit log > storage backend and configured a local log buffer directory /tmp/ranger/log/ > via 'xasecure.audit.hdfs.config.local.buffer.directory' . > first ,namenode started and find the directory /tmp/ranger/log/ doesn't > exists, so NN created the dir with access mod 700 and continues its own work > . then resourcemanager started and need to store its audit log to the already > exist dir ,unfortunately RM has no access authz to the dir and cannot work > well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (RANGER-1368) different service on the same machine would make the shared audit local buffer directory access confilct when using hdfs to store audit log
[ https://issues.apache.org/jira/browse/RANGER-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16388081#comment-16388081 ] Zsombor Gegesy commented on RANGER-1368: This should be handled by the installation scripts, not by Ranger startup code. And making a directory world readable is generally a very bad idea. > different service on the same machine would make the shared audit local > buffer directory access confilct when using hdfs to store audit log > --- > > Key: RANGER-1368 > URL: https://issues.apache.org/jira/browse/RANGER-1368 > Project: Ranger > Issue Type: Bug > Components: audit >Affects Versions: 0.6.0, 0.7.0 > Environment: linux centos 6,ranger 0.6.0 >Reporter: zhangxiong >Priority: Major > Attachments: > 0002-make-the-common-dir-created-for-audit-log-local-file.patch > > > when configured hdfs to store ranger audit log, different service on the same > machine would make the shared audit local buffer directory access confilct. > detail: > suppose that we have a server S with one hdfs NameNode NN and yarn > ResourceManager RM deployed on it, and ranger configured hdfs as audit log > storage backend and configured a local log buffer directory /tmp/ranger/log/ > via 'xasecure.audit.hdfs.config.local.buffer.directory' . > first ,namenode started and find the directory /tmp/ranger/log/ doesn't > exists, so NN created the dir with access mod 700 and continues its own work > . then resourcemanager started and need to store its audit log to the already > exist dir ,unfortunately RM has no access authz to the dir and cannot work > well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (RANGER-1967) The Ranger support the Kafka 1.0.0
[ https://issues.apache.org/jira/browse/RANGER-1967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16383685#comment-16383685 ] Zsombor Gegesy commented on RANGER-1967: Commited to [1.0 branch|https://github.com/apache/ranger/commit/55fe5844a3beb1ff54a51bb5c93f15c631426ebc] too > The Ranger support the Kafka 1.0.0 > -- > > Key: RANGER-1967 > URL: https://issues.apache.org/jira/browse/RANGER-1967 > Project: Ranger > Issue Type: New Feature > Components: plugins >Reporter: Qiang Zhang >Assignee: Zsombor Gegesy >Priority: Major > Labels: newbie, patch > Fix For: 1.0.0 > > Attachments: RANGER-1967-2.patch, RANGER-1967-3.patch, > RANGER-1967.patch > > > Now the Ranger don't support the Kafka 1.0.0. We should support the Kafka > 1.0.0. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (RANGER-1967) The Ranger support the Kafka 1.0.0
[ https://issues.apache.org/jira/browse/RANGER-1967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy updated RANGER-1967: --- Fix Version/s: (was: master) 1.0.0 > The Ranger support the Kafka 1.0.0 > -- > > Key: RANGER-1967 > URL: https://issues.apache.org/jira/browse/RANGER-1967 > Project: Ranger > Issue Type: New Feature > Components: plugins >Reporter: Qiang Zhang >Assignee: Zsombor Gegesy >Priority: Major > Labels: newbie, patch > Fix For: 1.0.0 > > Attachments: RANGER-1967-2.patch, RANGER-1967-3.patch, > RANGER-1967.patch > > > Now the Ranger don't support the Kafka 1.0.0. We should support the Kafka > 1.0.0. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (RANGER-1991) Fix problems detected by static code analysis
[
https://issues.apache.org/jira/browse/RANGER-1991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16383681#comment-16383681
]
Zsombor Gegesy commented on RANGER-1991:
Commited to 1.0 branch:
https://github.com/apache/ranger/commit/fdce224fa1aa63eba2fec2dce52f3d5ac3532df6
> Fix problems detected by static code analysis
> -
>
> Key: RANGER-1991
> URL: https://issues.apache.org/jira/browse/RANGER-1991
> Project: Ranger
> Issue Type: Bug
> Components: admin
>Affects Versions: 0.7.1
>Reporter: Zsombor Gegesy
>Assignee: Zsombor Gegesy
>Priority: Minor
> Labels: code-cleanup, findbugs
> Fix For: 1.0.0
>
> Attachments: RANGER-1991.patch
>
>
> FindBugs/SpotBug detects a couple of problems with the code base:
> * Incorrect class casting - in XXServiceDef.equals
> * Unnecessary NPE checks - for variables which is known to be non-null (for
> example, because in other places a method is called on that object). In
> ServiceREST.java PublicAPIs.java, ServiceUtil.java and independently in
> XUserMgr.java
> * Collection.contains method call which is never true - in
> ServiceDBStore.validatePolicyItems for policyItem.getAccesses().contains("")
> - because getAccesses doesn't store String objects
> * Making public partially initialized objects in
> HadoopConfigHolder.initResourceMap()
> * Calling toString on array, which is not too readable
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (RANGER-1991) Fix problems detected by static code analysis
[
https://issues.apache.org/jira/browse/RANGER-1991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zsombor Gegesy updated RANGER-1991:
---
Fix Version/s: (was: master)
1.0.0
> Fix problems detected by static code analysis
> -
>
> Key: RANGER-1991
> URL: https://issues.apache.org/jira/browse/RANGER-1991
> Project: Ranger
> Issue Type: Bug
> Components: admin
>Affects Versions: 0.7.1
>Reporter: Zsombor Gegesy
>Assignee: Zsombor Gegesy
>Priority: Minor
> Labels: code-cleanup, findbugs
> Fix For: 1.0.0
>
> Attachments: RANGER-1991.patch
>
>
> FindBugs/SpotBug detects a couple of problems with the code base:
> * Incorrect class casting - in XXServiceDef.equals
> * Unnecessary NPE checks - for variables which is known to be non-null (for
> example, because in other places a method is called on that object). In
> ServiceREST.java PublicAPIs.java, ServiceUtil.java and independently in
> XUserMgr.java
> * Collection.contains method call which is never true - in
> ServiceDBStore.validatePolicyItems for policyItem.getAccesses().contains("")
> - because getAccesses doesn't store String objects
> * Making public partially initialized objects in
> HadoopConfigHolder.initResourceMap()
> * Calling toString on array, which is not too readable
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (RANGER-1961) Fixed spelling error "condtion"
[ https://issues.apache.org/jira/browse/RANGER-1961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy resolved RANGER-1961. Resolution: Fixed Thanks Willie for your contribution! > Fixed spelling error "condtion" > --- > > Key: RANGER-1961 > URL: https://issues.apache.org/jira/browse/RANGER-1961 > Project: Ranger > Issue Type: Bug > Components: tagsync >Affects Versions: master >Reporter: Willie Engelbrecht >Priority: Trivial > Fix For: 1.0.0 > > Attachments: > 0001-Fixed-spelling-mistake-of-condtion-to-condition.patch > > > When creating a new tag policy, under "Add conditions" there is an input box > with the text: Please enter condtion.. > The patch corrects the spelling to _condition_ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (RANGER-1991) Fix problems detected by static code analysis
[
https://issues.apache.org/jira/browse/RANGER-1991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16380083#comment-16380083
]
Zsombor Gegesy commented on RANGER-1991:
Change commited to the master branch:
https://github.com/apache/ranger/commit/49b8a7a26653b028b7adaff3809a88f59fee3bf7
> Fix problems detected by static code analysis
> -
>
> Key: RANGER-1991
> URL: https://issues.apache.org/jira/browse/RANGER-1991
> Project: Ranger
> Issue Type: Bug
> Components: admin
>Affects Versions: 0.7.1
>Reporter: Zsombor Gegesy
>Assignee: Zsombor Gegesy
>Priority: Minor
> Labels: code-cleanup, findbugs
> Fix For: master
>
> Attachments: RANGER-1991.patch
>
>
> FindBugs/SpotBug detects a couple of problems with the code base:
> * Incorrect class casting - in XXServiceDef.equals
> * Unnecessary NPE checks - for variables which is known to be non-null (for
> example, because in other places a method is called on that object). In
> ServiceREST.java PublicAPIs.java, ServiceUtil.java and independently in
> XUserMgr.java
> * Collection.contains method call which is never true - in
> ServiceDBStore.validatePolicyItems for policyItem.getAccesses().contains("")
> - because getAccesses doesn't store String objects
> * Making public partially initialized objects in
> HadoopConfigHolder.initResourceMap()
> * Calling toString on array, which is not too readable
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (RANGER-1991) Fix problems detected by static code analysis
[
https://issues.apache.org/jira/browse/RANGER-1991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zsombor Gegesy updated RANGER-1991:
---
Fix Version/s: master
> Fix problems detected by static code analysis
> -
>
> Key: RANGER-1991
> URL: https://issues.apache.org/jira/browse/RANGER-1991
> Project: Ranger
> Issue Type: Bug
> Components: admin
>Affects Versions: 0.7.1
>Reporter: Zsombor Gegesy
>Assignee: Zsombor Gegesy
>Priority: Minor
> Labels: code-cleanup, findbugs
> Fix For: master
>
> Attachments: RANGER-1991.patch
>
>
> FindBugs/SpotBug detects a couple of problems with the code base:
> * Incorrect class casting - in XXServiceDef.equals
> * Unnecessary NPE checks - for variables which is known to be non-null (for
> example, because in other places a method is called on that object). In
> ServiceREST.java PublicAPIs.java, ServiceUtil.java and independently in
> XUserMgr.java
> * Collection.contains method call which is never true - in
> ServiceDBStore.validatePolicyItems for policyItem.getAccesses().contains("")
> - because getAccesses doesn't store String objects
> * Making public partially initialized objects in
> HadoopConfigHolder.initResourceMap()
> * Calling toString on array, which is not too readable
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (RANGER-1967) The Ranger support the Kafka 1.0.0
[ https://issues.apache.org/jira/browse/RANGER-1967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy updated RANGER-1967: --- Attachment: RANGER-1967-3.patch > The Ranger support the Kafka 1.0.0 > -- > > Key: RANGER-1967 > URL: https://issues.apache.org/jira/browse/RANGER-1967 > Project: Ranger > Issue Type: New Feature > Components: plugins >Reporter: Qiang Zhang >Assignee: Zsombor Gegesy >Priority: Major > Labels: newbie, patch > Attachments: RANGER-1967-2.patch, RANGER-1967-3.patch, > RANGER-1967.patch > > > Now the Ranger don't support the Kafka 1.0.0. We should support the Kafka > 1.0.0. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (RANGER-1961) Fixed spelling error "condtion"
[ https://issues.apache.org/jira/browse/RANGER-1961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16375635#comment-16375635 ] Zsombor Gegesy commented on RANGER-1961: Patch commited to master : https://github.com/apache/ranger/commit/04b4e167b14d768a160d4342ed12302f9449994f > Fixed spelling error "condtion" > --- > > Key: RANGER-1961 > URL: https://issues.apache.org/jira/browse/RANGER-1961 > Project: Ranger > Issue Type: Bug > Components: tagsync >Affects Versions: master >Reporter: Willie Engelbrecht >Priority: Trivial > Fix For: 1.0.0 > > Attachments: > 0001-Fixed-spelling-mistake-of-condtion-to-condition.patch > > > When creating a new tag policy, under "Add conditions" there is an input box > with the text: Please enter condtion.. > The patch corrects the spelling to _condition_ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (RANGER-1961) Fixed spelling error "condtion"
[ https://issues.apache.org/jira/browse/RANGER-1961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy updated RANGER-1961: --- Fix Version/s: 1.0.0 > Fixed spelling error "condtion" > --- > > Key: RANGER-1961 > URL: https://issues.apache.org/jira/browse/RANGER-1961 > Project: Ranger > Issue Type: Bug > Components: tagsync >Affects Versions: master >Reporter: Willie Engelbrecht >Priority: Trivial > Fix For: 1.0.0 > > Attachments: > 0001-Fixed-spelling-mistake-of-condtion-to-condition.patch > > > When creating a new tag policy, under "Add conditions" there is an input box > with the text: Please enter condtion.. > The patch corrects the spelling to _condition_ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (RANGER-1991) Fix problems detected by static code analysis
[
https://issues.apache.org/jira/browse/RANGER-1991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zsombor Gegesy updated RANGER-1991:
---
Attachment: RANGER-1991.patch
> Fix problems detected by static code analysis
> -
>
> Key: RANGER-1991
> URL: https://issues.apache.org/jira/browse/RANGER-1991
> Project: Ranger
> Issue Type: Bug
> Components: admin
>Affects Versions: 0.7.1
>Reporter: Zsombor Gegesy
>Assignee: Zsombor Gegesy
>Priority: Minor
> Labels: code-cleanup, findbugs
> Attachments: RANGER-1991.patch
>
>
> FindBugs/SpotBug detects a couple of problems with the code base:
> * Incorrect class casting - in XXServiceDef.equals
> * Unnecessary NPE checks - for variables which is known to be non-null (for
> example, because in other places a method is called on that object). In
> ServiceREST.java PublicAPIs.java, ServiceUtil.java and independently in
> XUserMgr.java
> * Collection.contains method call which is never true - in
> ServiceDBStore.validatePolicyItems for policyItem.getAccesses().contains("")
> - because getAccesses doesn't store String objects
> * Making public partially initialized objects in
> HadoopConfigHolder.initResourceMap()
> * Calling toString on array, which is not too readable
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (RANGER-1991) Fix problems detected by static code analysis
Zsombor Gegesy created RANGER-1991:
--
Summary: 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
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-1987) Upgrade to Storm 1.2.0
[ https://issues.apache.org/jira/browse/RANGER-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16375502#comment-16375502 ] Zsombor Gegesy commented on RANGER-1987: Commit merged to master: https://github.com/apache/ranger/commit/7514a9102b6649f0043220e0708a71d1ec6d0c77 > Upgrade to Storm 1.2.0 > -- > > Key: RANGER-1987 > URL: https://issues.apache.org/jira/browse/RANGER-1987 > Project: Ranger > Issue Type: Improvement > Components: plugins >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh >Priority: Major > Fix For: 1.0.0 > > Attachments: 0001-RANGER-1987-Upgrade-to-Storm-1.2.0.patch > > > > We should upgrade to the recently release Apache Storm 1.2.0. No code changes > are required. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (RANGER-1967) The Ranger support the Kafka 1.0.0
[ https://issues.apache.org/jira/browse/RANGER-1967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16375465#comment-16375465 ] Zsombor Gegesy commented on RANGER-1967: The updated review request is here: https://reviews.apache.org/r/65777/ > The Ranger support the Kafka 1.0.0 > -- > > Key: RANGER-1967 > URL: https://issues.apache.org/jira/browse/RANGER-1967 > Project: Ranger > Issue Type: New Feature > Components: plugins >Reporter: Qiang Zhang >Assignee: Zsombor Gegesy >Priority: Major > Labels: newbie, patch > Attachments: RANGER-1967-2.patch, RANGER-1967.patch > > > Now the Ranger don't support the Kafka 1.0.0. We should support the Kafka > 1.0.0. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (RANGER-1967) The Ranger support the Kafka 1.0.0
[ https://issues.apache.org/jira/browse/RANGER-1967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy updated RANGER-1967: --- Attachment: RANGER-1967-2.patch > The Ranger support the Kafka 1.0.0 > -- > > Key: RANGER-1967 > URL: https://issues.apache.org/jira/browse/RANGER-1967 > Project: Ranger > Issue Type: New Feature > Components: plugins >Reporter: Qiang Zhang >Assignee: Zsombor Gegesy >Priority: Major > Labels: newbie, patch > Attachments: RANGER-1967-2.patch, RANGER-1967.patch > > > Now the Ranger don't support the Kafka 1.0.0. We should support the Kafka > 1.0.0. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (RANGER-1967) The Ranger support the Kafka 1.0.0
[ https://issues.apache.org/jira/browse/RANGER-1967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16374982#comment-16374982 ] Zsombor Gegesy commented on RANGER-1967: I had some free time to implement it, the API changes are not too big, however running Kafka in embedded mode turned out to be a bit trickier beast. I had to add a couple of new flags, otherwise it would wait for 2 other broker to join. > The Ranger support the Kafka 1.0.0 > -- > > Key: RANGER-1967 > URL: https://issues.apache.org/jira/browse/RANGER-1967 > Project: Ranger > Issue Type: New Feature > Components: plugins >Reporter: Qiang Zhang >Assignee: Qiang Zhang >Priority: Major > Labels: newbie, patch > Attachments: RANGER-1967.patch > > > Now the Ranger don't support the Kafka 1.0.0. We should support the Kafka > 1.0.0. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (RANGER-1967) The Ranger support the Kafka 1.0.0
[ https://issues.apache.org/jira/browse/RANGER-1967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy updated RANGER-1967: --- Attachment: RANGER-1967.patch > The Ranger support the Kafka 1.0.0 > -- > > Key: RANGER-1967 > URL: https://issues.apache.org/jira/browse/RANGER-1967 > Project: Ranger > Issue Type: New Feature > Components: plugins >Reporter: Qiang Zhang >Assignee: Qiang Zhang >Priority: Major > Labels: newbie, patch > Attachments: RANGER-1967.patch > > > Now the Ranger don't support the Kafka 1.0.0. We should support the Kafka > 1.0.0. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (RANGER-1969) Fix failing Kafka tests with latest maven/JVM
[ https://issues.apache.org/jira/browse/RANGER-1969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy reassigned RANGER-1969: -- Assignee: Colm O hEigeartaigh (was: Zsombor Gegesy) > Fix failing Kafka tests with latest maven/JVM > - > > Key: RANGER-1969 > URL: https://issues.apache.org/jira/browse/RANGER-1969 > Project: Ranger > Issue Type: Improvement > Components: plugins >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh >Priority: Major > Fix For: 1.0.0 > > Attachments: > 0001-RANGER-1969-Fix-failing-Kafka-tests-with-latest-mave.patch > > > The Kafka SASL/SSL test is crashing for me with the latest Maven/JVM. > Upgrading the surefire plugin solves the problem. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (RANGER-1969) Fix failing Kafka tests with latest maven/JVM
[ https://issues.apache.org/jira/browse/RANGER-1969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy reassigned RANGER-1969: -- Assignee: Zsombor Gegesy (was: Colm O hEigeartaigh) > Fix failing Kafka tests with latest maven/JVM > - > > Key: RANGER-1969 > URL: https://issues.apache.org/jira/browse/RANGER-1969 > Project: Ranger > Issue Type: Improvement > Components: plugins >Reporter: Colm O hEigeartaigh >Assignee: Zsombor Gegesy >Priority: Major > Fix For: 1.0.0 > > Attachments: > 0001-RANGER-1969-Fix-failing-Kafka-tests-with-latest-mave.patch > > > The Kafka SASL/SSL test is crashing for me with the latest Maven/JVM. > Upgrading the surefire plugin solves the problem. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (RANGER-1949) KMS getKeys should filter based on name policy
[
https://issues.apache.org/jira/browse/RANGER-1949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zsombor Gegesy updated RANGER-1949:
---
Attachment: RANGER-1949.patch
> KMS getKeys should filter based on name policy
> --
>
> Key: RANGER-1949
> URL: https://issues.apache.org/jira/browse/RANGER-1949
> Project: Ranger
> Issue Type: Bug
> Components: kms
>Reporter: Owen O'Malley
>Assignee: Zsombor Gegesy
> Attachments: RANGER-1949.patch
>
>
> Currently when there are policies that limit users to certain keys, such as
> "pii*" those users can't call KMS.getKeyNames() even if they have the
> "getkeys" permission.
> This is because the method passes a null down for the key name, which will
> only match if the user can see all keys. A much better solution would be to
> filter each key individually and just returns the ones that should be
> visible. So if they have permission to see "pii*" and the keys were {"pii",
> "pii256", and "secret"} they would get back a list of "pii" and "pii256".
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (RANGER-1951) build problems with the saveVersion.py script
[ https://issues.apache.org/jira/browse/RANGER-1951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy updated RANGER-1951: --- Attachment: RANGER-1951-1.patch > build problems with the saveVersion.py script > - > > Key: RANGER-1951 > URL: https://issues.apache.org/jira/browse/RANGER-1951 > Project: Ranger > Issue Type: Bug > Components: build-infra >Affects Versions: 0.7.1 >Reporter: Zsombor Gegesy >Assignee: Zsombor Gegesy > Fix For: 1.0.0 > > Attachments: RANGER-1951-1.patch > > > Currently the saveVersion.py has the following problems: > * it doesn't work with python3 due to 'inconsistent whitespace usage' and > because in python3 the byte array is different from a string > * The checksum is generated from all the java source files from > ranger-util/target, which contains at most one java file - a previously > generated ranger-util/target/gen/org/apache/ranger/common/package-info.java > * -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (RANGER-1951) build problems with the saveVersion.py script
Zsombor Gegesy created RANGER-1951: -- Summary: build problems with the saveVersion.py script Key: RANGER-1951 URL: https://issues.apache.org/jira/browse/RANGER-1951 Project: Ranger Issue Type: Bug Components: build-infra Affects Versions: 0.7.1 Reporter: Zsombor Gegesy Assignee: Zsombor Gegesy Fix For: 1.0.0 Currently the saveVersion.py has the following problems: * it doesn't work with python3 due to 'inconsistent whitespace usage' and because in python3 the byte array is different from a string * The checksum is generated from all the java source files from ranger-util/target, which contains at most one java file - a previously generated ranger-util/target/gen/org/apache/ranger/common/package-info.java * -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (RANGER-1949) KMS getKeys should filter based on name policy
[
https://issues.apache.org/jira/browse/RANGER-1949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16319428#comment-16319428
]
Zsombor Gegesy commented on RANGER-1949:
It looks like a bug - or a missing feature. The original Hadoop KMS code is not
structured to be extendable by an other KMS (like Ranger), and assumes a very
simplistic permission model. As it is copied into the ranger codebase, we can
fix it with either passing the user information down through the
_KeyProvider_/_KeyProviderExtension_ layers - to _RangerKeyStoreProvider_ which
would be a bigger change, or we can apply the filtering with introducing a new
method on _KMSWebApp.getACLs().filterKeys(UserGroupInformation,String clientIp,
List keys)_ - which looks a bit better for me.
However, it would be good, if these changes could be upstreamed to Hadoop KMS
as well - so in the future, we can remove lot of copy-pasted, and slightly
modified code from Ranger. I've started working on these issue a couple of
month ago (for RANGER-1869, in HADOOP-14951 and HADOOP-15014 ) but it's haven't
merged yet.
> KMS getKeys should filter based on name policy
> --
>
> Key: RANGER-1949
> URL: https://issues.apache.org/jira/browse/RANGER-1949
> Project: Ranger
> Issue Type: Bug
> Components: kms
>Reporter: Owen O'Malley
>
> Currently when there are policies that limit users to certain keys, such as
> "pii*" those users can't call KMS.getKeyNames() even if they have the
> "getkeys" permission.
> This is because the method passes a null down for the key name, which will
> only match if the user can see all keys. A much better solution would be to
> filter each key individually and just returns the ones that should be
> visible. So if they have permission to see "pii*" and the keys were {"pii",
> "pii256", and "secret"} they would get back a list of "pii" and "pii256".
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (RANGER-1949) KMS getKeys should filter based on name policy
[
https://issues.apache.org/jira/browse/RANGER-1949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zsombor Gegesy reassigned RANGER-1949:
--
Assignee: Zsombor Gegesy
> KMS getKeys should filter based on name policy
> --
>
> Key: RANGER-1949
> URL: https://issues.apache.org/jira/browse/RANGER-1949
> Project: Ranger
> Issue Type: Bug
> Components: kms
>Reporter: Owen O'Malley
>Assignee: Zsombor Gegesy
>
> Currently when there are policies that limit users to certain keys, such as
> "pii*" those users can't call KMS.getKeyNames() even if they have the
> "getkeys" permission.
> This is because the method passes a null down for the key name, which will
> only match if the user can see all keys. A much better solution would be to
> filter each key individually and just returns the ones that should be
> visible. So if they have permission to see "pii*" and the keys were {"pii",
> "pii256", and "secret"} they would get back a list of "pii" and "pii256".
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (RANGER-1947) RangerHivePlugin does not authorize location on INSERT OVERWRITE DIRECTORY query
[
https://issues.apache.org/jira/browse/RANGER-1947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16318550#comment-16318550
]
Zsombor Gegesy commented on RANGER-1947:
Writing to the hdfs should be checked by the hdfs plugin. If Hive is configured
with user impersonation, then it will inherit the user rights, otherwise it
will try to act as user 'hive'. You should configure appropriate HDFS policy
for your cluster to avoid the problem.
> RangerHivePlugin does not authorize location on INSERT OVERWRITE DIRECTORY
> query
>
>
> Key: RANGER-1947
> URL: https://issues.apache.org/jira/browse/RANGER-1947
> Project: Ranger
> Issue Type: Bug
> Components: plugins
>Affects Versions: 0.7.1
> Environment: hadoop 2.7.5 + hive 2.3.2 + ranger 0.7.1
>Reporter: Jake Moon
>
> {code}
> insert overwrite directory '/user/user1/nonewrite3'
> ROW FORMAT DELIMITED
> FIELDS TERMINATED BY ','
> SELECT u.id, u.age, u.city, c.city
> FROM user_table u JOIN city_table c ON (u.city = c.code)
> WHERE u.age > 25
> AND u.age <= 28
> AND c.city = 'New York'
> {code}
> This query's hive operation type is HiveOperationType.QUERY, and also have a
> write location to 'hdfs://my.cluster/user/user1/nonewrite3'
> RangerHiveAuthorizer must authorize the location, but
> getURIAccessType(HiveOperationType.QUERY) always return FsAction.NONE, so
> it's not work.
> If hive-server2 have enough permission on hdfs with no impersonation, every
> user can format hdfs like this.
> {code}
> insert overwrite directory '/'
> ROW FORMAT DELIMITED
> FIELDS TERMINATED BY ','
> SELECT 1
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (RANGER-1905) NoClassDefFoundError from the built zip/tar.gz, created by the maven-assembly-plugin
[
https://issues.apache.org/jira/browse/RANGER-1905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zsombor Gegesy updated RANGER-1905:
---
Attachment: RANGER-1905-4.patch
> NoClassDefFoundError from the built zip/tar.gz, created by the
> maven-assembly-plugin
>
>
> Key: RANGER-1905
> URL: https://issues.apache.org/jira/browse/RANGER-1905
> Project: Ranger
> Issue Type: Bug
> Components: admin
>Reporter: Zsombor Gegesy
>Assignee: Zsombor Gegesy
>Priority: Blocker
> Attachments: RANGER-1905-2.patch, RANGER-1905-3.patch,
> RANGER-1905-4.patch, RANGER-1905.patch
>
>
> It seems, because of the recent guava exclusions, the maven-assembly plugin
> fails to include guava-17.0.jar in ews/lib. It only puts into
> ews/webapp/WEB-INF/lib and cred/lib/guava-17.0.jar. Unfortunately this blocks
> starting up the server, because of the following exception:
> {code}
> Exception in thread "main" java.lang.NoClassDefFoundError:
> com/google/common/base/Preconditions
> at
> org.apache.hadoop.conf.Configuration$DeprecationDelta.(Configuration.java:336)
> at
> org.apache.hadoop.conf.Configuration$DeprecationDelta.(Configuration.java:349)
> at
> org.apache.hadoop.conf.Configuration.(Configuration.java:431)
> at
> org.apache.ranger.server.tomcat.EmbeddedServer.getDecryptedString(EmbeddedServer.java:480)
> at
> org.apache.ranger.server.tomcat.EmbeddedServer.start(EmbeddedServer.java:142)
> at
> org.apache.ranger.server.tomcat.EmbeddedServer.main(EmbeddedServer.java:76)
> Caused by: java.lang.ClassNotFoundException:
> com.google.common.base.Preconditions
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (RANGER-1921) Fix coverity warnings in RangerHdfsAuthorizer
[ https://issues.apache.org/jira/browse/RANGER-1921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy updated RANGER-1921: --- Attachment: RANGER-1921.patch > Fix coverity warnings in RangerHdfsAuthorizer > - > > Key: RANGER-1921 > URL: https://issues.apache.org/jira/browse/RANGER-1921 > Project: Ranger > Issue Type: Bug > Components: plugins >Affects Versions: master >Reporter: Zsombor Gegesy >Assignee: Zsombor Gegesy > Labels: coverity > Attachments: RANGER-1921.patch > > > There are a couple of coverity scan error reported -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (RANGER-1921) Fix coverity warnings in RangerHdfsAuthorizer
Zsombor Gegesy created RANGER-1921: -- Summary: Fix coverity warnings in RangerHdfsAuthorizer Key: RANGER-1921 URL: https://issues.apache.org/jira/browse/RANGER-1921 Project: Ranger Issue Type: Bug Components: plugins Affects Versions: master Reporter: Zsombor Gegesy Assignee: Zsombor Gegesy There are a couple of coverity scan error reported -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (RANGER-1905) NoClassDefFoundError from the built zip/tar.gz, created by the maven-assembly-plugin
[
https://issues.apache.org/jira/browse/RANGER-1905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zsombor Gegesy updated RANGER-1905:
---
Attachment: RANGER-1905-3.patch
> NoClassDefFoundError from the built zip/tar.gz, created by the
> maven-assembly-plugin
>
>
> Key: RANGER-1905
> URL: https://issues.apache.org/jira/browse/RANGER-1905
> Project: Ranger
> Issue Type: Bug
> Components: admin
>Reporter: Zsombor Gegesy
>Assignee: Zsombor Gegesy
>Priority: Blocker
> Attachments: RANGER-1905-2.patch, RANGER-1905-3.patch,
> RANGER-1905.patch
>
>
> It seems, because of the recent guava exclusions, the maven-assembly plugin
> fails to include guava-17.0.jar in ews/lib. It only puts into
> ews/webapp/WEB-INF/lib and cred/lib/guava-17.0.jar. Unfortunately this blocks
> starting up the server, because of the following exception:
> {code}
> Exception in thread "main" java.lang.NoClassDefFoundError:
> com/google/common/base/Preconditions
> at
> org.apache.hadoop.conf.Configuration$DeprecationDelta.(Configuration.java:336)
> at
> org.apache.hadoop.conf.Configuration$DeprecationDelta.(Configuration.java:349)
> at
> org.apache.hadoop.conf.Configuration.(Configuration.java:431)
> at
> org.apache.ranger.server.tomcat.EmbeddedServer.getDecryptedString(EmbeddedServer.java:480)
> at
> org.apache.ranger.server.tomcat.EmbeddedServer.start(EmbeddedServer.java:142)
> at
> org.apache.ranger.server.tomcat.EmbeddedServer.main(EmbeddedServer.java:76)
> Caused by: java.lang.ClassNotFoundException:
> com.google.common.base.Preconditions
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (RANGER-1707) Traverse check in RangerHdfsAuthorizer works incorrectly
[ https://issues.apache.org/jira/browse/RANGER-1707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy updated RANGER-1707: --- Attachment: RANGER-1707-3.patch > Traverse check in RangerHdfsAuthorizer works incorrectly > > > Key: RANGER-1707 > URL: https://issues.apache.org/jira/browse/RANGER-1707 > Project: Ranger > Issue Type: Bug > Components: plugins >Affects Versions: 1.0.0 >Reporter: Zsombor Gegesy >Assignee: Zsombor Gegesy > Labels: hdfs-2.8 > Fix For: 1.0.0 > > Attachments: > 0001-RANGER-1707-Fix-hdfs-traverse-check-which-problem-wa.patch, > RANGER-1707-2.patch, RANGER-1707-3.patch > > > Traversal check in RangerHdfsAuthorizer works incorrectly, when it is asked > for access to /a/b/c.txt, it only checks that if there are a policy which > grants EXEC to /a/b, but if it there aren't any, then it doesn't check, if > there is a policy which grants READ, WRITE or EXEC to /a/b/c.txt explicitly, > which would mean, that the path is accessible to the user. > This hasn't noticed by the current unit tests, because HDFS before 2.8.0 > doesn't called the traversal check before reading or writing a file, however > it will cause problem with 2.8.0, where FSDirectory.resolvePath will perform > a mandatory traversal check. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (RANGER-1905) NoClassDefFoundError from the built zip/tar.gz, created by the maven-assembly-plugin
[
https://issues.apache.org/jira/browse/RANGER-1905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zsombor Gegesy updated RANGER-1905:
---
Attachment: RANGER-1905-2.patch
> NoClassDefFoundError from the built zip/tar.gz, created by the
> maven-assembly-plugin
>
>
> Key: RANGER-1905
> URL: https://issues.apache.org/jira/browse/RANGER-1905
> Project: Ranger
> Issue Type: Bug
> Components: admin
>Reporter: Zsombor Gegesy
>Assignee: Zsombor Gegesy
>Priority: Blocker
> Attachments: RANGER-1905-2.patch, RANGER-1905.patch
>
>
> It seems, because of the recent guava exclusions, the maven-assembly plugin
> fails to include guava-17.0.jar in ews/lib. It only puts into
> ews/webapp/WEB-INF/lib and cred/lib/guava-17.0.jar. Unfortunately this blocks
> starting up the server, because of the following exception:
> {code}
> Exception in thread "main" java.lang.NoClassDefFoundError:
> com/google/common/base/Preconditions
> at
> org.apache.hadoop.conf.Configuration$DeprecationDelta.(Configuration.java:336)
> at
> org.apache.hadoop.conf.Configuration$DeprecationDelta.(Configuration.java:349)
> at
> org.apache.hadoop.conf.Configuration.(Configuration.java:431)
> at
> org.apache.ranger.server.tomcat.EmbeddedServer.getDecryptedString(EmbeddedServer.java:480)
> at
> org.apache.ranger.server.tomcat.EmbeddedServer.start(EmbeddedServer.java:142)
> at
> org.apache.ranger.server.tomcat.EmbeddedServer.main(EmbeddedServer.java:76)
> Caused by: java.lang.ClassNotFoundException:
> com.google.common.base.Preconditions
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (RANGER-1707) Traverse check in RangerHdfsAuthorizer works incorrectly
[ https://issues.apache.org/jira/browse/RANGER-1707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zsombor Gegesy updated RANGER-1707: --- Attachment: RANGER-1707-2.patch > Traverse check in RangerHdfsAuthorizer works incorrectly > > > Key: RANGER-1707 > URL: https://issues.apache.org/jira/browse/RANGER-1707 > Project: Ranger > Issue Type: Bug > Components: plugins >Affects Versions: 1.0.0 >Reporter: Zsombor Gegesy >Assignee: Zsombor Gegesy > Labels: hdfs-2.8 > Fix For: 1.0.0 > > Attachments: > 0001-RANGER-1707-Fix-hdfs-traverse-check-which-problem-wa.patch, > RANGER-1707-2.patch > > > Traversal check in RangerHdfsAuthorizer works incorrectly, when it is asked > for access to /a/b/c.txt, it only checks that if there are a policy which > grants EXEC to /a/b, but if it there aren't any, then it doesn't check, if > there is a policy which grants READ, WRITE or EXEC to /a/b/c.txt explicitly, > which would mean, that the path is accessible to the user. > This hasn't noticed by the current unit tests, because HDFS before 2.8.0 > doesn't called the traversal check before reading or writing a file, however > it will cause problem with 2.8.0, where FSDirectory.resolvePath will perform > a mandatory traversal check. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (RANGER-1905) NoClassDefFoundError from the built zip/tar.gz, created by the maven-assembly-plugin
[
https://issues.apache.org/jira/browse/RANGER-1905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zsombor Gegesy updated RANGER-1905:
---
Attachment: RANGER-1905.patch
> NoClassDefFoundError from the built zip/tar.gz, created by the
> maven-assembly-plugin
>
>
> Key: RANGER-1905
> URL: https://issues.apache.org/jira/browse/RANGER-1905
> Project: Ranger
> Issue Type: Bug
> Components: admin
>Reporter: Zsombor Gegesy
>Assignee: Zsombor Gegesy
>Priority: Blocker
> Attachments: RANGER-1905.patch
>
>
> It seems, because of the recent guava exclusions, the maven-assembly plugin
> fails to include guava-17.0.jar in ews/lib. It only puts into
> ews/webapp/WEB-INF/lib and cred/lib/guava-17.0.jar. Unfortunately this blocks
> starting up the server, because of the following exception:
> {code}
> Exception in thread "main" java.lang.NoClassDefFoundError:
> com/google/common/base/Preconditions
> at
> org.apache.hadoop.conf.Configuration$DeprecationDelta.(Configuration.java:336)
> at
> org.apache.hadoop.conf.Configuration$DeprecationDelta.(Configuration.java:349)
> at
> org.apache.hadoop.conf.Configuration.(Configuration.java:431)
> at
> org.apache.ranger.server.tomcat.EmbeddedServer.getDecryptedString(EmbeddedServer.java:480)
> at
> org.apache.ranger.server.tomcat.EmbeddedServer.start(EmbeddedServer.java:142)
> at
> org.apache.ranger.server.tomcat.EmbeddedServer.main(EmbeddedServer.java:76)
> Caused by: java.lang.ClassNotFoundException:
> com.google.common.base.Preconditions
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (RANGER-1905) NoClassDefFoundError from the built zip/tar.gz, created by the maven-assembly-plugin
Zsombor Gegesy created RANGER-1905:
--
Summary: NoClassDefFoundError from the built zip/tar.gz, created
by the maven-assembly-plugin
Key: RANGER-1905
URL: https://issues.apache.org/jira/browse/RANGER-1905
Project: Ranger
Issue Type: Bug
Components: admin
Reporter: Zsombor Gegesy
Assignee: Zsombor Gegesy
Priority: Blocker
It seems, because of the recent guava exclusions, the maven-assembly plugin
fails to include guava-17.0.jar in ews/lib. It only puts into
ews/webapp/WEB-INF/lib and cred/lib/guava-17.0.jar. Unfortunately this blocks
starting up the server, because of the following exception:
{code}
Exception in thread "main" java.lang.NoClassDefFoundError:
com/google/common/base/Preconditions
at
org.apache.hadoop.conf.Configuration$DeprecationDelta.(Configuration.java:336)
at
org.apache.hadoop.conf.Configuration$DeprecationDelta.(Configuration.java:349)
at org.apache.hadoop.conf.Configuration.(Configuration.java:431)
at
org.apache.ranger.server.tomcat.EmbeddedServer.getDecryptedString(EmbeddedServer.java:480)
at
org.apache.ranger.server.tomcat.EmbeddedServer.start(EmbeddedServer.java:142)
at
org.apache.ranger.server.tomcat.EmbeddedServer.main(EmbeddedServer.java:76)
Caused by: java.lang.ClassNotFoundException:
com.google.common.base.Preconditions
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
