[jira] [Commented] (SENTRY-2422) HMS synchronization is causing multiple entries of the same ID in SENTRY_HMS_NOTIFICATION_ID
[
https://issues.apache.org/jira/browse/SENTRY-2422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17164788#comment-17164788
]
Hadoop QA commented on SENTRY-2422:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/13008390/SENTRY-2422.003.patch
against master.
{color:red}Overall:{color} -1 due to 3 errors
{color:red}ERROR:{color} mvn test exited 1
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestHmsNotificationProcessingWithOutHdfsSync
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestHmsNotificationProcessingWithOutSyncOnDrop
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4486/console
This message is automatically generated.
> HMS synchronization is causing multiple entries of the same ID in
> SENTRY_HMS_NOTIFICATION_ID
>
>
> Key: SENTRY-2422
> URL: https://issues.apache.org/jira/browse/SENTRY-2422
> Project: Sentry
> Issue Type: Improvement
> Components: Core
>Affects Versions: 2.1.0, 2.0.1
>Reporter: Brian Towles
>Assignee: Na Li
>Priority: Major
> Attachments: SENTRY-2422.001.patch, SENTRY-2422.001.patch,
> SENTRY-2422.001.patch, SENTRY-2422.001.patch, SENTRY-2422.002.patch,
> SENTRY-2422.003.patch
>
>
> When processing updates for the HMS notifications, multiple entries of the
> same ID are being put into the SENTRY_HMS_NOTIFICATION_ID table.
> This can be seen after doing a non location changing ALTER TABLE in hive for
> example.
>
> ALTER TABLE sometable SET TBLPROPERTIES ("someproperty"="somevalue");
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SENTRY-2422) HMS synchronization is causing multiple entries of the same ID in SENTRY_HMS_NOTIFICATION_ID
[
https://issues.apache.org/jira/browse/SENTRY-2422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17164750#comment-17164750
]
Hadoop QA commented on SENTRY-2422:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/13008385/SENTRY-2422.002.patch
against master.
{color:green}Overall:{color} +1 all checks pass
{color:green}SUCCESS:{color} all tests passed
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4485/console
This message is automatically generated.
> HMS synchronization is causing multiple entries of the same ID in
> SENTRY_HMS_NOTIFICATION_ID
>
>
> Key: SENTRY-2422
> URL: https://issues.apache.org/jira/browse/SENTRY-2422
> Project: Sentry
> Issue Type: Improvement
> Components: Core
>Affects Versions: 2.1.0, 2.0.1
>Reporter: Brian Towles
>Assignee: Na Li
>Priority: Major
> Attachments: SENTRY-2422.001.patch, SENTRY-2422.001.patch,
> SENTRY-2422.001.patch, SENTRY-2422.001.patch, SENTRY-2422.002.patch,
> SENTRY-2422.003.patch
>
>
> When processing updates for the HMS notifications, multiple entries of the
> same ID are being put into the SENTRY_HMS_NOTIFICATION_ID table.
> This can be seen after doing a non location changing ALTER TABLE in hive for
> example.
>
> ALTER TABLE sometable SET TBLPROPERTIES ("someproperty"="somevalue");
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SENTRY-2422) HMS synchronization is causing multiple entries of the same ID in SENTRY_HMS_NOTIFICATION_ID
[
https://issues.apache.org/jira/browse/SENTRY-2422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17164674#comment-17164674
]
Hadoop QA commented on SENTRY-2422:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/13008373/SENTRY-2422.001.patch
against master.
{color:red}Overall:{color} -1 due to 9 errors
{color:red}ERROR:{color} mvn test exited 1
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hdfs.TestHDFSIntegrationWithHA
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestHmsNotificationProcessingWithOutHdfsSync
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestOwnerPrivilegesWithGrantOption
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestHmsNotificationProcessingWithOutSyncOnCreate
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hdfs.TestHDFSIntegrationEnd2End
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestHmsNotificationProcessingWithOutSyncOnDrop
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hdfs.TestHDFSIntegrationTogglingConf
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestOwnerPrivileges
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4484/console
This message is automatically generated.
> HMS synchronization is causing multiple entries of the same ID in
> SENTRY_HMS_NOTIFICATION_ID
>
>
> Key: SENTRY-2422
> URL: https://issues.apache.org/jira/browse/SENTRY-2422
> Project: Sentry
> Issue Type: Improvement
> Components: Core
>Affects Versions: 2.1.0, 2.0.1
>Reporter: Brian Towles
>Assignee: Na Li
>Priority: Major
> Attachments: SENTRY-2422.001.patch, SENTRY-2422.001.patch,
> SENTRY-2422.001.patch, SENTRY-2422.001.patch
>
>
> When processing updates for the HMS notifications, multiple entries of the
> same ID are being put into the SENTRY_HMS_NOTIFICATION_ID table.
> This can be seen after doing a non location changing ALTER TABLE in hive for
> example.
>
> ALTER TABLE sometable SET TBLPROPERTIES ("someproperty"="somevalue");
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SENTRY-2422) HMS synchronization is causing multiple entries of the same ID in SENTRY_HMS_NOTIFICATION_ID
[
https://issues.apache.org/jira/browse/SENTRY-2422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17164596#comment-17164596
]
Hadoop QA commented on SENTRY-2422:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/13008361/SENTRY-2422.001.patch
against master.
{color:red}Overall:{color} -1 due to 3 errors
{color:red}ERROR:{color} mvn test exited 1
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestHmsNotificationProcessingWithOutSyncOnDrop
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestHmsNotificationProcessing
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4483/console
This message is automatically generated.
> HMS synchronization is causing multiple entries of the same ID in
> SENTRY_HMS_NOTIFICATION_ID
>
>
> Key: SENTRY-2422
> URL: https://issues.apache.org/jira/browse/SENTRY-2422
> Project: Sentry
> Issue Type: Improvement
> Components: Core
>Affects Versions: 2.1.0, 2.0.1
>Reporter: Brian Towles
>Assignee: Na Li
>Priority: Major
> Attachments: SENTRY-2422.001.patch, SENTRY-2422.001.patch,
> SENTRY-2422.001.patch
>
>
> When processing updates for the HMS notifications, multiple entries of the
> same ID are being put into the SENTRY_HMS_NOTIFICATION_ID table.
> This can be seen after doing a non location changing ALTER TABLE in hive for
> example.
>
> ALTER TABLE sometable SET TBLPROPERTIES ("someproperty"="somevalue");
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SENTRY-2422) HMS synchronization is causing multiple entries of the same ID in SENTRY_HMS_NOTIFICATION_ID
[
https://issues.apache.org/jira/browse/SENTRY-2422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17164095#comment-17164095
]
Hadoop QA commented on SENTRY-2422:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/13008327/SENTRY-2422.001.patch
against master.
{color:red}Overall:{color} -1 due to 2 errors
{color:red}ERROR:{color} mvn test exited 1
{color:red}ERROR:{color} Failed:
org.apache.sentry.hdfs.TestSentryHDFSServiceProcessor
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4482/console
This message is automatically generated.
> HMS synchronization is causing multiple entries of the same ID in
> SENTRY_HMS_NOTIFICATION_ID
>
>
> Key: SENTRY-2422
> URL: https://issues.apache.org/jira/browse/SENTRY-2422
> Project: Sentry
> Issue Type: Improvement
> Components: Core
>Affects Versions: 2.1.0, 2.0.1
>Reporter: Brian Towles
>Assignee: Na Li
>Priority: Major
> Attachments: SENTRY-2422.001.patch, SENTRY-2422.001.patch
>
>
> When processing updates for the HMS notifications, multiple entries of the
> same ID are being put into the SENTRY_HMS_NOTIFICATION_ID table.
> This can be seen after doing a non location changing ALTER TABLE in hive for
> example.
>
> ALTER TABLE sometable SET TBLPROPERTIES ("someproperty"="somevalue");
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SENTRY-2557) Queries are running too slow after when there are more than 4k roles
[
https://issues.apache.org/jira/browse/SENTRY-2557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17163148#comment-17163148
]
Hadoop QA commented on SENTRY-2557:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/13008179/SENTRY-2557.01.patch
against master.
{color:green}Overall:{color} +1 all checks pass
{color:green}SUCCESS:{color} all tests passed
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4480/console
This message is automatically generated.
> Queries are running too slow after when there are more than 4k roles
>
>
> Key: SENTRY-2557
> URL: https://issues.apache.org/jira/browse/SENTRY-2557
> Project: Sentry
> Issue Type: Bug
> Components: sentrystore
>Affects Versions: 2.2.0, 2.3.0
>Reporter: Kalyan Kalvagadda
>Assignee: Kalyan Kalvagadda
>Priority: Critical
> Attachments: SENTRY-2557.01.patch
>
>
> When there are more than 4k roles Hive queries are very slow below because of
> the time it spends on the compile phase because of the delay in fetching the
> permissions.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SENTRY-2557) Queries are running too slow after when there are more than 4k roles
[
https://issues.apache.org/jira/browse/SENTRY-2557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17163022#comment-17163022
]
Hadoop QA commented on SENTRY-2557:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/13008179/SENTRY-2557.01.patch
against master.
{color:red}Overall:{color} -1 due to 4 errors
{color:red}ERROR:{color} mvn test exited 1
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hdfs.TestHDFSIntegrationWithHA
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hdfs.TestHDFSIntegrationWithHA
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hdfs.TestHDFSIntegrationWithHA
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4479/console
This message is automatically generated.
> Queries are running too slow after when there are more than 4k roles
>
>
> Key: SENTRY-2557
> URL: https://issues.apache.org/jira/browse/SENTRY-2557
> Project: Sentry
> Issue Type: Bug
> Components: sentrystore
>Affects Versions: 2.2.0, 2.3.0
>Reporter: Kalyan Kalvagadda
>Assignee: Kalyan Kalvagadda
>Priority: Critical
> Attachments: SENTRY-2557.01.patch
>
>
> When there are more than 4k roles Hive queries are very slow below because of
> the time it spends on the compile phase because of the delay in fetching the
> permissions.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SENTRY-2553) Auth path is not deleted in db after dropping table
[
https://issues.apache.org/jira/browse/SENTRY-2553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17062397#comment-17062397
]
Hadoop QA commented on SENTRY-2553:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12997096/SENTRY-2553.001.patch
against master.
{color:red}Overall:{color} -1 due to 2 errors
{color:red}ERROR:{color} mvn test exited 1
{color:red}ERROR:{color} Failed:
org.apache.sentry.provider.db.generic.service.persistent.TestPrivilegeOperatePersistence
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4478/console
This message is automatically generated.
> Auth path is not deleted in db after dropping table
> ---
>
> Key: SENTRY-2553
> URL: https://issues.apache.org/jira/browse/SENTRY-2553
> Project: Sentry
> Issue Type: Bug
> Components: Sentry, sentrystore
>Affects Versions: 2.2.0
>Reporter: ouchengeng
>Priority: Major
> Attachments: SENTRY-2553.001.patch
>
>
> SENTRY-2249 made pathsToPersist detached from MAuthzPathsMapping.
> So, deleting MAuthzPathsMapping object won't deleting paths in Mysql, and
> these paths are kept in Mysql as garbage. This happens when processing
> drop_table events.
> We need to delete pathsToPersist, before deleting a MAuthzPathsMapping object.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SENTRY-2550) Bump up the version of Guava to 28.1-jre
[
https://issues.apache.org/jira/browse/SENTRY-2550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17037360#comment-17037360
]
Hadoop QA commented on SENTRY-2550:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12993529/SENTRY-2550.001.patch
against master.
{color:red}Overall:{color} -1 due to an error
{color:red}ERROR:{color} failed to clean project (exit code 1)
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4477/console
This message is automatically generated.
> Bump up the version of Guava to 28.1-jre
>
>
> Key: SENTRY-2550
> URL: https://issues.apache.org/jira/browse/SENTRY-2550
> Project: Sentry
> Issue Type: Improvement
>Reporter: Fang-Yu Rao
>Assignee: Fang-Yu Rao
>Priority: Major
> Attachments: SENTRY-2550.001.patch
>
>
> Bump up the version of Guava to 28.1-jre from 14.0.1 due to a recent CVE
> report.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SENTRY-2549) Only groups but not users are passed to PrivilegeCache
[
https://issues.apache.org/jira/browse/SENTRY-2549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17023638#comment-17023638
]
Hadoop QA commented on SENTRY-2549:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12991834/SENTRY-2549.001.patch
against master.
{color:red}Overall:{color} -1 due to an error
{color:red}ERROR:{color} failed to clean project (exit code 1)
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4476/console
This message is automatically generated.
> Only groups but not users are passed to PrivilegeCache
> --
>
> Key: SENTRY-2549
> URL: https://issues.apache.org/jira/browse/SENTRY-2549
> Project: Sentry
> Issue Type: Bug
>Reporter: Csaba Ringhofer
>Assignee: Csaba Ringhofer
>Priority: Critical
> Attachments: SENTRY-2549.001.patch, SENTRY-2549.001.patch,
> SENTRY-2549.001.patch, SENTRY-2549.001.patch
>
>
> SENTRY-2539 introduced this issue, see line 83 of
> SimpleDBProviderBackend.java at
> https://github.com/apache/sentry/commit/843368fc2aeb154f9cf7b18d191c128644295ce5#diff-171087e076ec1622cb69536426d35b4a
> I guess that this means that privileges assigned to groups are respected, but
> user privileges are ignored. I think that this is the reason behind recent
> test failures in Apache Impala.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SENTRY-2549) Only groups but not users are passed to PrivilegeCache
[
https://issues.apache.org/jira/browse/SENTRY-2549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17022294#comment-17022294
]
Hadoop QA commented on SENTRY-2549:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12991684/SENTRY-2549.001.patch
against master.
{color:red}Overall:{color} -1 due to an error
{color:red}ERROR:{color} failed to clean project (exit code 1)
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4475/console
This message is automatically generated.
> Only groups but not users are passed to PrivilegeCache
> --
>
> Key: SENTRY-2549
> URL: https://issues.apache.org/jira/browse/SENTRY-2549
> Project: Sentry
> Issue Type: Bug
>Reporter: Csaba Ringhofer
>Priority: Critical
> Attachments: SENTRY-2549.001.patch, SENTRY-2549.001.patch,
> SENTRY-2549.001.patch
>
>
> SENTRY-2539 introduced this issue, see line 83 of
> SimpleDBProviderBackend.java at
> https://github.com/apache/sentry/commit/843368fc2aeb154f9cf7b18d191c128644295ce5#diff-171087e076ec1622cb69536426d35b4a
> I guess that this means that privileges assigned to groups are respected, but
> user privileges are ignored. I think that this is the reason behind recent
> test failures in Apache Impala.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SENTRY-2549) Only groups but not users are passed to PrivilegeCache
[
https://issues.apache.org/jira/browse/SENTRY-2549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17022253#comment-17022253
]
Hadoop QA commented on SENTRY-2549:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12991674/SENTRY-2549.001.patch
against master.
{color:red}Overall:{color} -1 due to an error
{color:red}ERROR:{color} failed to clean project (exit code 1)
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4474/console
This message is automatically generated.
> Only groups but not users are passed to PrivilegeCache
> --
>
> Key: SENTRY-2549
> URL: https://issues.apache.org/jira/browse/SENTRY-2549
> Project: Sentry
> Issue Type: Bug
>Reporter: Csaba Ringhofer
>Priority: Critical
> Attachments: SENTRY-2549.001.patch, SENTRY-2549.001.patch
>
>
> SENTRY-2539 introduced this issue, see line 83 of
> SimpleDBProviderBackend.java at
> https://github.com/apache/sentry/commit/843368fc2aeb154f9cf7b18d191c128644295ce5#diff-171087e076ec1622cb69536426d35b4a
> I guess that this means that privileges assigned to groups are respected, but
> user privileges are ignored. I think that this is the reason behind recent
> test failures in Apache Impala.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SENTRY-2549) Only groups but not users are passed to PrivilegeCache
[
https://issues.apache.org/jira/browse/SENTRY-2549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17022184#comment-17022184
]
Hadoop QA commented on SENTRY-2549:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12991669/SENTRY-2549.001.patch
against master.
{color:red}Overall:{color} -1 due to an error
{color:red}ERROR:{color} failed to clean project (exit code 1)
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4473/console
This message is automatically generated.
> Only groups but not users are passed to PrivilegeCache
> --
>
> Key: SENTRY-2549
> URL: https://issues.apache.org/jira/browse/SENTRY-2549
> Project: Sentry
> Issue Type: Bug
>Reporter: Csaba Ringhofer
>Priority: Critical
> Attachments: SENTRY-2549.001.patch
>
>
> SENTRY-2539 introduced this issue, see line 83 of
> SimpleDBProviderBackend.java at
> https://github.com/apache/sentry/commit/843368fc2aeb154f9cf7b18d191c128644295ce5#diff-171087e076ec1622cb69536426d35b4a
> I guess that this means that privileges assigned to groups are respected, but
> user privileges are ignored. I think that this is the reason behind recent
> test failures in Apache Impala.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SENTRY-2462) Seperate Metrics into sub module in order to remove circular dependencies
[
https://issues.apache.org/jira/browse/SENTRY-2462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17006963#comment-17006963
]
Hadoop QA commented on SENTRY-2462:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12948875/SENTRY-2462.001.patch
against master.
{color:red}Overall:{color} -1 due to an error
{color:red}ERROR:{color} failed to apply patch (exit code 1):
error: git apply: bad git-diff - inconsistent old filename on line 891
error: patch failed: sentry-dist/src/license/THIRD-PARTY.properties:8
Falling back to three-way merge...
Applied patch to 'sentry-dist/src/license/THIRD-PARTY.properties' with
conflicts.
error: patch failed: sentry-dist/src/main/assembly/bin.xml:49
error: repository lacks the necessary blob to fall back on 3-way merge.
error: sentry-dist/src/main/assembly/bin.xml: patch does not apply
error: patch failed:
sentry-service/sentry-service-server/src/main/java/org/apache/sentry/api/service/thrift/SentryMetrics.java:35
Falling back to three-way merge...
Applied patch to
'sentry-service/sentry-service-metrics/src/main/java/org/apache/sentry/service/metrics/SentryMetrics.java'
with conflicts.
error: patch failed:
sentry-service/sentry-service-server/src/main/java/org/apache/sentry/api/service/thrift/SentryPolicyStoreProcessor.java:31
Falling back to three-way merge...
Applied patch to
'sentry-service/sentry-service-server/src/main/java/org/apache/sentry/api/service/thrift/SentryPolicyStoreProcessor.java'
with conflicts.
error: patch failed:
sentry-service/sentry-service-server/src/main/java/org/apache/sentry/api/service/thrift/SentryServiceWebServiceProvider.java:19
error: repository lacks the necessary blob to fall back on 3-way merge.
error:
sentry-service/sentry-service-server/src/main/java/org/apache/sentry/api/service/thrift/SentryServiceWebServiceProvider.java:
patch does not apply
error: patch failed:
sentry-service/sentry-service-server/src/main/java/org/apache/sentry/service/thrift/FullUpdateInitializer.java:17
Falling back to three-way merge...
Applied patch to
'sentry-service/sentry-service-server/src/main/java/org/apache/sentry/service/thrift/FullUpdateInitializer.java'
with conflicts.
error: patch failed:
sentry-service/sentry-service-server/src/main/java/org/apache/sentry/service/thrift/SentryHMSClient.java:18
Falling back to three-way merge...
Applied patch to
'sentry-service/sentry-service-server/src/main/java/org/apache/sentry/service/thrift/SentryHMSClient.java'
with conflicts.
error: patch failed:
sentry-service/sentry-service-server/src/test/java/org/apache/sentry/api/service/thrift/TestSentryPolicyStoreProcessor.java:23
Falling back to three-way merge...
Applied patch to
'sentry-service/sentry-service-server/src/test/java/org/apache/sentry/api/service/thrift/TestSentryPolicyStoreProcessor.java'
cleanly.
error: patch failed: sentry-thirdparty/pom.xml:1
error: sentry-thirdparty/pom.xml: patch does not apply
error: patch failed: sentry-thirdparty/sentry-shaded/pom.xml:1
error: sentry-thirdparty/sentry-shaded/pom.xml: patch does not apply
error: git diff header lacks filename information when removing 2 leading
pathname components (line 5)
The patch does not appear to apply with p0, p1, or p2
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4472/console
This message is automatically generated.
> Seperate Metrics into sub module in order to remove circular dependencies
> -
>
> Key: SENTRY-2462
> URL: https://issues.apache.org/jira/browse/SENTRY-2462
> Project: Sentry
> Issue Type: Improvement
> Components: Service
>Affects Versions: 2.0.1
>Reporter: Brian Towles
>Assignee: Brian Towles
>Priority: Major
> Fix For: 2.3.0
>
> Attachments: SENTRY-2462.001.patch
>
>
> The metrics subsystem currently resides in the sentry-service-server. So any
> other module that needs to use it has to depend on sentry-service-server
> which is causing circular dependencies when trying to add modules used by
> sentry-service-server.
>
> This will create a sentry-service-metrics that will house and wrap all the
> metrics needs for the server. It will need to use SENTRY-2458 as a base to
> segment out the web presentation components of the metrics. It will also
> allow for the centralization of the roll up and shading of the codehale
> metrics package to happen in one sub module rather then split over two.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SENTRY-2545) Rolling back Privilege Cache to SimplePrivilegeCache does not work
[
https://issues.apache.org/jira/browse/SENTRY-2545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17004719#comment-17004719
]
Hadoop QA commented on SENTRY-2545:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12989626/SENTRY-2545.002.patch
against master.
{color:green}Overall:{color} +1 all checks pass
{color:green}SUCCESS:{color} all tests passed
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4471/console
This message is automatically generated.
> Rolling back Privilege Cache to SimplePrivilegeCache does not work
> --
>
> Key: SENTRY-2545
> URL: https://issues.apache.org/jira/browse/SENTRY-2545
> Project: Sentry
> Issue Type: Bug
> Components: Sentry
>Affects Versions: 2.1
>Reporter: Na Li
>Assignee: Na Li
>Priority: Major
> Attachments: SENTRY-2545.001.patch, SENTRY-2545.002.patch
>
>
> The change in SENTRY-2539 uses TreePrivilegeCache as default implementation
> of privilege cache to improve authorization performance. However, rolling
> back to SimplePrivilegeCache does not work due to how Sentry creates the
> privilege cache.
> The solution is to create the privilege cache based on configured class name
> and handle different constructor inputs properly.
> More test cases are added to verify that rollback works.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SENTRY-2545) Rolling back Privilege Cache to SimplePrivilegeCache does not work
[
https://issues.apache.org/jira/browse/SENTRY-2545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17004645#comment-17004645
]
Hadoop QA commented on SENTRY-2545:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12989624/SENTRY-2545.001.patch
against master.
{color:red}Overall:{color} -1 due to an error
{color:red}ERROR:{color} failed to build with patch (exit code 1)
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4470/console
This message is automatically generated.
> Rolling back Privilege Cache to SimplePrivilegeCache does not work
> --
>
> Key: SENTRY-2545
> URL: https://issues.apache.org/jira/browse/SENTRY-2545
> Project: Sentry
> Issue Type: Bug
> Components: Sentry
>Affects Versions: 2.1
>Reporter: Na Li
>Assignee: Na Li
>Priority: Major
> Attachments: SENTRY-2545.001.patch, SENTRY-2545.002.patch
>
>
> The change in SENTRY-2539 uses TreePrivilegeCache as default implementation
> of privilege cache to improve authorization performance. However, rolling
> back to SimplePrivilegeCache does not work due to how Sentry creates the
> privilege cache.
> The solution is to create the privilege cache based on configured class name
> and handle different constructor inputs properly.
> More test cases are added to verify that rollback works.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SENTRY-2539) PolicyEngine should be able to return privilege directly
[
https://issues.apache.org/jira/browse/SENTRY-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17001966#comment-17001966
]
Hadoop QA commented on SENTRY-2539:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12989343/SENTRY-2539.013.patch
against master.
{color:red}Overall:{color} -1 due to 4 errors
{color:red}ERROR:{color} mvn test exited 1
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hdfs.TestHDFSIntegrationWithHA
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hdfs.TestHDFSIntegrationWithHA
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hdfs.TestHDFSIntegrationWithHA
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4468/console
This message is automatically generated.
> PolicyEngine should be able to return privilege directly
> -
>
> Key: SENTRY-2539
> URL: https://issues.apache.org/jira/browse/SENTRY-2539
> Project: Sentry
> Issue Type: Improvement
> Components: Sentry
>Affects Versions: 2.1
>Reporter: Na Li
>Assignee: Na Li
>Priority: Major
> Attachments: SENTRY-2539.002.patch, SENTRY-2539.003.patch,
> SENTRY-2539.005.patch, SENTRY-2539.006.patch, SENTRY-2539.007.patch,
> SENTRY-2539.008.patch, SENTRY-2539.008.patch, SENTRY-2539.008.patch,
> SENTRY-2539.009.patch, SENTRY-2539.010.patch, SENTRY-2539.010.patch,
> SENTRY-2539.013.patch, SENTRY-2539.013.patch, SENTRY-2539.013.patch,
> SENTRY-2539.013.patch
>
>
> *Problem*:
> Right now, for a command such "show databases", Sentry has to perform
> authorization checks on each database. When there are many databases, like
> 12000 databases in the system, the authorization checks of a single command
> in Sentry could be very slow. There are two main factors that slow down
> authorization checks in Sentry even when caching is enabled:
> 1) Cache returns the list of privileges in the form of String. As a result,
> every authorization check has to convert the privilege string to privilege
> object.
> 2) When cache is enabled, the cache returns all privileges of a given user
> regardless what resource to check.
> 2.1) for example, a user has 2000 privileges assigned and the resource to
> check is "server=server1, database=db_1, table=table_1". The cache returns
> all 2000 privileges including unrelated privileges such like
> "server=server1->database=db_2->action=ALL".
> 2.2) Returning unrelated privileges has two side effects:
> 2.2.1) Converting privileges from String to Object overhead is
> proportional to the number of returned privileges from cache. Converting
> unrelated privileges cost time, but no benefit.
> 2.2.2) Authorization check goes through each privilege, and its overhead
> is proportional to the number of returned privileges from cache. Converting
> unrelated privileges cost time, but no benefit.
> *Solution*:
> 1) Add a new function listPrivilegeObjects that lets authorization provider
> get privilege objects when checking the authorization. This avoids the
> conversion overhead. All the interfaces from policy engine (PolicyEngine) to
> the cache (PrivilegeCache) have to be changed to add this new function.
> 2) Implement a new cache TreePrivilegeCache. It converts the privilege from
> String format to Privilege object at beginning, and directly return the
> privilege objects in listPrivilegeObjects at authorization check. This avoids
> the overhead of conversion at each authorization check.
> 3) TreePrivilegeCache organizes the privileges based on the resource
> hierarchy, like a tree. Therefore, it can return only related privileges
> based on the resource to check. This reduces the authorization check
> overhead.
> 3.1) For example, a user has 2000 privileges assigned, and the resource to
> check is "server=server1, database=db_1, table=table_1". the cache
> TreePrivilegeCache returns only related privileges excluding unrelated
> privileges such like "server=server1->database=db_2->action=ALL".
> 3.2) SENTRY-1291 was to address the problem 2). However, it did not address
> the problem 1). And its implementation SimplePrivilegeCache is not memory
> efficient (the key of the map contains the whole resource hierarchy, and many
> keys share large portion of the same content), nor operational efficient (for
> each authorization check, SimplePrivilegeCache .listPrivileges() has to
> construct a large amount of keys in order to find all related privileges in a
> map).
> 4) Use TreePrivilegeCache instead of SimplePrivilegeCache for caching. Note,
> this solution is built on top of SENTRY-1291, and utilizes the changes
> SENTRY-1291 made, such as providing resource hierarchy when getting
> privileges for authorization check.
>
[jira] [Commented] (SENTRY-2539) PolicyEngine should be able to return privilege directly
[
https://issues.apache.org/jira/browse/SENTRY-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17001871#comment-17001871
]
Hadoop QA commented on SENTRY-2539:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12989336/SENTRY-2539.013.patch
against master.
{color:red}Overall:{color} -1 due to 4 errors
{color:red}ERROR:{color} mvn test exited 1
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hdfs.TestHDFSIntegrationWithHA
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hdfs.TestHDFSIntegrationWithHA
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hdfs.TestHDFSIntegrationWithHA
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4466/console
This message is automatically generated.
> PolicyEngine should be able to return privilege directly
> -
>
> Key: SENTRY-2539
> URL: https://issues.apache.org/jira/browse/SENTRY-2539
> Project: Sentry
> Issue Type: Improvement
> Components: Sentry
>Affects Versions: 2.1
>Reporter: Na Li
>Assignee: Na Li
>Priority: Major
> Attachments: SENTRY-2539.002.patch, SENTRY-2539.003.patch,
> SENTRY-2539.005.patch, SENTRY-2539.006.patch, SENTRY-2539.007.patch,
> SENTRY-2539.008.patch, SENTRY-2539.008.patch, SENTRY-2539.008.patch,
> SENTRY-2539.009.patch, SENTRY-2539.010.patch, SENTRY-2539.010.patch,
> SENTRY-2539.013.patch, SENTRY-2539.013.patch
>
>
> *Problem*:
> Right now, for a command such "show databases", Sentry has to perform
> authorization checks on each database. When there are many databases, like
> 12000 databases in the system, the authorization checks of a single command
> in Sentry could be very slow. There are two main factors that slow down
> authorization checks in Sentry even when caching is enabled:
> 1) Cache returns the list of privileges in the form of String. As a result,
> every authorization check has to convert the privilege string to privilege
> object.
> 2) When cache is enabled, the cache returns all privileges of a given user
> regardless what resource to check.
> 2.1) for example, a user has 2000 privileges assigned and the resource to
> check is "server=server1, database=db_1, table=table_1". The cache returns
> all 2000 privileges including unrelated privileges such like
> "server=server1->database=db_2->action=ALL".
> 2.2) Returning unrelated privileges has two side effects:
> 2.2.1) Converting privileges from String to Object overhead is
> proportional to the number of returned privileges from cache. Converting
> unrelated privileges cost time, but no benefit.
> 2.2.2) Authorization check goes through each privilege, and its overhead
> is proportional to the number of returned privileges from cache. Converting
> unrelated privileges cost time, but no benefit.
> *Solution*:
> 1) Add a new function listPrivilegeObjects that lets authorization provider
> get privilege objects when checking the authorization. This avoids the
> conversion overhead. All the interfaces from policy engine (PolicyEngine) to
> the cache (PrivilegeCache) have to be changed to add this new function.
> 2) Implement a new cache TreePrivilegeCache. It converts the privilege from
> String format to Privilege object at beginning, and directly return the
> privilege objects in listPrivilegeObjects at authorization check. This avoids
> the overhead of conversion at each authorization check.
> 3) TreePrivilegeCache organizes the privileges based on the resource
> hierarchy, like a tree. Therefore, it can return only related privileges
> based on the resource to check. This reduces the authorization check
> overhead.
> 3.1) For example, a user has 2000 privileges assigned, and the resource to
> check is "server=server1, database=db_1, table=table_1". the cache
> TreePrivilegeCache returns only related privileges excluding unrelated
> privileges such like "server=server1->database=db_2->action=ALL".
> 3.2) SENTRY-1291 was to address the problem 2). However, it did not address
> the problem 1). And its implementation SimplePrivilegeCache is not memory
> efficient (the key of the map contains the whole resource hierarchy, and many
> keys share large portion of the same content), nor operational efficient (for
> each authorization check, SimplePrivilegeCache .listPrivileges() has to
> construct a large amount of keys in order to find all related privileges in a
> map).
> 4) Use TreePrivilegeCache instead of SimplePrivilegeCache for caching. Note,
> this solution is built on top of SENTRY-1291, and utilizes the changes
> SENTRY-1291 made, such as providing resource hierarchy when getting
> privileges for authorization check.
>
> *Major Behavior Change*
> 1) Create a new
[jira] [Commented] (SENTRY-2539) PolicyEngine should be able to return privilege directly
[
https://issues.apache.org/jira/browse/SENTRY-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17001313#comment-17001313
]
Hadoop QA commented on SENTRY-2539:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12989294/SENTRY-2539.010.patch
against master.
{color:green}Overall:{color} +1 all checks pass
{color:green}SUCCESS:{color} all tests passed
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4464/console
This message is automatically generated.
> PolicyEngine should be able to return privilege directly
> -
>
> Key: SENTRY-2539
> URL: https://issues.apache.org/jira/browse/SENTRY-2539
> Project: Sentry
> Issue Type: Improvement
> Components: Sentry
>Affects Versions: 2.1
>Reporter: Na Li
>Assignee: Na Li
>Priority: Major
> Attachments: SENTRY-2539.002.patch, SENTRY-2539.003.patch,
> SENTRY-2539.005.patch, SENTRY-2539.006.patch, SENTRY-2539.007.patch,
> SENTRY-2539.008.patch, SENTRY-2539.008.patch, SENTRY-2539.008.patch,
> SENTRY-2539.009.patch, SENTRY-2539.010.patch, SENTRY-2539.010.patch
>
>
> *Problem*:
> Right now, for a command such "show databases", Sentry has to perform
> authorization checks on each database. When there are many databases, like
> 12000 databases in the system, the authorization checks of a single command
> in Sentry could be very slow. There are two main factors that slow down
> authorization checks in Sentry even when caching is enabled:
> 1) Cache returns the list of privileges in the form of String. As a result,
> every authorization check has to convert the privilege string to privilege
> object.
> 2) When cache is enabled, the cache returns all privileges of a given user
> regardless what resource to check.
> 2.1) for example, a user has 2000 privileges assigned and the resource to
> check is "server=server1, database=db_1, table=table_1". The cache returns
> all 2000 privileges including unrelated privileges such like
> "server=server1->database=db_2->action=ALL".
> 2.2) Returning unrelated privileges has two side effects:
> 2.2.1) Converting privileges from String to Object overhead is
> proportional to the number of returned privileges from cache. Converting
> unrelated privileges cost time, but no benefit.
> 2.2.2) Authorization check goes through each privilege, and its overhead
> is proportional to the number of returned privileges from cache. Converting
> unrelated privileges cost time, but no benefit.
> *Solution*:
> 1) Add a new function listPrivilegeObjects that lets authorization provider
> get privilege objects when checking the authorization. This avoids the
> conversion overhead. All the interfaces from policy engine (PolicyEngine) to
> the cache (PrivilegeCache) have to be changed to add this new function.
> 2) Implement a new cache TreePrivilegeCache. It converts the privilege from
> String format to Privilege object at beginning, and directly return the
> privilege objects in listPrivilegeObjects at authorization check. This avoids
> the overhead of conversion at each authorization check.
> 3) TreePrivilegeCache organizes the privileges based on the resource
> hierarchy, like a tree. Therefore, it can return only related privileges
> based on the resource to check. This reduces the authorization check
> overhead.
> 3.1) For example, a user has 2000 privileges assigned, and the resource to
> check is "server=server1, database=db_1, table=table_1". the cache
> TreePrivilegeCache returns only related privileges excluding unrelated
> privileges such like "server=server1->database=db_2->action=ALL".
> 3.2) SENTRY-1291 was to address the problem 2). However, it did not address
> the problem 1). And its implementation SimplePrivilegeCache is not memory
> efficient (the key of the map contains the whole resource hierarchy, and many
> keys share large portion of the same content), nor operational efficient (for
> each authorization check, SimplePrivilegeCache .listPrivileges() has to
> construct a large amount of keys in order to find all related privileges in a
> map).
> 4) Use TreePrivilegeCache instead of SimplePrivilegeCache for caching. Note,
> this solution is built on top of SENTRY-1291, and utilizes the changes
> SENTRY-1291 made, such as providing resource hierarchy when getting
> privileges for authorization check.
>
> *Major Behavior Change*
> 1) Create a new Interface FilteredPrivilegeCache, which extends from
> PrivilegeCache.
> 2) Move the function added by SENTRY-1291 in PrivilegeCache to
> FilteredPrivilegeCache. Add additional functions in this solution to
> FilteredPrivilegeCache. In this way, there is no change in PrivilegeCache,
> and we are backward compatible with
[jira] [Commented] (SENTRY-2539) PolicyEngine should be able to return privilege directly
[
https://issues.apache.org/jira/browse/SENTRY-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17001309#comment-17001309
]
Hadoop QA commented on SENTRY-2539:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12989299/SENTRY-2539.010.patch
against master.
{color:green}Overall:{color} +1 all checks pass
{color:green}SUCCESS:{color} all tests passed
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4465/console
This message is automatically generated.
> PolicyEngine should be able to return privilege directly
> -
>
> Key: SENTRY-2539
> URL: https://issues.apache.org/jira/browse/SENTRY-2539
> Project: Sentry
> Issue Type: Improvement
> Components: Sentry
>Affects Versions: 2.1
>Reporter: Na Li
>Assignee: Na Li
>Priority: Major
> Attachments: SENTRY-2539.002.patch, SENTRY-2539.003.patch,
> SENTRY-2539.005.patch, SENTRY-2539.006.patch, SENTRY-2539.007.patch,
> SENTRY-2539.008.patch, SENTRY-2539.008.patch, SENTRY-2539.008.patch,
> SENTRY-2539.009.patch, SENTRY-2539.010.patch, SENTRY-2539.010.patch
>
>
> *Problem*:
> Right now, for a command such "show databases", Sentry has to perform
> authorization checks on each database. When there are many databases, like
> 12000 databases in the system, the authorization checks of a single command
> in Sentry could be very slow. There are two main factors that slow down
> authorization checks in Sentry even when caching is enabled:
> 1) Cache returns the list of privileges in the form of String. As a result,
> every authorization check has to convert the privilege string to privilege
> object.
> 2) When cache is enabled, the cache returns all privileges of a given user
> regardless what resource to check.
> 2.1) for example, a user has 2000 privileges assigned and the resource to
> check is "server=server1, database=db_1, table=table_1". The cache returns
> all 2000 privileges including unrelated privileges such like
> "server=server1->database=db_2->action=ALL".
> 2.2) Returning unrelated privileges has two side effects:
> 2.2.1) Converting privileges from String to Object overhead is
> proportional to the number of returned privileges from cache. Converting
> unrelated privileges cost time, but no benefit.
> 2.2.2) Authorization check goes through each privilege, and its overhead
> is proportional to the number of returned privileges from cache. Converting
> unrelated privileges cost time, but no benefit.
> *Solution*:
> 1) Add a new function listPrivilegeObjects that lets authorization provider
> get privilege objects when checking the authorization. This avoids the
> conversion overhead. All the interfaces from policy engine (PolicyEngine) to
> the cache (PrivilegeCache) have to be changed to add this new function.
> 2) Implement a new cache TreePrivilegeCache. It converts the privilege from
> String format to Privilege object at beginning, and directly return the
> privilege objects in listPrivilegeObjects at authorization check. This avoids
> the overhead of conversion at each authorization check.
> 3) TreePrivilegeCache organizes the privileges based on the resource
> hierarchy, like a tree. Therefore, it can return only related privileges
> based on the resource to check. This reduces the authorization check
> overhead.
> 3.1) For example, a user has 2000 privileges assigned, and the resource to
> check is "server=server1, database=db_1, table=table_1". the cache
> TreePrivilegeCache returns only related privileges excluding unrelated
> privileges such like "server=server1->database=db_2->action=ALL".
> 3.2) SENTRY-1291 was to address the problem 2). However, it did not address
> the problem 1). And its implementation SimplePrivilegeCache is not memory
> efficient (the key of the map contains the whole resource hierarchy, and many
> keys share large portion of the same content), nor operational efficient (for
> each authorization check, SimplePrivilegeCache .listPrivileges() has to
> construct a large amount of keys in order to find all related privileges in a
> map).
> 4) Use TreePrivilegeCache instead of SimplePrivilegeCache for caching. Note,
> this solution is built on top of SENTRY-1291, and utilizes the changes
> SENTRY-1291 made, such as providing resource hierarchy when getting
> privileges for authorization check.
>
> *Major Behavior Change*
> 1) Create a new Interface FilteredPrivilegeCache, which extends from
> PrivilegeCache.
> 2) Move the function added by SENTRY-1291 in PrivilegeCache to
> FilteredPrivilegeCache. Add additional functions in this solution to
> FilteredPrivilegeCache. In this way, there is no change in PrivilegeCache,
> and we are backward compatible with
[jira] [Commented] (SENTRY-2539) PolicyEngine should be able to return privilege directly
[
https://issues.apache.org/jira/browse/SENTRY-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999598#comment-16999598
]
Hadoop QA commented on SENTRY-2539:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12989137/SENTRY-2539.008.patch
against master.
{color:red}Overall:{color} -1 due to 3 errors
{color:red}ERROR:{color} mvn test exited 1
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestOwnerPrivileges
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestOwnerPrivilegesWithGrantOption
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4461/console
This message is automatically generated.
> PolicyEngine should be able to return privilege directly
> -
>
> Key: SENTRY-2539
> URL: https://issues.apache.org/jira/browse/SENTRY-2539
> Project: Sentry
> Issue Type: Improvement
> Components: Sentry
>Affects Versions: 2.1
>Reporter: Na Li
>Assignee: Na Li
>Priority: Major
> Attachments: SENTRY-2539.002.patch, SENTRY-2539.003.patch,
> SENTRY-2539.005.patch, SENTRY-2539.006.patch, SENTRY-2539.007.patch,
> SENTRY-2539.008.patch, SENTRY-2539.008.patch, SENTRY-2539.008.patch
>
>
> *Problem*:
> Right now, for a command such "show databases", Sentry has to perform
> authorization checks on each database. When there are many databases, like
> 12000 databases in the system, the authorization checks of a single command
> in Sentry could be very slow. There are two main factors that slow down
> authorization checks in Sentry even when caching is enabled:
> 1) Cache returns the list of privileges in the form of String. As a result,
> every authorization check has to convert the privilege string to privilege
> object.
> 2) When cache is enabled, the cache returns all privileges of a given user
> regardless what resource to check.
> 2.1) for example, a user has 2000 privileges assigned and the resource to
> check is "server=server1, database=db_1, table=table_1". The cache returns
> all 2000 privileges including unrelated privileges such like
> "server=server1->database=db_2->action=ALL".
> 2.2) Returning unrelated privileges has two side effects:
> 2.2.1) Converting privileges from String to Object overhead is
> proportional to the number of returned privileges from cache. Converting
> unrelated privileges cost time, but no benefit.
> 2.2.2) Authorization check goes through each privilege, and its overhead
> is proportional to the number of returned privileges from cache. Converting
> unrelated privileges cost time, but no benefit.
> *Solution*:
> 1) Add a new function listPrivilegeObjects that lets authorization provider
> get privilege objects when checking the authorization. This avoids the
> conversion overhead. All the interfaces from policy engine (PolicyEngine) to
> the cache (PrivilegeCache) have to be changed to add this new function.
> 2) Implement a new cache TreePrivilegeCache. It converts the privilege from
> String format to Privilege object at beginning, and directly return the
> privilege objects in listPrivilegeObjects at authorization check. This avoids
> the overhead of conversion at each authorization check.
> 3) TreePrivilegeCache organizes the privileges based on the resource
> hierarchy, like a tree. Therefore, it can return only related privileges
> based on the resource to check. This reduces the authorization check
> overhead.
> 3.1) For example, a user has 2000 privileges assigned, and the resource to
> check is "server=server1, database=db_1, table=table_1". the cache
> TreePrivilegeCache returns only related privileges excluding unrelated
> privileges such like "server=server1->database=db_2->action=ALL".
> 3.2) SENTRY-1291 was to address the problem 2). However, it did not address
> the problem 1). And its implementation SimplePrivilegeCache is not memory
> efficient (the key of the map contains the whole resource hierarchy, and many
> keys share large portion of the same content), nor operational efficient (for
> each authorization check, SimplePrivilegeCache .listPrivileges() has to
> construct a large amount of keys in order to find all related privileges in a
> map).
> 4) Use TreePrivilegeCache instead of SimplePrivilegeCache for caching. Note,
> this solution is built on top of SENTRY-1291, and utilizes the changes
> SENTRY-1291 made, such as providing resource hierarchy when getting
> privileges for authorization check.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SENTRY-2539) PolicyEngine should be able to return privilege directly
[
https://issues.apache.org/jira/browse/SENTRY-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999462#comment-16999462
]
Hadoop QA commented on SENTRY-2539:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12989127/SENTRY-2539.008.patch
against master.
{color:red}Overall:{color} -1 due to 2 errors
{color:red}ERROR:{color} mvn test exited 1
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hdfs.TestHDFSIntegrationWithHA
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4460/console
This message is automatically generated.
> PolicyEngine should be able to return privilege directly
> -
>
> Key: SENTRY-2539
> URL: https://issues.apache.org/jira/browse/SENTRY-2539
> Project: Sentry
> Issue Type: Improvement
> Components: Sentry
>Affects Versions: 2.1
>Reporter: Na Li
>Assignee: Na Li
>Priority: Major
> Attachments: SENTRY-2539.002.patch, SENTRY-2539.003.patch,
> SENTRY-2539.005.patch, SENTRY-2539.006.patch, SENTRY-2539.007.patch,
> SENTRY-2539.008.patch
>
>
> Right now, the PolicyEngine Interface only returns the list of privileges in
> the form of String. As a result, every authorization check has to convert the
> privilege string to privilege object even though the cached privilege objects
> are of the correct type already.
> We should add a new function that returns privilege object directly to avoid
> the overhead of conversion.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SENTRY-2539) PolicyEngine should be able to return privilege directly
[
https://issues.apache.org/jira/browse/SENTRY-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16998838#comment-16998838
]
Hadoop QA commented on SENTRY-2539:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12989068/SENTRY-2539.007.patch
against master.
{color:red}Overall:{color} -1 due to 41 errors
{color:red}ERROR:{color} mvn test exited 1
{color:red}ERROR:{color} Failed:
org.apache.sentry.policy.hive.TestDBModelAuthorizables
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.sqoop.TestLinkEndToEnd
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.sqoop.TestLinkEndToEnd
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.sqoop.TestLinkEndToEnd
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.sqoop.TestLinkEndToEnd
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.sqoop.TestOwnerPrivilege
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.sqoop.TestOwnerPrivilege
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.sqoop.TestOwnerPrivilege
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.sqoop.TestConnectorEndToEnd
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.sqoop.TestConnectorEndToEnd
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.sqoop.TestServerScopeEndToEnd
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.sqoop.TestServerScopeEndToEnd
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.sqoop.TestJobEndToEnd
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.sqoop.TestJobEndToEnd
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.sqoop.TestJobEndToEnd
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.sqoop.TestJobEndToEnd
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.solr.TestSubsetQueryOperations
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.solr.TestSubsetQueryOperations
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.solr.TestSubsetQueryOperations
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.solr.TestSubsetQueryOperations
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.solr.TestSubsetQueryOperations
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.solr.TestSolrCollectionOperations
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.solr.TestSolrCollectionOperations
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.solr.TestSolrAdminOperations
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.solr.TestSolrAdminOperations
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.solr.TestSolrAdminOperations
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.solr.TestSolrAdminOperations
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.solr.TestSolrSchemaOperations
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.solr.TestAbacOperations
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.solr.TestAbacOperations
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.solr.TestAbacOperations
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.solr.TestAbacOperations
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.solr.TestAbacOperations
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.solr.TestAbacOperations
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.solr.TestDocLevelOperations
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.solr.TestDocLevelOperations
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.solr.TestDocLevelOperations
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.solr.TestDocLevelOperations
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.solr.TestSolrConfigOperations
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.solr.TestSolrConfigOperations
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4459/console
This message is automatically generated.
> PolicyEngine should be able to return privilege directly
> -
>
> Key: SENTRY-2539
> URL: https://issues.apache.org/jira/browse/SENTRY-2539
> Project: Sentry
> Issue Type: Improvement
> Components: Sentry
>Affects Versions: 2.1
>Reporter: Na Li
>Assignee: Na Li
>Priority: Major
> Attachments: SENTRY-2539.002.patch, SENTRY-2539.003.patch,
> SENTRY-2539.005.patch, SENTRY-2539.006.patch, SENTRY-2539.007.patch
>
>
> Right now, the PolicyEngine Interface only returns the list of privileges in
> the form of String. As a result, every authorization check has to convert the
> privilege string to privilege object even though the cached privilege objects
> are
[jira] [Commented] (SENTRY-2539) PolicyEngine should be able to return privilege directly
[
https://issues.apache.org/jira/browse/SENTRY-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16998634#comment-16998634
]
Hadoop QA commented on SENTRY-2539:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12989045/SENTRY-2539.006.patch
against master.
{color:red}Overall:{color} -1 due to an error
{color:red}ERROR:{color} failed to build with patch (exit code 1)
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4458/console
This message is automatically generated.
> PolicyEngine should be able to return privilege directly
> -
>
> Key: SENTRY-2539
> URL: https://issues.apache.org/jira/browse/SENTRY-2539
> Project: Sentry
> Issue Type: Improvement
> Components: Sentry
>Affects Versions: 2.1
>Reporter: Na Li
>Assignee: Na Li
>Priority: Major
> Attachments: SENTRY-2539.002.patch, SENTRY-2539.003.patch,
> SENTRY-2539.005.patch, SENTRY-2539.006.patch
>
>
> Right now, the PolicyEngine Interface only returns the list of privileges in
> the form of String. As a result, every authorization check has to convert the
> privilege string to privilege object even though the cached privilege objects
> are of the correct type already.
> We should add a new function that returns privilege object directly to avoid
> the overhead of conversion.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SENTRY-2539) PolicyEngine should be able to return privilege directly
[
https://issues.apache.org/jira/browse/SENTRY-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16997871#comment-16997871
]
Hadoop QA commented on SENTRY-2539:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12988958/SENTRY-2539.003.patch
against master.
{color:red}Overall:{color} -1 due to 5 errors
{color:red}ERROR:{color} mvn test exited 1
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.metastore.TestMetastoreEndToEnd
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.metastore.TestMetastoreEndToEnd
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestDbSandboxOps
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestDbSandboxOps
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4456/console
This message is automatically generated.
> PolicyEngine should be able to return privilege directly
> -
>
> Key: SENTRY-2539
> URL: https://issues.apache.org/jira/browse/SENTRY-2539
> Project: Sentry
> Issue Type: Improvement
> Components: Sentry
>Affects Versions: 2.1
>Reporter: Na Li
>Assignee: Na Li
>Priority: Major
> Attachments: SENTRY-2539.002.patch, SENTRY-2539.003.patch,
> SENTRY-2539.005.patch
>
>
> Right now, the PolicyEngine Interface only returns the list of privileges in
> the form of String. As a result, every authorization check has to convert the
> privilege string to privilege object even though the cached privilege objects
> are of the correct type already.
> We should add a new function that returns privilege object directly to avoid
> the overhead of conversion.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SENTRY-2539) PolicyEngine should be able to return privilege directly
[
https://issues.apache.org/jira/browse/SENTRY-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16996751#comment-16996751
]
Hadoop QA commented on SENTRY-2539:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/1291/SENTRY-2539.002.patch
against master.
{color:red}Overall:{color} -1 due to 229 errors
{color:red}ERROR:{color} mvn test exited 143
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestConcurrentClients
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestConcurrentClients
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestConcurrentClients
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestHmsNotificationProcessing
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestDbExportImportPrivileges
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestDbExportImportPrivileges
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestDbExportImportPrivileges
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestDbDDLAuditLog
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestDbDDLAuditLog
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestHmsNotificationProcessingWithOutSyncOnCreate
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestDbOperationsPart2
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestDbOperationsPart2
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestDbOperationsPart2
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestDbOperationsPart2
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestDbOperationsPart2
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestDbOperationsPart2
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestDbOperationsPart2
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestDbOperationsPart2
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestDbOperationsPart2
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestDbOperationsPart2
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestDbOperationsPart2
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestDbOperationsPart2
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestDbOperationsPart2
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestDbOperationsPart2
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestDbOperationsPart2
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.metastore.TestMetastoreEndToEnd
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.metastore.TestMetastoreEndToEnd
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.metastore.TestMetastoreEndToEnd
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.metastore.TestMetastoreEndToEnd
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.metastore.TestMetastoreEndToEnd
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.metastore.TestMetastoreEndToEnd
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestPrivilegeWithGrantOption
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestPrivilegeWithGrantOption
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestPrivilegeWithGrantOption
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestPrivilegeWithGrantOption
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestDbMetadataPermissions
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestDbMetadataPermissions
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestDbMetadataPermissions
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestDbMetadataPermissions
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestDbMetadataPermissions
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestDbPrivilegesAtDatabaseScope
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestDbPrivilegesAtDatabaseScope
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestDbPrivilegesAtDatabaseScope
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestDbPrivilegesAtDatabaseScope
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestDbPrivilegesAtDatabaseScope
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestDbPrivilegesAtDatabaseScope
[jira] [Commented] (SENTRY-2540) Only use SELECT action for filter SHOW DATABASES and SHOW TABLES command based on configuration
[
https://issues.apache.org/jira/browse/SENTRY-2540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16996658#comment-16996658
]
Hadoop QA commented on SENTRY-2540:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12988879/SENTRY-2540.003.patch
against master.
{color:green}Overall:{color} +1 all checks pass
{color:green}SUCCESS:{color} all tests passed
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4453/console
This message is automatically generated.
> Only use SELECT action for filter SHOW DATABASES and SHOW TABLES command
> based on configuration
> ---
>
> Key: SENTRY-2540
> URL: https://issues.apache.org/jira/browse/SENTRY-2540
> Project: Sentry
> Issue Type: Improvement
>Reporter: Na Li
>Assignee: Na Li
>Priority: Major
> Attachments: SENTRY-2540.001.patch, SENTRY-2540.002.patch,
> SENTRY-2540.002.patch, SENTRY-2540.003.patch, SENTRY-2540.003.patch,
> SENTRY-2540.003.patch, SENTRY-2540.003.patch, SENTRY-2540.003.patch
>
>
> When there are thousands of databases, SHOW DATABASES may take a really long
> time because SENTRY checks if user has any of the following privileges on
> that database for filtering out the database
> DBModelAction.SELECT, DBModelAction.INSERT, DBModelAction.ALTER,
> DBModelAction.CREATE, DBModelAction.DROP, DBModelAction.INDEX,
> DBModelAction.LOCK
> To speedup the authorization checking for this case, Sentry can check only
> the select privilege for SHOW DATABASES and SHOW TABLES based on
> configuration.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SENTRY-2540) Only use SELECT action for filter SHOW DATABASES and SHOW TABLES command based on configuration
[
https://issues.apache.org/jira/browse/SENTRY-2540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16996598#comment-16996598
]
Hadoop QA commented on SENTRY-2540:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12988871/SENTRY-2540.003.patch
against master.
{color:red}Overall:{color} -1 due to 5 errors
{color:red}ERROR:{color} mvn test exited 1
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hdfs.TestHDFSIntegrationEnd2End
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestOwnerPrivileges
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hdfs.TestHDFSIntegrationWithHA
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hdfs.TestHDFSIntegrationTogglingConf
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4451/console
This message is automatically generated.
> Only use SELECT action for filter SHOW DATABASES and SHOW TABLES command
> based on configuration
> ---
>
> Key: SENTRY-2540
> URL: https://issues.apache.org/jira/browse/SENTRY-2540
> Project: Sentry
> Issue Type: Improvement
>Reporter: Na Li
>Assignee: Na Li
>Priority: Major
> Attachments: SENTRY-2540.001.patch, SENTRY-2540.002.patch,
> SENTRY-2540.002.patch, SENTRY-2540.003.patch, SENTRY-2540.003.patch,
> SENTRY-2540.003.patch
>
>
> When there are thousands of databases, SHOW DATABASES may take a really long
> time because SENTRY checks if user has any of the following privileges on
> that database for filtering out the database
> DBModelAction.SELECT, DBModelAction.INSERT, DBModelAction.ALTER,
> DBModelAction.CREATE, DBModelAction.DROP, DBModelAction.INDEX,
> DBModelAction.LOCK
> To speedup the authorization checking for this case, Sentry can check only
> the select privilege for SHOW DATABASES and SHOW TABLES based on
> configuration.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SENTRY-2540) Only use SELECT action for filter SHOW DATABASES and SHOW TABLES command based on configuration
[
https://issues.apache.org/jira/browse/SENTRY-2540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16995886#comment-16995886
]
Hadoop QA commented on SENTRY-2540:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12988809/SENTRY-2540.003.patch
against master.
{color:red}Overall:{color} -1 due to 6 errors
{color:red}ERROR:{color} mvn test exited 1
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hdfs.TestHDFSIntegrationEnd2End
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hdfs.TestHDFSIntegrationWithHA
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hdfs.TestHDFSIntegrationTogglingConf
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestHmsNotificationProcessingWithOutSyncOnDrop
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hdfs.TestHDFSIntegrationAdvanced
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4449/console
This message is automatically generated.
> Only use SELECT action for filter SHOW DATABASES and SHOW TABLES command
> based on configuration
> ---
>
> Key: SENTRY-2540
> URL: https://issues.apache.org/jira/browse/SENTRY-2540
> Project: Sentry
> Issue Type: Improvement
>Reporter: Na Li
>Assignee: Na Li
>Priority: Major
> Attachments: SENTRY-2540.001.patch, SENTRY-2540.002.patch,
> SENTRY-2540.002.patch, SENTRY-2540.003.patch
>
>
> When there are thousands of databases, SHOW DATABASES may take a really long
> time because SENTRY checks if user has any of the following privileges on
> that database for filtering out the database
> DBModelAction.SELECT, DBModelAction.INSERT, DBModelAction.ALTER,
> DBModelAction.CREATE, DBModelAction.DROP, DBModelAction.INDEX,
> DBModelAction.LOCK
> To speedup the authorization checking for this case, Sentry can check only
> the select privilege for SHOW DATABASES and SHOW TABLES based on
> configuration.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SENTRY-2540) Only use SELECT action for filter SHOW DATABASES and SHOW TABLES command based on configuration
[
https://issues.apache.org/jira/browse/SENTRY-2540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16995748#comment-16995748
]
Hadoop QA commented on SENTRY-2540:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12988808/SENTRY-2540.002.patch
against master.
{color:red}Overall:{color} -1 due to an error
{color:red}ERROR:{color} failed to build with patch (exit code 1)
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4448/console
This message is automatically generated.
> Only use SELECT action for filter SHOW DATABASES and SHOW TABLES command
> based on configuration
> ---
>
> Key: SENTRY-2540
> URL: https://issues.apache.org/jira/browse/SENTRY-2540
> Project: Sentry
> Issue Type: Improvement
>Reporter: Na Li
>Assignee: Na Li
>Priority: Major
> Attachments: SENTRY-2540.001.patch, SENTRY-2540.002.patch,
> SENTRY-2540.002.patch
>
>
> When there are thousands of databases, SHOW DATABASES may take a really long
> time because SENTRY checks if user has any of the following privileges on
> that database for filtering out the database
> DBModelAction.SELECT, DBModelAction.INSERT, DBModelAction.ALTER,
> DBModelAction.CREATE, DBModelAction.DROP, DBModelAction.INDEX,
> DBModelAction.LOCK
> To speedup the authorization checking for this case, Sentry can check only
> the select privilege for SHOW DATABASES and SHOW TABLES based on
> configuration.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SENTRY-2538) consecutiveUpdateFailuresCount is not reset
[
https://issues.apache.org/jira/browse/SENTRY-2538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16994229#comment-16994229
]
Hadoop QA commented on SENTRY-2538:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12988626/SENTRY-2538.001.patch
against master.
{color:green}Overall:{color} +1 all checks pass
{color:green}SUCCESS:{color} all tests passed
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build//console
This message is automatically generated.
> consecutiveUpdateFailuresCount is not reset
> ---
>
> Key: SENTRY-2538
> URL: https://issues.apache.org/jira/browse/SENTRY-2538
> Project: Sentry
> Issue Type: Bug
> Components: Sentry
>Reporter: László Dénes Terjéki
>Assignee: László Dénes Terjéki
>Priority: Major
> Attachments:
> 0001-SENTRY-2538-reset-consecutiveUpdateFailuresCount-on-.patch,
> SENTRY-2538.001.patch
>
>
> *consecutiveUpdateFailuresCount* reset only happens when an error occurs and
> the threshold is reached. Also as a side affect the log always contains the
> following message
> {code:java}
> ERROR org.apache.sentry.provider.db.generic.UpdatableCache: Failed to update
> roles and privileges cache for 0 times. Revoking all privileges from cache,
> which will cause all authorization requests to fail.
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SENTRY-2536) optimize the filtering performed by sentry
[
https://issues.apache.org/jira/browse/SENTRY-2536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16991930#comment-16991930
]
Hadoop QA commented on SENTRY-2536:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12988355/SENTRY-2536.001.patch
against master.
{color:red}Overall:{color} -1 due to 7 errors
{color:red}ERROR:{color} mvn test exited 1
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hdfs.TestHDFSIntegrationEnd2End
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestOwnerPrivileges
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hdfs.TestHDFSIntegrationWithHA
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hdfs.TestHDFSIntegrationTogglingConf
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hdfs.TestHDFSIntegrationAdvanced
{color:red}ERROR:{color} Failed: org.apache.sentry.tests.e2e.hive.TestConfigTool
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4443/console
This message is automatically generated.
> optimize the filtering performed by sentry
> --
>
> Key: SENTRY-2536
> URL: https://issues.apache.org/jira/browse/SENTRY-2536
> Project: Sentry
> Issue Type: Bug
> Components: Sentry
>Affects Versions: 2.0.1
>Reporter: Kalyan Kalvagadda
>Assignee: Kalyan Kalvagadda
>Priority: Major
> Attachments: SENTRY-2536.001.patch, SENTRY-2536.001.patch
>
>
> For commands like "show databases" and "show tables" filtering mechanism is
> applied where the filter is applied on entry to decide if the user is
> authorized to see that entry.
>
> This filtering takes longer when the number of objects that need to be
> filtered are very high.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SENTRY-2536) optimize the filtering performed by sentry
[
https://issues.apache.org/jira/browse/SENTRY-2536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16987358#comment-16987358
]
Hadoop QA commented on SENTRY-2536:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12987401/SENTRY-2536.001.patch
against master.
{color:red}Overall:{color} -1 due to 6 errors
{color:red}ERROR:{color} mvn test exited 1
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hdfs.TestHDFSIntegrationWithHA
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hdfs.TestHDFSIntegrationWithHA
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hdfs.TestHDFSIntegrationWithHA
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestHmsNotificationProcessingWithOutSyncOnDrop
{color:red}ERROR:{color} Failed: org.apache.sentry.tests.e2e.hive.TestConfigTool
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4441/console
This message is automatically generated.
> optimize the filtering performed by sentry
> --
>
> Key: SENTRY-2536
> URL: https://issues.apache.org/jira/browse/SENTRY-2536
> Project: Sentry
> Issue Type: Bug
> Components: Sentry
>Affects Versions: 2.0.1
>Reporter: Kalyan Kalvagadda
>Assignee: Kalyan Kalvagadda
>Priority: Major
> Attachments: SENTRY-2536.001.patch
>
>
> For commands like "show databases" and "show tables" filtering mechanism is
> applied where the filter is applied on entry to decide if the user is
> authorized to see that entry.
>
> This filtering takes longer when the number of objects that need to be
> filtered are very high.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SENTRY-2536) optimize the filtering performed by sentry
[
https://issues.apache.org/jira/browse/SENTRY-2536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16982947#comment-16982947
]
Hadoop QA commented on SENTRY-2536:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12986710/SENTRY-2536.001.patch
against master.
{color:red}Overall:{color} -1 due to 5 errors
{color:red}ERROR:{color} mvn test exited 1
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hdfs.TestHDFSIntegrationEnd2End
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hdfs.TestHDFSIntegrationWithHA
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hdfs.TestHDFSIntegrationAdvanced
{color:red}ERROR:{color} Failed: org.apache.sentry.tests.e2e.hive.TestConfigTool
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4439/console
This message is automatically generated.
> optimize the filtering performed by sentry
> --
>
> Key: SENTRY-2536
> URL: https://issues.apache.org/jira/browse/SENTRY-2536
> Project: Sentry
> Issue Type: Bug
> Components: Sentry
>Affects Versions: 2.0.1
>Reporter: Kalyan Kalvagadda
>Assignee: Kalyan Kalvagadda
>Priority: Major
> Attachments: SENTRY-2536.001.patch
>
>
> For commands like "show databases" and "show tables" filtering mechanism is
> applied where the filter is applied on entry to decide if the user is
> authorized to see that entry.
>
> This filtering takes longer when the number of objects that need to be
> filtered are very high.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SENTRY-2535) SentryKafkaAuthorizer throws Exception when describing ACLs
[
https://issues.apache.org/jira/browse/SENTRY-2535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16968796#comment-16968796
]
Hadoop QA commented on SENTRY-2535:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12985114/SENTRY-2535.002.patch
against master.
{color:green}Overall:{color} +1 all checks pass
{color:green}SUCCESS:{color} all tests passed
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4434/console
This message is automatically generated.
> SentryKafkaAuthorizer throws Exception when describing ACLs
> ---
>
> Key: SENTRY-2535
> URL: https://issues.apache.org/jira/browse/SENTRY-2535
> Project: Sentry
> Issue Type: Bug
> Components: Sentry
>Reporter: Gergo Wilder
>Assignee: Gergo Wilder
>Priority: Major
> Attachments: SENTRY-2535.001.patch, SENTRY-2535.002.patch,
> SENTRY-2535.002.patch
>
>
> ConsumerGroup resource type is not handled properly in SentryKafkaAuthorizer
> causing an exception when converting from Sentry consumer group resource type
> to Kafka's consumer group resource type.
> {noformat}
> 2019-10-25 12:30:17,992 ERROR kafka.server.KafkaApis: [KafkaApi-6] Error
> when handling request: clientId=adminclient-83, correlationId=1158,
> api=DESCRIBE_ACLS,
> body={resource_type=2,resource_name=null,resource_pattern_type_filter=1,principal=null,host=null,operation=1,permission_type=1}
> kafka.common.KafkaException: CONSUMERGROUP not a valid resourceType name. The
> valid names are Topic,Group,Cluster,TransactionalId,DelegationToken
> at
> kafka.security.auth.ResourceType$$anonfun$fromString$1.apply(ResourceType.scala:64)
> at
> kafka.security.auth.ResourceType$$anonfun$fromString$1.apply(ResourceType.scala:64)
> at scala.Option.getOrElse(Option.scala:121)
> at kafka.security.auth.ResourceType$.fromString(ResourceType.scala:64)
> at
> org.apache.sentry.kafka.binding.KafkaAuthBinding.rolePrivilegesToResourceAcls(KafkaAuthBinding.java:481)
> at
> org.apache.sentry.kafka.binding.KafkaAuthBinding.getAclsForRoles(KafkaAuthBinding.java:463)
> at
> org.apache.sentry.kafka.binding.KafkaAuthBinding.getAcls(KafkaAuthBinding.java:379)
> at
> org.apache.sentry.kafka.authorizer.SentryKafkaAuthorizer.getAcls(SentryKafkaAuthorizer.java:93)
> at kafka.server.KafkaApis.handleDescribeAcls(KafkaApis.scala:1911)
> at kafka.server.KafkaApis.handle(KafkaApis.scala:137)
> at kafka.server.KafkaRequestHandler.run(KafkaRequestHandler.scala:74)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SENTRY-2533) The UDF in_file should be blacked defaultly
[
https://issues.apache.org/jira/browse/SENTRY-2533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16935290#comment-16935290
]
Hadoop QA commented on SENTRY-2533:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12980996/SENTRY-2533.001.patch
against master.
{color:green}Overall:{color} +1 all checks pass
{color:green}SUCCESS:{color} all tests passed
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4432/console
This message is automatically generated.
> The UDF in_file should be blacked defaultly
> ---
>
> Key: SENTRY-2533
> URL: https://issues.apache.org/jira/browse/SENTRY-2533
> Project: Sentry
> Issue Type: New Feature
> Components: Sentry
>Affects Versions: 2.1.0
>Reporter: Wenchao Li
>Priority: Major
> Labels: security
> Attachments: SENTRY-2533.001.patch, SENTRY-2533.001.patch,
> SENTRY-2533.001.patch, SENTRY-2533.001.patch
>
>
> HIVE-20420(CVE-2018-11777) introduced a fallback authorizer factory which
> disallowed some builtin UDFs such as java_method, reflect, reflect2 and
> in_file. But Sentry does not black in_file up to now, so a malicious user can
> use in_file in SQL queries to detect some specific files on the HS2 host, or
> to detect whether a specific file has specific content. in_file should be
> added to HIVE_UDF_BLACK_LIST.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SENTRY-2533) The UDF in_file should be blacked defaultly
[
https://issues.apache.org/jira/browse/SENTRY-2533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16934984#comment-16934984
]
Hadoop QA commented on SENTRY-2533:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12980961/SENTRY-2533.001.patch
against master.
{color:red}Overall:{color} -1 due to an error
{color:red}ERROR:{color} mvn test exited 1
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4429/console
This message is automatically generated.
> The UDF in_file should be blacked defaultly
> ---
>
> Key: SENTRY-2533
> URL: https://issues.apache.org/jira/browse/SENTRY-2533
> Project: Sentry
> Issue Type: New Feature
> Components: Sentry
>Affects Versions: 2.1.0
>Reporter: Wenchao Li
>Priority: Major
> Labels: security
> Attachments: SENTRY-2533.001.patch
>
>
> HIVE-20420(CVE-2018-11777) introduced a fallback authorizer factory which
> disallowed some builtin UDFs such as java_method, reflect, reflect2 and
> in_file. But Sentry does not black in_file up to now, so a malicious user can
> use in_file in SQL queries to detect some specific files on the HS2 host, or
> to detect whether a specific file has specific content. in_file should be
> added to HIVE_UDF_BLACK_LIST.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SENTRY-2533) The UDF in_file should be blacked defaultly
[
https://issues.apache.org/jira/browse/SENTRY-2533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16934952#comment-16934952
]
Hadoop QA commented on SENTRY-2533:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12980959/SENTRY-2533.001.patch
against master.
{color:red}Overall:{color} -1 due to an error
{color:red}ERROR:{color} failed to build with patch (exit code 1)
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4428/console
This message is automatically generated.
> The UDF in_file should be blacked defaultly
> ---
>
> Key: SENTRY-2533
> URL: https://issues.apache.org/jira/browse/SENTRY-2533
> Project: Sentry
> Issue Type: New Feature
> Components: Sentry
>Affects Versions: 2.1.0
>Reporter: Wenchao Li
>Priority: Major
> Labels: security
> Attachments: SENTRY-2533.001.patch
>
>
> HIVE-20420(CVE-2018-11777) introduced a fallback authorizer factory which
> disallowed some builtin UDFs such as java_method, reflect, reflect2 and
> in_file. But Sentry does not black in_file up to now, so a malicious user can
> use in_file in SQL queries to detect some specific files on the HS2 host, or
> to detect whether a specific file has specific content. in_file should be
> added to HIVE_UDF_BLACK_LIST.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SENTRY-2528) Format exception when fetching a full snapshot
[
https://issues.apache.org/jira/browse/SENTRY-2528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16881451#comment-16881451
]
Hadoop QA commented on SENTRY-2528:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12974057/SENTRY-2528.01.patch
against master.
{color:green}Overall:{color} +1 all checks pass
{color:green}SUCCESS:{color} all tests passed
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4427/console
This message is automatically generated.
> Format exception when fetching a full snapshot
> --
>
> Key: SENTRY-2528
> URL: https://issues.apache.org/jira/browse/SENTRY-2528
> Project: Sentry
> Issue Type: Bug
> Components: Sentry
>Reporter: Arjun Mishra
>Assignee: Arjun Mishra
>Priority: Major
> Attachments: SENTRY-2528.01.patch
>
>
> When fetching a full snapshot we get the below error. This is a regression of
> SENTRY-2301
> {noformat}
> 2019-07-07 23:07:39,677 ERROR
> org.apache.sentry.service.thrift.SentryHMSClient: Snapshot created failed
> java.util.IllegalFormatConversionException: f != java.lang.Long
> at
> java.util.Formatter$FormatSpecifier.failConversion(Formatter.java:4302)
> at java.util.Formatter$FormatSpecifier.printFloat(Formatter.java:2806)
> at java.util.Formatter$FormatSpecifier.print(Formatter.java:2753)
> at java.util.Formatter.format(Formatter.java:2520)
> at java.util.Formatter.format(Formatter.java:2455)
> at java.lang.String.format(String.java:2940)
> at
> org.apache.sentry.service.thrift.FullUpdateInitializer.getFullHMSSnapshot(FullUpdateInitializer.java:552)
> at
> org.apache.sentry.service.thrift.SentryHMSClient.fetchFullUpdate(SentryHMSClient.java:244)
> at
> org.apache.sentry.service.thrift.SentryHMSClient.getFullSnapshot(SentryHMSClient.java:147)
> at
> org.apache.sentry.provider.db.service.persistent.HMSFollower.createFullSnapshot(HMSFollower.java:409)
> at
> org.apache.sentry.provider.db.service.persistent.HMSFollower.syncupWithHms(HMSFollower.java:237)
> at
> org.apache.sentry.provider.db.service.persistent.HMSFollower.run(HMSFollower.java:198)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2276) Sentry-Kafka integration does not support Kafka's Alter/DescribeConfigs and IdempotentWrite operations
[
https://issues.apache.org/jira/browse/SENTRY-2276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16877908#comment-16877908
]
Hadoop QA commented on SENTRY-2276:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12973554/SENTRY-2276.003.patch
against master.
{color:green}Overall:{color} +1 all checks pass
{color:green}SUCCESS:{color} all tests passed
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4426/console
This message is automatically generated.
> Sentry-Kafka integration does not support Kafka's Alter/DescribeConfigs and
> IdempotentWrite operations
> --
>
> Key: SENTRY-2276
> URL: https://issues.apache.org/jira/browse/SENTRY-2276
> Project: Sentry
> Issue Type: Bug
> Components: kafka-integration
> Environment: Cloudera's Kafka (CDK 3.1.0) and Sentry Distribution, as
> included with CDH 5.13
>Reporter: Julian Eberius
>Assignee: Gergo Wilder
>Priority: Minor
> Attachments: SENTRY-2276.002.patch, SENTRY-2276.003.patch
>
>
> When sending AlterConfigs or DescribeConfigs requests using Kafka's
> AdminClient class to a Sentry-enabled Kafka broker, I noticed that the
> request would fail on the broker side with a NullPointerException in
> ResourceAuthorizationProvider::buildPermissions, the action being null.
> However, other requests, such as DescribeTopics, would work fine. I
> discovered that these request type are not covered in Sentry's
> [KafkaActionFactory|https://github.com/apache/sentry/blob/branch-2.0/sentry-core/sentry-core-model-kafka/src/main/java/org/apache/sentry/core/model/kafka/KafkaActionFactory.java]
> which leads to null values being returned as Actions, e.g., from
> getActionByName.
> Sentry's Kafka binding does not support the following actions that are
> defined by Kafka's authorization model:
> * AlterConfigs
> * DescribeConfigs
> * IdempotentWrite
> It does not support the TransactionalId authorizable resource either that is
> required for using Kafka's transactional capabilities in combination with
> Sentry authorizer.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2276) Sentry-Kafka integration does not support Kafka's Alter/DescribeConfigs and IdempotentWrite operations
[
https://issues.apache.org/jira/browse/SENTRY-2276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16877749#comment-16877749
]
Hadoop QA commented on SENTRY-2276:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12973535/SENTRY-2276.001.patch
against master.
{color:green}Overall:{color} +1 all checks pass
{color:green}SUCCESS:{color} all tests passed
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4424/console
This message is automatically generated.
> Sentry-Kafka integration does not support Kafka's Alter/DescribeConfigs and
> IdempotentWrite operations
> --
>
> Key: SENTRY-2276
> URL: https://issues.apache.org/jira/browse/SENTRY-2276
> Project: Sentry
> Issue Type: Bug
> Components: kafka-integration
> Environment: Cloudera's Kafka (CDK 3.1.0) and Sentry Distribution, as
> included with CDH 5.13
>Reporter: Julian Eberius
>Assignee: Gergo Wilder
>Priority: Minor
> Attachments: SENTRY-2276.002.patch
>
>
> When sending AlterConfigs or DescribeConfigs requests using Kafka's
> AdminClient class to a Sentry-enabled Kafka broker, I noticed that the
> request would fail on the broker side with a NullPointerException in
> ResourceAuthorizationProvider::buildPermissions, the action being null.
> However, other requests, such as DescribeTopics, would work fine. I
> discovered that these request type are not covered in Sentry's
> [KafkaActionFactory|https://github.com/apache/sentry/blob/branch-2.0/sentry-core/sentry-core-model-kafka/src/main/java/org/apache/sentry/core/model/kafka/KafkaActionFactory.java]
> which leads to null values being returned as Actions, e.g., from
> getActionByName.
> Sentry's Kafka binding does not support the following actions that are
> defined by Kafka's authorization model:
> * AlterConfigs
> * DescribeConfigs
> * IdempotentWrite
> It does not support the TransactionalId authorizable resource either that is
> required for using Kafka's transactional capabilities in combination with
> Sentry authorizer.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2276) Sentry-Kafka integration does not support Kafka's Alter/DescribeConfigs and IdempotentWrite operations
[
https://issues.apache.org/jira/browse/SENTRY-2276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16877746#comment-16877746
]
Hadoop QA commented on SENTRY-2276:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12973538/SENTRY-2276.002.patch
against master.
{color:red}Overall:{color} -1 due to 2 errors
{color:red}ERROR:{color} mvn test exited 1
{color:red}ERROR:{color} Failed:
org.apache.sentry.kafka.authorizer.SentryKafkaAuthorizerTest
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4425/console
This message is automatically generated.
> Sentry-Kafka integration does not support Kafka's Alter/DescribeConfigs and
> IdempotentWrite operations
> --
>
> Key: SENTRY-2276
> URL: https://issues.apache.org/jira/browse/SENTRY-2276
> Project: Sentry
> Issue Type: Bug
> Components: kafka-integration
> Environment: Cloudera's Kafka (CDK 3.1.0) and Sentry Distribution, as
> included with CDH 5.13
>Reporter: Julian Eberius
>Assignee: Gergo Wilder
>Priority: Minor
> Attachments: SENTRY-2276.002.patch
>
>
> When sending AlterConfigs or DescribeConfigs requests using Kafka's
> AdminClient class to a Sentry-enabled Kafka broker, I noticed that the
> request would fail on the broker side with a NullPointerException in
> ResourceAuthorizationProvider::buildPermissions, the action being null.
> However, other requests, such as DescribeTopics, would work fine. I
> discovered that these request type are not covered in Sentry's
> [KafkaActionFactory|https://github.com/apache/sentry/blob/branch-2.0/sentry-core/sentry-core-model-kafka/src/main/java/org/apache/sentry/core/model/kafka/KafkaActionFactory.java]
> which leads to null values being returned as Actions, e.g., from
> getActionByName.
> Sentry's Kafka binding does not support the following actions that are
> defined by Kafka's authorization model:
> * AlterConfigs
> * DescribeConfigs
> * IdempotentWrite
> It does not support the TransactionalId authorizable resource either that is
> required for using Kafka's transactional capabilities in combination with
> Sentry authorizer.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2228) Improve on how to handle unsupported Hive commands
[
https://issues.apache.org/jira/browse/SENTRY-2228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16864492#comment-16864492
]
Hadoop QA commented on SENTRY-2228:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12922917/SENTRY-2228.002.patch
against master.
{color:red}Overall:{color} -1 due to 26 errors
{color:red}ERROR:{color} mvn test exited 143
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hive.fs.TestTableOnExtFS
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hive.TestMetadataPermissions
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hive.TestMetadataPermissions
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hive.TestMetadataPermissions
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hive.TestMetadataPermissions
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hive.fs.TestHiveWarehouseOnExtFs
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hive.TestExportImportPrivileges
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hive.TestExportImportPrivileges
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hive.TestJDBCInterface
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hive.TestLockPrivileges
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hive.TestLockPrivileges
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hive.TestMovingToProduction
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hive.TestMovingToProduction
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hive.TestDescribeMetadataPrivileges
{color:red}ERROR:{color} Failed: org.apache.sentry.tests.e2e.hive.TestEndToEnd
{color:red}ERROR:{color} Failed: org.apache.sentry.tests.e2e.hive.TestConfigTool
{color:red}ERROR:{color} Failed: org.apache.sentry.tests.e2e.hive.TestConfigTool
{color:red}ERROR:{color} Failed: org.apache.sentry.tests.e2e.hive.TestConfigTool
{color:red}ERROR:{color} Failed: org.apache.sentry.tests.e2e.hive.TestConfigTool
{color:red}ERROR:{color} Failed: org.apache.sentry.tests.e2e.hive.TestConfigTool
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hive.TestPolicyImportExport
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hive.TestPolicyImportExport
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hive.TestPolicyImportExport
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hive.TestPolicyImportExport
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hive.TestAllowedGrantPrivileges
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4419/console
This message is automatically generated.
> Improve on how to handle unsupported Hive commands
> --
>
> Key: SENTRY-2228
> URL: https://issues.apache.org/jira/browse/SENTRY-2228
> Project: Sentry
> Issue Type: Improvement
> Components: Sentry
>Affects Versions: 2.1.0
>Reporter: Na Li
>Priority: Major
> Attachments: SENTRY-2228.002.patch
>
>
> Sentry should throw exception when encountering unsupported Hive command.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2289) Tests in TestHDFSIntegrationAdvanced fail from time to time
[
https://issues.apache.org/jira/browse/SENTRY-2289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16864441#comment-16864441
]
Hadoop QA commented on SENTRY-2289:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12929628/SENTRY-2289.001.patch
against master.
{color:green}Overall:{color} +1 all checks pass
{color:green}SUCCESS:{color} all tests passed
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4421/console
This message is automatically generated.
> Tests in TestHDFSIntegrationAdvanced fail from time to time
> ---
>
> Key: SENTRY-2289
> URL: https://issues.apache.org/jira/browse/SENTRY-2289
> Project: Sentry
> Issue Type: Bug
> Components: Sentry
>Affects Versions: 2.1.0
>Reporter: Na Li
>Priority: Major
> Attachments: SENTRY-2289.001.patch
>
>
> The test cases fail from time to time, but works if run individually.
> It is likely due to the async nature of HDFS sync from sentry, so when next
> test is running, old test clean up removes the added DB, table, role or
> privileges.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-1957) Do not parse hive sql string in Sentry
[
https://issues.apache.org/jira/browse/SENTRY-1957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16864361#comment-16864361
]
Hadoop QA commented on SENTRY-1957:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12889532/SENTRY-1957.003.patch
against master.
{color:red}Overall:{color} -1 due to an error
{color:red}ERROR:{color} failed to apply patch (exit code 1):
error:
a/sentry-binding/sentry-binding-hive-v2/src/main/java/org/apache/sentry/binding/hive/v2/SentryAuthorizerFactory.java:
does not exist in index
error:
a/sentry-binding/sentry-binding-hive-v2/src/main/java/org/apache/sentry/binding/hive/v2/authorizer/DefaultSentryValidator.java:
does not exist in index
error:
a/sentry-binding/sentry-binding-hive-v2/src/main/java/org/apache/sentry/binding/hive/v2/authorizer/SentryHiveAuthorizationValidator.java:
does not exist in index
error:
a/sentry-binding/sentry-binding-hive-v2/src/main/java/org/apache/sentry/binding/hive/v2/util/SentryAuthorizerUtil.java:
does not exist in index
error:
a/sentry-binding/sentry-binding-hive-v2/src/main/java/org/apache/sentry/binding/hive/v2/util/SimpleSemanticAnalyzer.java:
does not exist in index
error:
sentry-binding/sentry-binding-hive-v2/src/main/java/org/apache/sentry/binding/hive/v2/SentryAuthorizerFactory.java:
does not exist in index
error:
sentry-binding/sentry-binding-hive-v2/src/main/java/org/apache/sentry/binding/hive/v2/authorizer/DefaultSentryValidator.java:
does not exist in index
error:
sentry-binding/sentry-binding-hive-v2/src/main/java/org/apache/sentry/binding/hive/v2/authorizer/SentryHiveAuthorizationValidator.java:
does not exist in index
error:
sentry-binding/sentry-binding-hive-v2/src/main/java/org/apache/sentry/binding/hive/v2/util/SentryAuthorizerUtil.java:
does not exist in index
error:
sentry-binding/sentry-binding-hive-v2/src/main/java/org/apache/sentry/binding/hive/v2/util/SimpleSemanticAnalyzer.java:
does not exist in index
error:
sentry-binding-hive-v2/src/main/java/org/apache/sentry/binding/hive/v2/SentryAuthorizerFactory.java:
does not exist in index
error:
sentry-binding-hive-v2/src/main/java/org/apache/sentry/binding/hive/v2/authorizer/DefaultSentryValidator.java:
does not exist in index
error:
sentry-binding-hive-v2/src/main/java/org/apache/sentry/binding/hive/v2/authorizer/SentryHiveAuthorizationValidator.java:
does not exist in index
error:
sentry-binding-hive-v2/src/main/java/org/apache/sentry/binding/hive/v2/util/SentryAuthorizerUtil.java:
does not exist in index
error:
sentry-binding-hive-v2/src/main/java/org/apache/sentry/binding/hive/v2/util/SimpleSemanticAnalyzer.java:
does not exist in index
The patch does not appear to apply with p0, p1, or p2
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4423/console
This message is automatically generated.
> Do not parse hive sql string in Sentry
> --
>
> Key: SENTRY-1957
> URL: https://issues.apache.org/jira/browse/SENTRY-1957
> Project: Sentry
> Issue Type: Task
> Components: Sentry
>Affects Versions: 2.0.0
>Reporter: Na Li
>Priority: Major
> Attachments: SENTRY-1957.002.patch, SENTRY-1957.003.patch
>
>
> In current authorization 2 API, Hive does not provide parsed sql string to
> Sentry. So sentry parses the sql string to get database name and table name.
> Once the API changes to include the parsed sql string, sentry should remove
> the code that parses the sql string in SimpleSemanticAnalyzer.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2091) User-based Privilege is broken by SENTRY-769
[
https://issues.apache.org/jira/browse/SENTRY-2091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16864360#comment-16864360
]
Hadoop QA commented on SENTRY-2091:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12907185/SENTRY-2091.006.patch
against master.
{color:red}Overall:{color} -1 due to an error
{color:red}ERROR:{color} failed to apply patch (exit code 1):
error:
a/sentry-binding/sentry-binding-hive-v2/src/main/java/org/apache/sentry/binding/hive/v2/HiveAuthzBindingHookBaseV2.java:
does not exist in index
error:
a/sentry-binding/sentry-binding-hive/src/main/java/org/apache/sentry/binding/hive/authz/HiveAuthzBindingHookBase.java:
does not exist in index
error:
a/sentry-provider/sentry-provider-common/src/main/java/org/apache/sentry/provider/common/ResourceAuthorizationProvider.java:
does not exist in index
error:
a/sentry-provider/sentry-provider-db/src/main/java/org/apache/sentry/provider/db/service/persistent/SentryStore.java:
does not exist in index
error:
a/sentry-tests/sentry-tests-hive/src/test/java/org/apache/sentry/tests/e2e/dbprovider/TestGrantUserToRole.java:
does not exist in index
error:
a/sentry-tests/sentry-tests-hive/src/test/java/org/apache/sentry/tests/e2e/hive/TestUserManagement.java:
does not exist in index
error:
sentry-binding/sentry-binding-hive-v2/src/main/java/org/apache/sentry/binding/hive/v2/HiveAuthzBindingHookBaseV2.java:
does not exist in index
error: patch failed:
sentry-binding/sentry-binding-hive/src/main/java/org/apache/sentry/binding/hive/authz/HiveAuthzBindingHookBase.java:547
Falling back to three-way merge...
Applied patch to
'sentry-binding/sentry-binding-hive/src/main/java/org/apache/sentry/binding/hive/authz/HiveAuthzBindingHookBase.java'
cleanly.
error: patch failed:
sentry-provider/sentry-provider-common/src/main/java/org/apache/sentry/provider/common/ResourceAuthorizationProvider.java:22
Falling back to three-way merge...
Applied patch to
'sentry-provider/sentry-provider-common/src/main/java/org/apache/sentry/provider/common/ResourceAuthorizationProvider.java'
with conflicts.
error:
sentry-provider/sentry-provider-db/src/main/java/org/apache/sentry/provider/db/service/persistent/SentryStore.java:
does not exist in index
error:
sentry-binding-hive-v2/src/main/java/org/apache/sentry/binding/hive/v2/HiveAuthzBindingHookBaseV2.java:
does not exist in index
error:
sentry-binding-hive/src/main/java/org/apache/sentry/binding/hive/authz/HiveAuthzBindingHookBase.java:
does not exist in index
error:
sentry-provider-common/src/main/java/org/apache/sentry/provider/common/ResourceAuthorizationProvider.java:
does not exist in index
error:
sentry-provider-db/src/main/java/org/apache/sentry/provider/db/service/persistent/SentryStore.java:
does not exist in index
error:
sentry-tests-hive/src/test/java/org/apache/sentry/tests/e2e/dbprovider/TestGrantUserToRole.java:
does not exist in index
error:
sentry-tests-hive/src/test/java/org/apache/sentry/tests/e2e/hive/TestUserManagement.java:
does not exist in index
The patch does not appear to apply with p0, p1, or p2
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4422/console
This message is automatically generated.
> User-based Privilege is broken by SENTRY-769
>
>
> Key: SENTRY-2091
> URL: https://issues.apache.org/jira/browse/SENTRY-2091
> Project: Sentry
> Issue Type: Sub-task
> Components: Sentry
>Affects Versions: 2.1.0
>Reporter: Na Li
>Priority: Major
> Attachments: SENTRY-2091.001.patch, SENTRY-2091.002.patch,
> SENTRY-2091.003.patch, SENTRY-2091.004.patch, SENTRY-2091.004.patch,
> SENTRY-2091.006.patch
>
>
> SENTRY-769 throws exception when a user has no group. This breaks user-based
> privilege as the exception prevents getting privilege using user-based
> privilege.
> For example, in the following code
> {code}
> Set userPrivileges =
> authProvider.getPolicyEngine().getPrivileges(
> authProvider.getGroupMapping().getGroups(userName),
> Sets.newHashSet(userName),
> hiveAuthzBinding.getActiveRoleSet(),
> hiveAuthzBinding.getAuthServer());
> {code}
> when user has no group, the exception causes the processing stops even when
> user has privilege.
> The solution is to catch the exception, and continue the processing.
> {code}
> try {
> Set groups = null;
> try {
> groups = authProvider.getGroupMapping().getGroups(userName)
> } catch (SentryGroupNotFoundException ex) {
> log.debug(...);
> groups = new HashSet();
> }
> Set userPrivileges =
> authProvider.getPolicyEngine().getPrivileges(
> groups, Sets.newHashSet(userName),
> hiveAuthzBinding.getActiveRoleSet(),
> hiveAuthzBinding.getAuthServer());
> ...
> }
>
[jira] [Commented] (SENTRY-1949) Old full snapshots are never cleaned up
[
https://issues.apache.org/jira/browse/SENTRY-1949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16864347#comment-16864347
]
Hadoop QA commented on SENTRY-1949:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12920934/SENTRY-1949.004.patch
against master.
{color:red}Overall:{color} -1 due to an error
{color:red}ERROR:{color} failed to apply patch (exit code 1):
error:
a/sentry-provider/sentry-provider-db/src/main/java/org/apache/sentry/provider/db/service/persistent/SentryStore.java:
does not exist in index
error:
a/sentry-provider/sentry-provider-db/src/main/java/org/apache/sentry/service/thrift/SentryService.java:
does not exist in index
error:
a/sentry-provider/sentry-provider-db/src/main/java/org/apache/sentry/service/thrift/ServiceConstants.java:
does not exist in index
error:
a/sentry-provider/sentry-provider-db/src/test/java/org/apache/sentry/provider/db/service/persistent/TestSentryStore.java:
does not exist in index
error:
sentry-provider/sentry-provider-db/src/main/java/org/apache/sentry/provider/db/service/persistent/SentryStore.java:
does not exist in index
error:
sentry-provider/sentry-provider-db/src/main/java/org/apache/sentry/service/thrift/SentryService.java:
does not exist in index
error:
sentry-provider/sentry-provider-db/src/main/java/org/apache/sentry/service/thrift/ServiceConstants.java:
does not exist in index
error:
sentry-provider/sentry-provider-db/src/test/java/org/apache/sentry/provider/db/service/persistent/TestSentryStore.java:
does not exist in index
error:
sentry-provider-db/src/main/java/org/apache/sentry/provider/db/service/persistent/SentryStore.java:
does not exist in index
error:
sentry-provider-db/src/main/java/org/apache/sentry/service/thrift/SentryService.java:
does not exist in index
error:
sentry-provider-db/src/main/java/org/apache/sentry/service/thrift/ServiceConstants.java:
does not exist in index
error:
sentry-provider-db/src/test/java/org/apache/sentry/provider/db/service/persistent/TestSentryStore.java:
does not exist in index
The patch does not appear to apply with p0, p1, or p2
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4418/console
This message is automatically generated.
> Old full snapshots are never cleaned up
> ---
>
> Key: SENTRY-1949
> URL: https://issues.apache.org/jira/browse/SENTRY-1949
> Project: Sentry
> Issue Type: Bug
> Components: Sentry
>Affects Versions: 2.0.0
>Reporter: Alexander Kolbasov
>Priority: Major
> Attachments: SENTRY-1949.001.patch, SENTRY-1949.002.patch,
> SENTRY-1949.003.patch, SENTRY-1949.004.patch, SENTRY-1949.1.patch
>
>
> We never clean old snapshots and they stay forever, hurting performance as
> more and more are accumulated.
> [~vamsee] FYI.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2239) Table rename cross database should update Full snapshot correctly
[
https://issues.apache.org/jira/browse/SENTRY-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16864348#comment-16864348
]
Hadoop QA commented on SENTRY-2239:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12924413/SENTRY-2239.001.patch
against master.
{color:red}Overall:{color} -1 due to an error
{color:red}ERROR:{color} failed to apply patch (exit code 1):
error:
a/sentry-provider/sentry-provider-db/src/main/java/org/apache/sentry/service/thrift/FullUpdateModifier.java:
does not exist in index
error:
a/sentry-provider/sentry-provider-db/src/test/java/org/apache/sentry/provider/db/service/persistent/TestSentryStore.java:
does not exist in index
error:
a/sentry-provider/sentry-provider-db/src/test/java/org/apache/sentry/service/thrift/TestFullUpdateModifier.java:
does not exist in index
error:
a/sentry-tests/sentry-tests-hive/src/test/java/org/apache/sentry/tests/e2e/dbprovider/TestDbPrivilegeCleanupOnDrop.java:
does not exist in index
error:
sentry-provider/sentry-provider-db/src/main/java/org/apache/sentry/service/thrift/FullUpdateModifier.java:
does not exist in index
error:
sentry-provider/sentry-provider-db/src/test/java/org/apache/sentry/provider/db/service/persistent/TestSentryStore.java:
does not exist in index
error:
sentry-provider/sentry-provider-db/src/test/java/org/apache/sentry/service/thrift/TestFullUpdateModifier.java:
does not exist in index
error:
sentry-provider-db/src/main/java/org/apache/sentry/service/thrift/FullUpdateModifier.java:
does not exist in index
error:
sentry-provider-db/src/test/java/org/apache/sentry/provider/db/service/persistent/TestSentryStore.java:
does not exist in index
error:
sentry-provider-db/src/test/java/org/apache/sentry/service/thrift/TestFullUpdateModifier.java:
does not exist in index
error:
sentry-tests-hive/src/test/java/org/apache/sentry/tests/e2e/dbprovider/TestDbPrivilegeCleanupOnDrop.java:
does not exist in index
The patch does not appear to apply with p0, p1, or p2
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4420/console
This message is automatically generated.
> Table rename cross database should update Full snapshot correctly
> --
>
> Key: SENTRY-2239
> URL: https://issues.apache.org/jira/browse/SENTRY-2239
> Project: Sentry
> Issue Type: Bug
>Reporter: Na Li
>Priority: Major
> Attachments: SENTRY-2239.001.patch
>
>
> This only happens if there are "alter table rename" during taking full
> snapshot.
> When alter table rename changes DB name of the table, FullUpdateModifier
> changes all tables' DB name, not just the table whose name is changed. This
> will change the table names incorrectly.
> For example, when user changes table name from "db1.table1" to table name to
> "db2.table2" and in db1 there are two other tables: db1.table3, db1.table4,
> FullUpdateModifier changes the tables from "db1.table1, db1.table3,
> db1.table4" to "db2.table2, db2.table3, db3.table4".
> The desired behavior is changes the tables from "db1.table1" to "db2.table2".
> and "db1.table3, db1.table4" remains the same.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2240) User can DROP function under a database that he/she has no access
[
https://issues.apache.org/jira/browse/SENTRY-2240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16864295#comment-16864295
]
Hadoop QA commented on SENTRY-2240:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12971819/SENTRY-2240.03.patch
against master.
{color:green}Overall:{color} +1 all checks pass
{color:green}SUCCESS:{color} all tests passed
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4416/console
This message is automatically generated.
> User can DROP function under a database that he/she has no access
> -
>
> Key: SENTRY-2240
> URL: https://issues.apache.org/jira/browse/SENTRY-2240
> Project: Sentry
> Issue Type: Bug
> Components: Sentry
>Affects Versions: 1.8.0
>Reporter: Eric Lin
>Assignee: Arjun Mishra
>Priority: Major
> Attachments: SENTRY-2240-1.patch, SENTRY-2240-2.patch,
> SENTRY-2240.01.patch, SENTRY-2240.02.patch, SENTRY-2240.03.patch
>
>
> User can DROP UDF function under a database that he/she has no access to.
> I created it as separate JIRA from SENTRY-781 due to changes are quite
> different.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2240) User can DROP function under a database that he/she has no access
[
https://issues.apache.org/jira/browse/SENTRY-2240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863722#comment-16863722
]
Hadoop QA commented on SENTRY-2240:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12971745/SENTRY-2240.02.patch
against master.
{color:green}Overall:{color} +1 all checks pass
{color:green}SUCCESS:{color} all tests passed
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4415/console
This message is automatically generated.
> User can DROP function under a database that he/she has no access
> -
>
> Key: SENTRY-2240
> URL: https://issues.apache.org/jira/browse/SENTRY-2240
> Project: Sentry
> Issue Type: Bug
> Components: Sentry
>Affects Versions: 1.8.0
>Reporter: Eric Lin
>Assignee: Arjun Mishra
>Priority: Major
> Attachments: SENTRY-2240-1.patch, SENTRY-2240-2.patch,
> SENTRY-2240.01.patch, SENTRY-2240.02.patch
>
>
> User can DROP UDF function under a database that he/she has no access to.
> I created it as separate JIRA from SENTRY-781 due to changes are quite
> different.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2240) User can DROP function under a database that he/she has no access
[
https://issues.apache.org/jira/browse/SENTRY-2240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16862514#comment-16862514
]
Hadoop QA commented on SENTRY-2240:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12971608/SENTRY-2240.01.patch
against master.
{color:red}Overall:{color} -1 due to 16 errors
{color:red}ERROR:{color} mvn test exited 1
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hdfs.TestHDFSIntegrationEnd2End
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestDbPrivilegesAtFunctionScope
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestDbPrivilegesAtFunctionScope
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestDbPrivilegesAtFunctionScope
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestDbPrivilegesAtFunctionScope
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestDbPrivilegesAtFunctionScope
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestDbPrivilegesAtFunctionScope
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestDbPrivilegesAtFunctionScope
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hive.TestPrivilegesAtFunctionScope
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hive.TestPrivilegesAtFunctionScope
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hive.TestPrivilegesAtFunctionScope
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hive.TestPrivilegesAtFunctionScope
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hive.TestPrivilegesAtFunctionScope
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hive.TestPrivilegesAtFunctionScope
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestOwnerPrivilegesWithGrantOption
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4414/console
This message is automatically generated.
> User can DROP function under a database that he/she has no access
> -
>
> Key: SENTRY-2240
> URL: https://issues.apache.org/jira/browse/SENTRY-2240
> Project: Sentry
> Issue Type: Bug
> Components: Sentry
>Affects Versions: 1.8.0
>Reporter: Eric Lin
>Assignee: Arjun Mishra
>Priority: Major
> Attachments: SENTRY-2240-1.patch, SENTRY-2240-2.patch,
> SENTRY-2240.01.patch
>
>
> User can DROP UDF function under a database that he/she has no access to.
> I created it as separate JIRA from SENTRY-781 due to changes are quite
> different.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2523) Fix response of list_sentry_privileges_by_authorizable_and_user API
[
https://issues.apache.org/jira/browse/SENTRY-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16860694#comment-16860694
]
Hadoop QA commented on SENTRY-2523:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12971416/SENTRY-2523.1.patch
against master.
{color:green}Overall:{color} +1 all checks pass
{color:green}SUCCESS:{color} all tests passed
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4413/console
This message is automatically generated.
> Fix response of list_sentry_privileges_by_authorizable_and_user API
> ---
>
> Key: SENTRY-2523
> URL: https://issues.apache.org/jira/browse/SENTRY-2523
> Project: Sentry
> Issue Type: Bug
>Reporter: Hao Hao
>Assignee: Hao Hao
>Priority: Major
> Attachments: SENTRY-2523.1.patch
>
>
> SENTRY-2522 introduced a new API
> list_sentry_privileges_by_authorizable_and_user for bulk fetching privileges
> for a given user. However, in the thrift definition
> (TListSentryPrivilegesByAuthUserResponse) {{privilegesMapByAuth}} should be
> optional as it is only returned when there is no exception thrown.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2522) Add a new thrift API for getting all privileges a user has for a given set of authorizable
[
https://issues.apache.org/jira/browse/SENTRY-2522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16859075#comment-16859075
]
Hadoop QA commented on SENTRY-2522:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12971218/SENTRY-2522.2.patch
against master.
{color:green}Overall:{color} +1 all checks pass
{color:green}SUCCESS:{color} all tests passed
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4412/console
This message is automatically generated.
> Add a new thrift API for getting all privileges a user has for a given set of
> authorizable
> --
>
> Key: SENTRY-2522
> URL: https://issues.apache.org/jira/browse/SENTRY-2522
> Project: Sentry
> Issue Type: Improvement
>Reporter: Hao Hao
>Assignee: Hao Hao
>Priority: Major
> Attachments: SENTRY-2522.1.patch, SENTRY-2522.2.patch
>
>
> SENTRY-2371 added a new API to list sentry privilege for a given user. But a
> 'bulk' API to return sentry privilege for a given user filtered by a set of
> authorizables is desired to reduce client side RPC when need to authorize a
> set of authorizables.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2522) Add a new thrift API for getting all privileges a user has for a given set of authorizable
[
https://issues.apache.org/jira/browse/SENTRY-2522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16858440#comment-16858440
]
Hadoop QA commented on SENTRY-2522:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12971145/SENTRY-2522.1.patch
against master.
{color:green}Overall:{color} +1 all checks pass
{color:green}SUCCESS:{color} all tests passed
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4411/console
This message is automatically generated.
> Add a new thrift API for getting all privileges a user has for a given set of
> authorizable
> --
>
> Key: SENTRY-2522
> URL: https://issues.apache.org/jira/browse/SENTRY-2522
> Project: Sentry
> Issue Type: Improvement
>Reporter: Hao Hao
>Assignee: Hao Hao
>Priority: Major
> Attachments: SENTRY-2522.1.patch
>
>
> SENTRY-2371 added a new API to list sentry privilege for a given user. But a
> 'bulk' API to return sentry privilege for a given user filtered by a set of
> authorizables is desired to reduce client side RPC when need to authorize a
> set of authorizables.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2511) Debug level logging on HMSPaths significantly affects performance
[
https://issues.apache.org/jira/browse/SENTRY-2511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16805199#comment-16805199
]
Hadoop QA commented on SENTRY-2511:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12964197/SENTRY-2511.001.patch
against master.
{color:green}Overall:{color} +1 all checks pass
{color:green}SUCCESS:{color} all tests passed
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4410/console
This message is automatically generated.
> Debug level logging on HMSPaths significantly affects performance
> -
>
> Key: SENTRY-2511
> URL: https://issues.apache.org/jira/browse/SENTRY-2511
> Project: Sentry
> Issue Type: Bug
> Components: Sentry
>Reporter: Arjun Mishra
>Assignee: Arjun Mishra
>Priority: Major
> Fix For: 2.1
>
> Attachments: SENTRY-2511.001.patch, SENTRY-2511.01.patch
>
>
> Newer logging changes were made to HMSPath to help identify the corrupt
> cache. However when there are large number of partitions logging changes made
> makes the processing or creation of an update very slow
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2511) Debug level logging on HMSPaths significantly affects performance
[
https://issues.apache.org/jira/browse/SENTRY-2511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16804588#comment-16804588
]
Hadoop QA commented on SENTRY-2511:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12964117/SENTRY-2511.01.patch
against master.
{color:red}Overall:{color} -1 due to 2 errors
{color:red}ERROR:{color} mvn test exited 1
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestHmsNotificationProcessingWithOutHdfsSync
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4409/console
This message is automatically generated.
> Debug level logging on HMSPaths significantly affects performance
> -
>
> Key: SENTRY-2511
> URL: https://issues.apache.org/jira/browse/SENTRY-2511
> Project: Sentry
> Issue Type: Bug
> Components: Sentry
>Reporter: Arjun Mishra
>Assignee: Arjun Mishra
>Priority: Major
> Fix For: 2.1
>
> Attachments: SENTRY-2511.01.patch
>
>
> Newer logging changes were made to HMSPath to help identify the corrupt
> cache. However when there are large number of partitions logging changes made
> makes the processing or creation of an update very slow
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2505) SENTRY-2505: Fix TestRollingFileWithoutDeleteAppender test case testFileNamePattern
[
https://issues.apache.org/jira/browse/SENTRY-2505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16786011#comment-16786011
]
Hadoop QA commented on SENTRY-2505:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12961415/SENTRY-2505.003.patch
against master.
{color:red}Overall:{color} -1 due to an error
{color:red}ERROR:{color} mvn test exited 1
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4408/console
This message is automatically generated.
> SENTRY-2505: Fix TestRollingFileWithoutDeleteAppender test case
> testFileNamePattern
> ---
>
> Key: SENTRY-2505
> URL: https://issues.apache.org/jira/browse/SENTRY-2505
> Project: Sentry
> Issue Type: Bug
> Components: Sentry
>Reporter: Arjun Mishra
>Assignee: Arjun Mishra
>Priority: Major
> Attachments: SENTRY-2505.003.patch, SENTRY-2505.01.patch,
> SENTRY-2505.02.patch, SENTRY-2505.03.patch
>
>
> TestRollingFileWithoutDeleteAppender#testFileNamePattern because not enough
> time is given to create a file
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2503) Failed to revoke the privilege from impala-shell if the privilege added from beeline cli
[
https://issues.apache.org/jira/browse/SENTRY-2503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16784838#comment-16784838
]
Hadoop QA commented on SENTRY-2503:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12961193/SENTRY-2503.004.patch
against master.
{color:green}Overall:{color} +1 all checks pass
{color:green}SUCCESS:{color} all tests passed
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4407/console
This message is automatically generated.
> Failed to revoke the privilege from impala-shell if the privilege added from
> beeline cli
>
>
> Key: SENTRY-2503
> URL: https://issues.apache.org/jira/browse/SENTRY-2503
> Project: Sentry
> Issue Type: Bug
> Components: Sentry
>Affects Versions: 2.2.0
>Reporter: Na Li
>Assignee: Na Li
>Priority: Major
> Attachments: SENTRY-2503.001.patch, SENTRY-2503.002.patch,
> SENTRY-2503.003.patch, SENTRY-2503.004.patch, SENTRY-2503.004.patch
>
>
> When granting all privilege on a table from impala-shell, this privilege
> cannot be revoked from hiove beeline.
> When granting all privilege on a table from hive beeline, this privilege
> cannot be revoked from impala-shell.
> The reason is that impala uses "ALL" to represent all privilege, and hive
> uses "*". So getting privilege to drop it does not properly.
> The solution is to find all equivalent privileges from input, and drop them.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2503) Failed to revoke the privilege from impala-shell if the privilege added from beeline cli
[
https://issues.apache.org/jira/browse/SENTRY-2503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16783957#comment-16783957
]
Hadoop QA commented on SENTRY-2503:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12961057/SENTRY-2503.004.patch
against master.
{color:red}Overall:{color} -1 due to 9 errors
{color:red}ERROR:{color} mvn test exited 1
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hdfs.TestHDFSIntegrationTogglingConf
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hdfs.TestHDFSIntegrationEnd2End
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestHmsNotificationProcessing
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestDbPrivilegeCleanupOnDrop
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestHmsNotificationProcessingWithOutSyncOnCreate
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestHmsNotificationProcessingWithOutSyncOnDrop
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hdfs.TestHDFSIntegrationWithHA
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestOwnerPrivilegesWithGrantOption
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4406/console
This message is automatically generated.
> Failed to revoke the privilege from impala-shell if the privilege added from
> beeline cli
>
>
> Key: SENTRY-2503
> URL: https://issues.apache.org/jira/browse/SENTRY-2503
> Project: Sentry
> Issue Type: Bug
> Components: Sentry
>Affects Versions: 2.2.0
>Reporter: Na Li
>Assignee: Na Li
>Priority: Major
> Attachments: SENTRY-2503.001.patch, SENTRY-2503.002.patch,
> SENTRY-2503.003.patch, SENTRY-2503.004.patch
>
>
> When granting all privilege on a table from impala-shell, this privilege
> cannot be revoked from hiove beeline.
> When granting all privilege on a table from hive beeline, this privilege
> cannot be revoked from impala-shell.
> The reason is that impala uses "ALL" to represent all privilege, and hive
> uses "*". So getting privilege to drop it does not properly.
> The solution is to find all equivalent privileges from input, and drop them.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2505) SENTRY-2505: Fix TestRollingFileWithoutDeleteAppender test case testFileNamePattern
[
https://issues.apache.org/jira/browse/SENTRY-2505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16783802#comment-16783802
]
Hadoop QA commented on SENTRY-2505:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12961027/SENTRY-2505.03.patch
against master.
{color:red}Overall:{color} -1 due to 3 errors
{color:red}ERROR:{color} mvn test exited 1
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestHmsNotificationProcessingWithOutHdfsSync
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hdfs.TestHDFSIntegrationAdvanced
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4404/console
This message is automatically generated.
> SENTRY-2505: Fix TestRollingFileWithoutDeleteAppender test case
> testFileNamePattern
> ---
>
> Key: SENTRY-2505
> URL: https://issues.apache.org/jira/browse/SENTRY-2505
> Project: Sentry
> Issue Type: Bug
> Components: Sentry
>Reporter: Arjun Mishra
>Assignee: Arjun Mishra
>Priority: Major
> Attachments: SENTRY-2505.01.patch, SENTRY-2505.02.patch,
> SENTRY-2505.03.patch
>
>
> TestRollingFileWithoutDeleteAppender#testFileNamePattern because not enough
> time is given to create a file
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2503) Failed to revoke the privilege from impala-shell if the privilege added from beeline cli
[
https://issues.apache.org/jira/browse/SENTRY-2503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16783764#comment-16783764
]
Hadoop QA commented on SENTRY-2503:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12961047/SENTRY-2503.003.patch
against master.
{color:red}Overall:{color} -1 due to an error
{color:red}ERROR:{color} failed to build with patch (exit code 1)
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4405/console
This message is automatically generated.
> Failed to revoke the privilege from impala-shell if the privilege added from
> beeline cli
>
>
> Key: SENTRY-2503
> URL: https://issues.apache.org/jira/browse/SENTRY-2503
> Project: Sentry
> Issue Type: Bug
> Components: Sentry
>Affects Versions: 2.2.0
>Reporter: Na Li
>Assignee: Na Li
>Priority: Major
> Attachments: SENTRY-2503.001.patch, SENTRY-2503.002.patch,
> SENTRY-2503.003.patch
>
>
> When granting all privilege on a table from impala-shell, this privilege
> cannot be revoked from hiove beeline.
> When granting all privilege on a table from hive beeline, this privilege
> cannot be revoked from impala-shell.
> The reason is that impala uses "ALL" to represent all privilege, and hive
> uses "*". So getting privilege to drop it does not properly.
> The solution is to find all equivalent privileges from input, and drop them.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2503) Failed to revoke the privilege from impala-shell if the privilege added from beeline cli
[
https://issues.apache.org/jira/browse/SENTRY-2503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16781280#comment-16781280
]
Hadoop QA commented on SENTRY-2503:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12960719/SENTRY-2503.002.patch
against master.
{color:red}Overall:{color} -1 due to 3 errors
{color:red}ERROR:{color} mvn test exited 1
{color:red}ERROR:{color} Failed:
org.apache.sentry.provider.db.service.persistent.TestSentryStore
{color:red}ERROR:{color} Failed:
org.apache.sentry.api.service.thrift.TestSentryServiceIntegration
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4403/console
This message is automatically generated.
> Failed to revoke the privilege from impala-shell if the privilege added from
> beeline cli
>
>
> Key: SENTRY-2503
> URL: https://issues.apache.org/jira/browse/SENTRY-2503
> Project: Sentry
> Issue Type: Bug
> Components: Sentry
>Affects Versions: 2.2.0
>Reporter: Na Li
>Assignee: Na Li
>Priority: Major
> Attachments: SENTRY-2503.001.patch, SENTRY-2503.002.patch
>
>
> When granting all privilege on a table from impala-shell, this privilege
> cannot be revoked from hiove beeline.
> When granting all privilege on a table from hive beeline, this privilege
> cannot be revoked from impala-shell.
> The reason is that impala uses "ALL" to represent all privilege, and hive
> uses "*". So getting privilege to drop it does not properly.
> The solution is to find all equivalent privileges from input, and drop them.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2505) Fix file bounds in TestRollingFileWithoutDeleteAppender test case testFileNamePattern
[
https://issues.apache.org/jira/browse/SENTRY-2505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16781093#comment-16781093
]
Hadoop QA commented on SENTRY-2505:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12960652/SENTRY-2505.02.patch
against master.
{color:green}Overall:{color} +1 all checks pass
{color:green}SUCCESS:{color} all tests passed
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4402/console
This message is automatically generated.
> Fix file bounds in TestRollingFileWithoutDeleteAppender test case
> testFileNamePattern
> -
>
> Key: SENTRY-2505
> URL: https://issues.apache.org/jira/browse/SENTRY-2505
> Project: Sentry
> Issue Type: Bug
> Components: Sentry
>Reporter: Arjun Mishra
>Assignee: Arjun Mishra
>Priority: Major
> Attachments: SENTRY-2505.01.patch, SENTRY-2505.02.patch
>
>
> TestRollingFileWithoutDeleteAppender#testFileNamePattern still flaky because
> of size bounds
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2504) Account for partial revokes on ALL grant
[
https://issues.apache.org/jira/browse/SENTRY-2504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16780878#comment-16780878
]
Hadoop QA commented on SENTRY-2504:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12960635/SENTRY-2504.01.patch
against master.
{color:red}Overall:{color} -1 due to 3 errors
{color:red}ERROR:{color} mvn test exited 1
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hdfs.TestHDFSIntegrationTogglingConf
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hdfs.TestHDFSIntegrationWithHA
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4401/console
This message is automatically generated.
> Account for partial revokes on ALL grant
>
>
> Key: SENTRY-2504
> URL: https://issues.apache.org/jira/browse/SENTRY-2504
> Project: Sentry
> Issue Type: Bug
> Components: Sentry
>Reporter: Arjun Mishra
>Assignee: Arjun Mishra
>Priority: Major
> Attachments: SENTRY-2504.01.patch
>
>
> Right now if ALL grant is given to a role+object, if we revoke a SELECT or
> INSERT, we don't replace with a partial privilege. This however works with *
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2503) Failed to revoke the privilege from impala-shell if the privilege added from beeline cli
[
https://issues.apache.org/jira/browse/SENTRY-2503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16779798#comment-16779798
]
Hadoop QA commented on SENTRY-2503:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12960429/SENTRY-2503.001.patch
against master.
{color:green}Overall:{color} +1 all checks pass
{color:green}SUCCESS:{color} all tests passed
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4400/console
This message is automatically generated.
> Failed to revoke the privilege from impala-shell if the privilege added from
> beeline cli
>
>
> Key: SENTRY-2503
> URL: https://issues.apache.org/jira/browse/SENTRY-2503
> Project: Sentry
> Issue Type: Bug
> Components: Sentry
>Affects Versions: 2.2.0
>Reporter: Na Li
>Assignee: Na Li
>Priority: Major
> Attachments: SENTRY-2503.001.patch
>
>
> When granting all privilege on a table from impala-shell, this privilege
> cannot be revoked from hiove beeline.
> When granting all privilege on a table from hive beeline, this privilege
> cannot be revoked from impala-shell.
> The reason is that impala uses "ALL" to represent all privilege, and hive
> uses "*". So getting privilege to drop it does not properly.
> The solution is to find all equivalent privileges from input, and drop them.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2496) Support multi-field attribute based document level controls for Solr
[
https://issues.apache.org/jira/browse/SENTRY-2496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16777358#comment-16777358
]
Hadoop QA commented on SENTRY-2496:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12960062/SENTRY-2496.patch
against master.
{color:green}Overall:{color} +1 all checks pass
{color:green}SUCCESS:{color} all tests passed
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4399/console
This message is automatically generated.
> Support multi-field attribute based document level controls for Solr
>
>
> Key: SENTRY-2496
> URL: https://issues.apache.org/jira/browse/SENTRY-2496
> Project: Sentry
> Issue Type: Sub-task
>Reporter: Tristan Stevens
>Assignee: Tristan Stevens
>Priority: Major
> Attachments: SENTRY-2496.patch.003
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2497) show grant role results in NPE when URI does not have scheme
[
https://issues.apache.org/jira/browse/SENTRY-2497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16777214#comment-16777214
]
Hadoop QA commented on SENTRY-2497:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12960056/sentry-2497.1.patch
against master.
{color:green}Overall:{color} +1 all checks pass
{color:green}SUCCESS:{color} all tests passed
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4397/console
This message is automatically generated.
> show grant role results in NPE when URI does not have scheme
>
>
> Key: SENTRY-2497
> URL: https://issues.apache.org/jira/browse/SENTRY-2497
> Project: Sentry
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: Haley Reeve
>Assignee: Haley Reeve
>Priority: Major
> Attachments: sentry-2497.1.patch, sentry-2497.0001.patch,
> sentry-2497.001.patch, sentry-2497.01.patch, sentry-2497.1.patch
>
>
> Sentry throws a NullPointerException when trying to run "show grant role" on
> a URI with no scheme associated with it. You can see the stacktrace in the
> HS2 logs:
> {noformat}
> HS2 logs are showing the stacktrace:
> 2019-02-08 05:53:58,650 INFO org.apache.hadoop.hive.ql.Driver:
> [HiveServer2-Background-Pool: Thread-84]: Executing
> command(queryId=hive_20190208
> 055358_a283626f-c906-4bd1-be50-43e2e9a6949b): show grant role uritest
> 2019-02-08 05:53:58,651 INFO org.apache.hadoop.hive.ql.Driver:
> [HiveServer2-Background-Pool: Thread-84]: Starting task [Stage-0:DDL] in
> serial m
> ode
> 2019-02-08 05:53:58,661 ERROR hive.ql.exec.DDLTask:
> [HiveServer2-Background-Pool: Thread-84]: java.lang.NullPointerException
> at
> org.apache.sentry.binding.util.SentryAuthorizerUtil.isLocalUri(SentryAuthorizerUtil.java:283)
> at
> org.apache.sentry.binding.util.SentryAuthorizerUtil.convert2HivePrivilegeObject(SentryAuthorizerUtil.java:267)
> at
> org.apache.sentry.binding.util.SentryAuthorizerUtil.convert2HivePrivilegeInfo(SentryAuthorizerUtil.java:220)
> at
> org.apache.sentry.binding.hive.authz.DefaultSentryAccessController.showPrivilegesByPrincipal(DefaultSentryAccessController.java:279)
> at
> org.apache.sentry.binding.hive.authz.DefaultSentryAccessController.showPrivileges(DefaultSentryAccessController.java:213)
> at
> org.apache.sentry.binding.hive.authz.SentryHiveAuthorizerImpl.showPrivileges(SentryHiveAuthorizerImpl.java:146)
> at org.apache.hadoop.hive.ql.exec.DDLTask.showGrants(DDLTask.java:746)
> at org.apache.hadoop.hive.ql.exec.DDLTask.execute(DDLTask.java:527)
> at org.apache.hadoop.hive.ql.exec.Task.executeTask(Task.java:199)
> at
> org.apache.hadoop.hive.ql.exec.TaskRunner.runSequential(TaskRunner.java:97)
> at org.apache.hadoop.hive.ql.Driver.launchTask(Driver.java:2250)
> at org.apache.hadoop.hive.ql.Driver.execute(Driver.java:1893)
> at org.apache.hadoop.hive.ql.Driver.runInternal(Driver.java:1613)
> at org.apache.hadoop.hive.ql.Driver.run(Driver.java:1332)
> ...
> 2019-02-08 05:53:58,663 ERROR org.apache.hadoop.hive.ql.Driver:
> [HiveServer2-Background-Pool: Thread-84]: FAILED: Execution Error, return
> code 1
> from org.apache.hadoop.hive.ql.exec.DDLTask. null
> {noformat}
> This appears to be happening because the show grant role logic is trying to
> construct a HivePrivilegeObject, which it wasn't doing in 1.8.0, and assumes
> the URI will have a scheme. See:
> {noformat}
> public static boolean isLocalUri(String uriString) throws
> URISyntaxException {
> URI uri = new URI(uriString);
> if (uri.getScheme().equalsIgnoreCase("file")) {
> return true;
> }
> return false;
> }
> {noformat}
> Because uri.getScheme() can return null, the equalsIgnoreCase() can result in
> an NPE.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2497) show grant role results in NPE when URI does not have scheme
[
https://issues.apache.org/jira/browse/SENTRY-2497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16777032#comment-16777032
]
Hadoop QA commented on SENTRY-2497:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12960045/sentry-2497.0001.patch
against master.
{color:red}Overall:{color} -1 due to 2 errors
{color:red}ERROR:{color} mvn test exited 1
{color:red}ERROR:{color} Failed:
org.apache.sentry.provider.db.generic.service.persistent.TestPrivilegeOperatePersistence
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4396/console
This message is automatically generated.
> show grant role results in NPE when URI does not have scheme
>
>
> Key: SENTRY-2497
> URL: https://issues.apache.org/jira/browse/SENTRY-2497
> Project: Sentry
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: Haley Reeve
>Assignee: Haley Reeve
>Priority: Major
> Attachments: sentry-2497.0001.patch, sentry-2497.001.patch,
> sentry-2497.01.patch, sentry-2497.1.patch
>
>
> Sentry throws a NullPointerException when trying to run "show grant role" on
> a URI with no scheme associated with it. You can see the stacktrace in the
> HS2 logs:
> {noformat}
> HS2 logs are showing the stacktrace:
> 2019-02-08 05:53:58,650 INFO org.apache.hadoop.hive.ql.Driver:
> [HiveServer2-Background-Pool: Thread-84]: Executing
> command(queryId=hive_20190208
> 055358_a283626f-c906-4bd1-be50-43e2e9a6949b): show grant role uritest
> 2019-02-08 05:53:58,651 INFO org.apache.hadoop.hive.ql.Driver:
> [HiveServer2-Background-Pool: Thread-84]: Starting task [Stage-0:DDL] in
> serial m
> ode
> 2019-02-08 05:53:58,661 ERROR hive.ql.exec.DDLTask:
> [HiveServer2-Background-Pool: Thread-84]: java.lang.NullPointerException
> at
> org.apache.sentry.binding.util.SentryAuthorizerUtil.isLocalUri(SentryAuthorizerUtil.java:283)
> at
> org.apache.sentry.binding.util.SentryAuthorizerUtil.convert2HivePrivilegeObject(SentryAuthorizerUtil.java:267)
> at
> org.apache.sentry.binding.util.SentryAuthorizerUtil.convert2HivePrivilegeInfo(SentryAuthorizerUtil.java:220)
> at
> org.apache.sentry.binding.hive.authz.DefaultSentryAccessController.showPrivilegesByPrincipal(DefaultSentryAccessController.java:279)
> at
> org.apache.sentry.binding.hive.authz.DefaultSentryAccessController.showPrivileges(DefaultSentryAccessController.java:213)
> at
> org.apache.sentry.binding.hive.authz.SentryHiveAuthorizerImpl.showPrivileges(SentryHiveAuthorizerImpl.java:146)
> at org.apache.hadoop.hive.ql.exec.DDLTask.showGrants(DDLTask.java:746)
> at org.apache.hadoop.hive.ql.exec.DDLTask.execute(DDLTask.java:527)
> at org.apache.hadoop.hive.ql.exec.Task.executeTask(Task.java:199)
> at
> org.apache.hadoop.hive.ql.exec.TaskRunner.runSequential(TaskRunner.java:97)
> at org.apache.hadoop.hive.ql.Driver.launchTask(Driver.java:2250)
> at org.apache.hadoop.hive.ql.Driver.execute(Driver.java:1893)
> at org.apache.hadoop.hive.ql.Driver.runInternal(Driver.java:1613)
> at org.apache.hadoop.hive.ql.Driver.run(Driver.java:1332)
> ...
> 2019-02-08 05:53:58,663 ERROR org.apache.hadoop.hive.ql.Driver:
> [HiveServer2-Background-Pool: Thread-84]: FAILED: Execution Error, return
> code 1
> from org.apache.hadoop.hive.ql.exec.DDLTask. null
> {noformat}
> This appears to be happening because the show grant role logic is trying to
> construct a HivePrivilegeObject, which it wasn't doing in 1.8.0, and assumes
> the URI will have a scheme. See:
> {noformat}
> public static boolean isLocalUri(String uriString) throws
> URISyntaxException {
> URI uri = new URI(uriString);
> if (uri.getScheme().equalsIgnoreCase("file")) {
> return true;
> }
> return false;
> }
> {noformat}
> Because uri.getScheme() can return null, the equalsIgnoreCase() can result in
> an NPE.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2502) Sentry NN plug-in stops fetching updates from sentry server
[
https://issues.apache.org/jira/browse/SENTRY-2502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16775823#comment-16775823
]
Hadoop QA commented on SENTRY-2502:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12959871/SENTRY-2502.001.patch
against master.
{color:green}Overall:{color} +1 all checks pass
{color:green}SUCCESS:{color} all tests passed
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4394/console
This message is automatically generated.
> Sentry NN plug-in stops fetching updates from sentry server
> ---
>
> Key: SENTRY-2502
> URL: https://issues.apache.org/jira/browse/SENTRY-2502
> Project: Sentry
> Issue Type: Bug
> Components: Sentry
>Affects Versions: 2.2.0
>Reporter: kalyan kumar kalvagadda
>Assignee: kalyan kumar kalvagadda
>Priority: Major
> Fix For: 2.2.0
>
> Attachments: SENTRY-2502.001.patch, SENTRY-2502.002.patch
>
>
> Sentry plug-in in name node is stopping to fetch updates from sentry server
> when below sequence of events occurs.
> # Create a table
> # Add a single partition to it.
> # Rename the table created above.
> # Drop the partition added above
> # Add the partition again.
> # Rename the table
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2497) show grant role results in NPE when URI does not have scheme
[
https://issues.apache.org/jira/browse/SENTRY-2497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16775655#comment-16775655
]
Hadoop QA commented on SENTRY-2497:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12959840/sentry-2497.01.patch
against master.
{color:red}Overall:{color} -1 due to 3 errors
{color:red}ERROR:{color} mvn test exited 1
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestHmsNotificationProcessing
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestHmsNotificationProcessingWithOutSyncOnCreate
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4392/console
This message is automatically generated.
> show grant role results in NPE when URI does not have scheme
>
>
> Key: SENTRY-2497
> URL: https://issues.apache.org/jira/browse/SENTRY-2497
> Project: Sentry
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: Haley Reeve
>Assignee: Haley Reeve
>Priority: Major
> Attachments: sentry-2497.001.patch, sentry-2497.01.patch,
> sentry-2497.1.patch
>
>
> Sentry throws a NullPointerException when trying to run "show grant role" on
> a URI with no scheme associated with it. You can see the stacktrace in the
> HS2 logs:
> {noformat}
> HS2 logs are showing the stacktrace:
> 2019-02-08 05:53:58,650 INFO org.apache.hadoop.hive.ql.Driver:
> [HiveServer2-Background-Pool: Thread-84]: Executing
> command(queryId=hive_20190208
> 055358_a283626f-c906-4bd1-be50-43e2e9a6949b): show grant role uritest
> 2019-02-08 05:53:58,651 INFO org.apache.hadoop.hive.ql.Driver:
> [HiveServer2-Background-Pool: Thread-84]: Starting task [Stage-0:DDL] in
> serial m
> ode
> 2019-02-08 05:53:58,661 ERROR hive.ql.exec.DDLTask:
> [HiveServer2-Background-Pool: Thread-84]: java.lang.NullPointerException
> at
> org.apache.sentry.binding.util.SentryAuthorizerUtil.isLocalUri(SentryAuthorizerUtil.java:283)
> at
> org.apache.sentry.binding.util.SentryAuthorizerUtil.convert2HivePrivilegeObject(SentryAuthorizerUtil.java:267)
> at
> org.apache.sentry.binding.util.SentryAuthorizerUtil.convert2HivePrivilegeInfo(SentryAuthorizerUtil.java:220)
> at
> org.apache.sentry.binding.hive.authz.DefaultSentryAccessController.showPrivilegesByPrincipal(DefaultSentryAccessController.java:279)
> at
> org.apache.sentry.binding.hive.authz.DefaultSentryAccessController.showPrivileges(DefaultSentryAccessController.java:213)
> at
> org.apache.sentry.binding.hive.authz.SentryHiveAuthorizerImpl.showPrivileges(SentryHiveAuthorizerImpl.java:146)
> at org.apache.hadoop.hive.ql.exec.DDLTask.showGrants(DDLTask.java:746)
> at org.apache.hadoop.hive.ql.exec.DDLTask.execute(DDLTask.java:527)
> at org.apache.hadoop.hive.ql.exec.Task.executeTask(Task.java:199)
> at
> org.apache.hadoop.hive.ql.exec.TaskRunner.runSequential(TaskRunner.java:97)
> at org.apache.hadoop.hive.ql.Driver.launchTask(Driver.java:2250)
> at org.apache.hadoop.hive.ql.Driver.execute(Driver.java:1893)
> at org.apache.hadoop.hive.ql.Driver.runInternal(Driver.java:1613)
> at org.apache.hadoop.hive.ql.Driver.run(Driver.java:1332)
> ...
> 2019-02-08 05:53:58,663 ERROR org.apache.hadoop.hive.ql.Driver:
> [HiveServer2-Background-Pool: Thread-84]: FAILED: Execution Error, return
> code 1
> from org.apache.hadoop.hive.ql.exec.DDLTask. null
> {noformat}
> This appears to be happening because the show grant role logic is trying to
> construct a HivePrivilegeObject, which it wasn't doing in 1.8.0, and assumes
> the URI will have a scheme. See:
> {noformat}
> public static boolean isLocalUri(String uriString) throws
> URISyntaxException {
> URI uri = new URI(uriString);
> if (uri.getScheme().equalsIgnoreCase("file")) {
> return true;
> }
> return false;
> }
> {noformat}
> Because uri.getScheme() can return null, the equalsIgnoreCase() can result in
> an NPE.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2497) show grant role results in NPE when URI does not have scheme
[
https://issues.apache.org/jira/browse/SENTRY-2497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16775608#comment-16775608
]
Hadoop QA commented on SENTRY-2497:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12959846/sentry-2497.001.patch
against master.
{color:red}Overall:{color} -1 due to 2 errors
{color:red}ERROR:{color} mvn test exited 1
{color:red}ERROR:{color} Failed:
org.apache.sentry.provider.db.generic.service.persistent.TestPrivilegeOperatePersistence
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4393/console
This message is automatically generated.
> show grant role results in NPE when URI does not have scheme
>
>
> Key: SENTRY-2497
> URL: https://issues.apache.org/jira/browse/SENTRY-2497
> Project: Sentry
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: Haley Reeve
>Assignee: Haley Reeve
>Priority: Major
> Attachments: sentry-2497.001.patch, sentry-2497.01.patch,
> sentry-2497.1.patch
>
>
> Sentry throws a NullPointerException when trying to run "show grant role" on
> a URI with no scheme associated with it. You can see the stacktrace in the
> HS2 logs:
> {noformat}
> HS2 logs are showing the stacktrace:
> 2019-02-08 05:53:58,650 INFO org.apache.hadoop.hive.ql.Driver:
> [HiveServer2-Background-Pool: Thread-84]: Executing
> command(queryId=hive_20190208
> 055358_a283626f-c906-4bd1-be50-43e2e9a6949b): show grant role uritest
> 2019-02-08 05:53:58,651 INFO org.apache.hadoop.hive.ql.Driver:
> [HiveServer2-Background-Pool: Thread-84]: Starting task [Stage-0:DDL] in
> serial m
> ode
> 2019-02-08 05:53:58,661 ERROR hive.ql.exec.DDLTask:
> [HiveServer2-Background-Pool: Thread-84]: java.lang.NullPointerException
> at
> org.apache.sentry.binding.util.SentryAuthorizerUtil.isLocalUri(SentryAuthorizerUtil.java:283)
> at
> org.apache.sentry.binding.util.SentryAuthorizerUtil.convert2HivePrivilegeObject(SentryAuthorizerUtil.java:267)
> at
> org.apache.sentry.binding.util.SentryAuthorizerUtil.convert2HivePrivilegeInfo(SentryAuthorizerUtil.java:220)
> at
> org.apache.sentry.binding.hive.authz.DefaultSentryAccessController.showPrivilegesByPrincipal(DefaultSentryAccessController.java:279)
> at
> org.apache.sentry.binding.hive.authz.DefaultSentryAccessController.showPrivileges(DefaultSentryAccessController.java:213)
> at
> org.apache.sentry.binding.hive.authz.SentryHiveAuthorizerImpl.showPrivileges(SentryHiveAuthorizerImpl.java:146)
> at org.apache.hadoop.hive.ql.exec.DDLTask.showGrants(DDLTask.java:746)
> at org.apache.hadoop.hive.ql.exec.DDLTask.execute(DDLTask.java:527)
> at org.apache.hadoop.hive.ql.exec.Task.executeTask(Task.java:199)
> at
> org.apache.hadoop.hive.ql.exec.TaskRunner.runSequential(TaskRunner.java:97)
> at org.apache.hadoop.hive.ql.Driver.launchTask(Driver.java:2250)
> at org.apache.hadoop.hive.ql.Driver.execute(Driver.java:1893)
> at org.apache.hadoop.hive.ql.Driver.runInternal(Driver.java:1613)
> at org.apache.hadoop.hive.ql.Driver.run(Driver.java:1332)
> ...
> 2019-02-08 05:53:58,663 ERROR org.apache.hadoop.hive.ql.Driver:
> [HiveServer2-Background-Pool: Thread-84]: FAILED: Execution Error, return
> code 1
> from org.apache.hadoop.hive.ql.exec.DDLTask. null
> {noformat}
> This appears to be happening because the show grant role logic is trying to
> construct a HivePrivilegeObject, which it wasn't doing in 1.8.0, and assumes
> the URI will have a scheme. See:
> {noformat}
> public static boolean isLocalUri(String uriString) throws
> URISyntaxException {
> URI uri = new URI(uriString);
> if (uri.getScheme().equalsIgnoreCase("file")) {
> return true;
> }
> return false;
> }
> {noformat}
> Because uri.getScheme() can return null, the equalsIgnoreCase() can result in
> an NPE.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2497) show grant role results in NPE when URI does not have scheme
[
https://issues.apache.org/jira/browse/SENTRY-2497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16775387#comment-16775387
]
Hadoop QA commented on SENTRY-2497:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12959817/sentry-2497.1.patch
against master.
{color:red}Overall:{color} -1 due to 2 errors
{color:red}ERROR:{color} mvn test exited 1
{color:red}ERROR:{color} Failed:
org.apache.sentry.hdfs.TestSentryHDFSServiceProcessor
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4391/console
This message is automatically generated.
> show grant role results in NPE when URI does not have scheme
>
>
> Key: SENTRY-2497
> URL: https://issues.apache.org/jira/browse/SENTRY-2497
> Project: Sentry
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: Haley Reeve
>Assignee: Haley Reeve
>Priority: Major
> Attachments: sentry-2497.1.patch
>
>
> Sentry throws a NullPointerException when trying to run "show grant role" on
> a URI with no scheme associated with it. You can see the stacktrace in the
> HS2 logs:
> {noformat}
> HS2 logs are showing the stacktrace:
> 2019-02-08 05:53:58,650 INFO org.apache.hadoop.hive.ql.Driver:
> [HiveServer2-Background-Pool: Thread-84]: Executing
> command(queryId=hive_20190208
> 055358_a283626f-c906-4bd1-be50-43e2e9a6949b): show grant role uritest
> 2019-02-08 05:53:58,651 INFO org.apache.hadoop.hive.ql.Driver:
> [HiveServer2-Background-Pool: Thread-84]: Starting task [Stage-0:DDL] in
> serial m
> ode
> 2019-02-08 05:53:58,661 ERROR hive.ql.exec.DDLTask:
> [HiveServer2-Background-Pool: Thread-84]: java.lang.NullPointerException
> at
> org.apache.sentry.binding.util.SentryAuthorizerUtil.isLocalUri(SentryAuthorizerUtil.java:283)
> at
> org.apache.sentry.binding.util.SentryAuthorizerUtil.convert2HivePrivilegeObject(SentryAuthorizerUtil.java:267)
> at
> org.apache.sentry.binding.util.SentryAuthorizerUtil.convert2HivePrivilegeInfo(SentryAuthorizerUtil.java:220)
> at
> org.apache.sentry.binding.hive.authz.DefaultSentryAccessController.showPrivilegesByPrincipal(DefaultSentryAccessController.java:279)
> at
> org.apache.sentry.binding.hive.authz.DefaultSentryAccessController.showPrivileges(DefaultSentryAccessController.java:213)
> at
> org.apache.sentry.binding.hive.authz.SentryHiveAuthorizerImpl.showPrivileges(SentryHiveAuthorizerImpl.java:146)
> at org.apache.hadoop.hive.ql.exec.DDLTask.showGrants(DDLTask.java:746)
> at org.apache.hadoop.hive.ql.exec.DDLTask.execute(DDLTask.java:527)
> at org.apache.hadoop.hive.ql.exec.Task.executeTask(Task.java:199)
> at
> org.apache.hadoop.hive.ql.exec.TaskRunner.runSequential(TaskRunner.java:97)
> at org.apache.hadoop.hive.ql.Driver.launchTask(Driver.java:2250)
> at org.apache.hadoop.hive.ql.Driver.execute(Driver.java:1893)
> at org.apache.hadoop.hive.ql.Driver.runInternal(Driver.java:1613)
> at org.apache.hadoop.hive.ql.Driver.run(Driver.java:1332)
> ...
> 2019-02-08 05:53:58,663 ERROR org.apache.hadoop.hive.ql.Driver:
> [HiveServer2-Background-Pool: Thread-84]: FAILED: Execution Error, return
> code 1
> from org.apache.hadoop.hive.ql.exec.DDLTask. null
> {noformat}
> This appears to be happening because the show grant role logic is trying to
> construct a HivePrivilegeObject, which it wasn't doing in 1.8.0, and assumes
> the URI will have a scheme. See:
> {noformat}
> public static boolean isLocalUri(String uriString) throws
> URISyntaxException {
> URI uri = new URI(uriString);
> if (uri.getScheme().equalsIgnoreCase("file")) {
> return true;
> }
> return false;
> }
> {noformat}
> Because uri.getScheme() can return null, the equalsIgnoreCase() can result in
> an NPE.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2501) Add cache for HMS server filtering hook
[
https://issues.apache.org/jira/browse/SENTRY-2501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16773675#comment-16773675
]
Hadoop QA commented on SENTRY-2501:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12959549/SENTRY-2501.002.patch
against master.
{color:green}Overall:{color} +1 all checks pass
{color:green}SUCCESS:{color} all tests passed
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4390/console
This message is automatically generated.
> Add cache for HMS server filtering hook
> ---
>
> Key: SENTRY-2501
> URL: https://issues.apache.org/jira/browse/SENTRY-2501
> Project: Sentry
> Issue Type: Bug
> Components: Sentry
>Affects Versions: 2.2.0
>Reporter: Na Li
>Assignee: Na Li
>Priority: Major
> Attachments: SENTRY-2501.001.patch, SENTRY-2501.002.patch,
> SENTRY-2501.002.patch
>
>
> The filter in SentryMetaStoreFilterHook does not cache sentry privileges.
> Therefore, for each item in the list, sentry client has to get privileges
> from sentry server.
> To improve performance, we need to add cache in SentryMetaStoreFilterHook
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2501) Add cache for HMS server filtering hook
[
https://issues.apache.org/jira/browse/SENTRY-2501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16773537#comment-16773537
]
Hadoop QA commented on SENTRY-2501:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12959504/SENTRY-2501.002.patch
against master.
{color:red}Overall:{color} -1 due to an error
{color:red}ERROR:{color} mvn test exited 1
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4389/console
This message is automatically generated.
> Add cache for HMS server filtering hook
> ---
>
> Key: SENTRY-2501
> URL: https://issues.apache.org/jira/browse/SENTRY-2501
> Project: Sentry
> Issue Type: Bug
> Components: Sentry
>Affects Versions: 2.2.0
>Reporter: Na Li
>Assignee: Na Li
>Priority: Major
> Attachments: SENTRY-2501.001.patch, SENTRY-2501.002.patch
>
>
> The filter in SentryMetaStoreFilterHook does not cache sentry privileges.
> Therefore, for each item in the list, sentry client has to get privileges
> from sentry server.
> To improve performance, we need to add cache in SentryMetaStoreFilterHook
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2500) CREATE on server does not provide HMS server side read authorization for get_all_tables(database_name)
[
https://issues.apache.org/jira/browse/SENTRY-2500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16773529#comment-16773529
]
Hadoop QA commented on SENTRY-2500:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12959497/SENTRY-2500.005.patch
against master.
{color:green}Overall:{color} +1 all checks pass
{color:green}SUCCESS:{color} all tests passed
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4388/console
This message is automatically generated.
> CREATE on server does not provide HMS server side read authorization for
> get_all_tables(database_name)
> --
>
> Key: SENTRY-2500
> URL: https://issues.apache.org/jira/browse/SENTRY-2500
> Project: Sentry
> Issue Type: Bug
> Components: Sentry
>Affects Versions: 2.2.0
>Reporter: Na Li
>Assignee: Na Li
>Priority: Major
> Attachments: SENTRY-2500.001.patch, SENTRY-2500.002.patch,
> SENTRY-2500.003.patch, SENTRY-2500.004.patch, SENTRY-2500.005.patch,
> SENTRY-2500.005.patch
>
>
> If a user has CREATE privileges on server, they are not able to see any
> tables with the direct call to the HMS api method get_all_tables when server
> side filtering is enabled.
> Ideally, CREATE privileges on server should give one an unfiltered view of
> the tables when the user with that privilege calls HMS api method
> get_all_tables(database_name).
> The solution is to add "CREATE" privilege as one of the required privileges
> (any one of the privilege will allow) in listing table operation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2500) CREATE on server does not provide HMS server side read authorization for get_all_tables(database_name)
[
https://issues.apache.org/jira/browse/SENTRY-2500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16773347#comment-16773347
]
Hadoop QA commented on SENTRY-2500:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12959459/SENTRY-2500.005.patch
against master.
{color:red}Overall:{color} -1 due to 8 errors
{color:red}ERROR:{color} mvn test exited 1
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestOwnerPrivileges
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestHmsNotificationProcessing
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestHmsNotificationProcessingWithOutHdfsSync
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestDbPrivilegeCleanupOnDrop
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestHmsNotificationProcessingWithOutSyncOnCreate
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hdfs.TestHDFSIntegrationTogglingConf
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestHmsNotificationProcessingWithOutSyncOnDrop
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4387/console
This message is automatically generated.
> CREATE on server does not provide HMS server side read authorization for
> get_all_tables(database_name)
> --
>
> Key: SENTRY-2500
> URL: https://issues.apache.org/jira/browse/SENTRY-2500
> Project: Sentry
> Issue Type: Bug
> Components: Sentry
>Affects Versions: 2.2.0
>Reporter: Na Li
>Assignee: Na Li
>Priority: Major
> Attachments: SENTRY-2500.001.patch, SENTRY-2500.002.patch,
> SENTRY-2500.003.patch, SENTRY-2500.004.patch, SENTRY-2500.005.patch
>
>
> If a user has CREATE privileges on server, they are not able to see any
> tables with the direct call to the HMS api method get_all_tables when server
> side filtering is enabled.
> Ideally, CREATE privileges on server should give one an unfiltered view of
> the tables when the user with that privilege calls HMS api method
> get_all_tables(database_name).
> The solution is to add "CREATE" privilege as one of the required privileges
> (any one of the privilege will allow) in listing table operation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2500) CREATE on server does not provide HMS server side read authorization for get_all_tables(database_name)
[
https://issues.apache.org/jira/browse/SENTRY-2500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16772412#comment-16772412
]
Hadoop QA commented on SENTRY-2500:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12959332/SENTRY-2500.004.patch
against master.
{color:red}Overall:{color} -1 due to 2 errors
{color:red}ERROR:{color} mvn test exited 1
{color:red}ERROR:{color} Failed:
org.apache.sentry.hdfs.TestSentryHDFSServiceProcessor
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4386/console
This message is automatically generated.
> CREATE on server does not provide HMS server side read authorization for
> get_all_tables(database_name)
> --
>
> Key: SENTRY-2500
> URL: https://issues.apache.org/jira/browse/SENTRY-2500
> Project: Sentry
> Issue Type: Bug
> Components: Sentry
>Affects Versions: 2.2.0
>Reporter: Na Li
>Assignee: Na Li
>Priority: Major
> Attachments: SENTRY-2500.001.patch, SENTRY-2500.002.patch,
> SENTRY-2500.003.patch, SENTRY-2500.004.patch
>
>
> If a user has CREATE privileges on server, they are not able to see any
> tables with the direct call to the HMS api method get_all_tables when server
> side filtering is enabled.
> Ideally, CREATE privileges on server should give one an unfiltered view of
> the tables when the user with that privilege calls HMS api method
> get_all_tables(database_name).
> The solution is to add "CREATE" privilege as one of the required privileges
> (any one of the privilege will allow) in listing table operation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2501) Add cache for HMS server filtering hook
[
https://issues.apache.org/jira/browse/SENTRY-2501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16772398#comment-16772398
]
Hadoop QA commented on SENTRY-2501:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12959331/SENTRY-2501.001.patch
against master.
{color:red}Overall:{color} -1 due to 3 errors
{color:red}ERROR:{color} mvn test exited 1
{color:red}ERROR:{color} Failed:
org.apache.sentry.binding.metastore.TestSentryMetaStoreFilterHook
{color:red}ERROR:{color} Failed:
org.apache.sentry.binding.metastore.TestSentryMetaStoreFilterHook
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4385/console
This message is automatically generated.
> Add cache for HMS server filtering hook
> ---
>
> Key: SENTRY-2501
> URL: https://issues.apache.org/jira/browse/SENTRY-2501
> Project: Sentry
> Issue Type: Bug
> Components: Sentry
>Affects Versions: 2.2.0
>Reporter: Na Li
>Assignee: Na Li
>Priority: Major
> Attachments: SENTRY-2501.001.patch
>
>
> The filter in SentryMetaStoreFilterHook does not cache sentry privileges.
> Therefore, for each item in the list, sentry client has to get privileges
> from sentry server.
> To improve performance, we need to add cache in SentryMetaStoreFilterHook
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2500) CREATE on server does not provide HMS server side read authorization for get_all_tables(database_name)
[
https://issues.apache.org/jira/browse/SENTRY-2500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16772349#comment-16772349
]
Hadoop QA commented on SENTRY-2500:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12959310/SENTRY-2500.003.patch
against master.
{color:red}Overall:{color} -1 due to 4 errors
{color:red}ERROR:{color} mvn test exited 1
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hive.TestShowMetadataPrivileges
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hive.TestShowMetadataPrivileges
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hive.TestShowMetadataPrivileges
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4384/console
This message is automatically generated.
> CREATE on server does not provide HMS server side read authorization for
> get_all_tables(database_name)
> --
>
> Key: SENTRY-2500
> URL: https://issues.apache.org/jira/browse/SENTRY-2500
> Project: Sentry
> Issue Type: Bug
> Components: Sentry
>Affects Versions: 2.2.0
>Reporter: Na Li
>Assignee: Na Li
>Priority: Major
> Attachments: SENTRY-2500.001.patch, SENTRY-2500.002.patch,
> SENTRY-2500.003.patch
>
>
> If a user has CREATE privileges on server, they are not able to see any
> tables with the direct call to the HMS api method get_all_tables when server
> side filtering is enabled.
> Ideally, CREATE privileges on server should give one an unfiltered view of
> the tables when the user with that privilege calls HMS api method
> get_all_tables(database_name).
> The solution is to add "CREATE" privilege as one of the required privileges
> (any one of the privilege will allow) in listing table operation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2500) CREATE on server does not provide HMS server side read authorization for get_all_tables(database_name)
[
https://issues.apache.org/jira/browse/SENTRY-2500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16772133#comment-16772133
]
Hadoop QA commented on SENTRY-2500:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12959283/SENTRY-2500.002.patch
against master.
{color:red}Overall:{color} -1 due to an error
{color:red}ERROR:{color} failed to build with patch (exit code 1)
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4383/console
This message is automatically generated.
> CREATE on server does not provide HMS server side read authorization for
> get_all_tables(database_name)
> --
>
> Key: SENTRY-2500
> URL: https://issues.apache.org/jira/browse/SENTRY-2500
> Project: Sentry
> Issue Type: Bug
> Components: Sentry
>Affects Versions: 2.2.0
>Reporter: Na Li
>Assignee: Na Li
>Priority: Major
> Attachments: SENTRY-2500.001.patch, SENTRY-2500.002.patch
>
>
> If a user has CREATE privileges on server, they are not able to see any
> tables with the direct call to the HMS api method get_all_tables when server
> side filtering is enabled.
> Ideally, CREATE privileges on server should give one an unfiltered view of
> the tables when the user with that privilege calls HMS api method
> get_all_tables(database_name).
> The solution is to add "CREATE" privilege as one of the required privileges
> (any one of the privilege will allow) in listing table operation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-1392) Umask 077 leads to Hive crash with Sentry
[
https://issues.apache.org/jira/browse/SENTRY-1392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16772122#comment-16772122
]
Hadoop QA commented on SENTRY-1392:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12959258/SENTRY-1392.002.patch
against master.
{color:green}Overall:{color} +1 all checks pass
{color:green}SUCCESS:{color} all tests passed
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4381/console
This message is automatically generated.
> Umask 077 leads to Hive crash with Sentry
> -
>
> Key: SENTRY-1392
> URL: https://issues.apache.org/jira/browse/SENTRY-1392
> Project: Sentry
> Issue Type: Bug
> Components: Hive Binding
>Affects Versions: 1.5.1
> Environment: CDH 5.7.1, Sentry 1.5.1
>Reporter: Marek Sušický
>Assignee: Lars Francke
>Priority: Major
> Labels: easyfix
> Attachments: SENTRY-1392.001.patch, SENTRY-1392.002.patch
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Hi,
> I installed CDH with Sentry and in Impala everything works fine. We have
> security demands that umask 077 should be used, so I changed default 022 to
> 077.
> But Hive says "No databases found.". In /var/log/hive is following stacktrace:
> 2016-07-08 16:05:58,085 WARN
> org.apache.sentry.binding.metastore.SentryMetaStoreFilterHook:
> [HiveServer2-Handler-Pool: Thread-54]: Error getting DB list
> org.apache.hadoop.hive.ql.parse.SemanticException:
> org.apache.sentry.binding.hive.conf.InvalidConfigurationException:
> fs.permissions.umask-mode should be 077 in non-testing mode
> at
> org.apache.sentry.binding.hive.HiveAuthzBindingHook.getHiveBindingWithPrivilegeCache(HiveAuthzBindingHook.java:978)
> at
> org.apache.sentry.binding.hive.HiveAuthzBindingHook.filterShowDatabases(HiveAuthzBindingHook.java:836)
> at
> org.apache.sentry.binding.metastore.SentryMetaStoreFilterHook.filterDb(SentryMetaStoreFilterHook.java:131)
> at
> org.apache.sentry.binding.metastore.SentryMetaStoreFilterHook.filterDatabases(SentryMetaStoreFilterHook.java:59)
> at
> org.apache.hadoop.hive.metastore.HiveMetaStoreClient.getDatabases(HiveMetaStoreClient.java:1014)
> ..
> ..
> Caused by: org.apache.sentry.binding.hive.conf.InvalidConfigurationException:
> fs.permissions.umask-mode should be 077 in non-testing mode
> at
> org.apache.sentry.binding.hive.authz.HiveAuthzBinding.validateHiveServer2Config(HiveAuthzBinding.java:196)
> at
> org.apache.sentry.binding.hive.authz.HiveAuthzBinding.validateHiveConfig(HiveAuthzBinding.java:148)
> at
> org.apache.sentry.binding.hive.authz.HiveAuthzBinding.(HiveAuthzBinding.java:96)
> at
> org.apache.sentry.binding.hive.HiveAuthzBindingHook.getHiveBindingWithPrivilegeCache(HiveAuthzBindingHook.java:974)
> ... 30 more
> I investigated this issue and in sourcecode I found following lines:
> if("077".equalsIgnoreCase(defaultUmask)) {
> LOG.error("HiveServer2 required a default umask of 077");
> throw new
> InvalidConfigurationException(CommonConfigurationKeys.FS_PERMISSIONS_UMASK_KEY
> +
> " should be 077 in non-testing mode");
> }
> I think, that one exclamation mark is missing:
> if (!"077".equalsIgnoreCase(defaultUmask)).
> Thanks
> Marek
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2500) CREATE on server does not provide HMS server side read authorization for get_all_tables(database_name)
[
https://issues.apache.org/jira/browse/SENTRY-2500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16772056#comment-16772056
]
Hadoop QA commented on SENTRY-2500:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12959271/SENTRY-2500.001.patch
against master.
{color:red}Overall:{color} -1 due to an error
{color:red}ERROR:{color} failed to build with patch (exit code 1)
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4382/console
This message is automatically generated.
> CREATE on server does not provide HMS server side read authorization for
> get_all_tables(database_name)
> --
>
> Key: SENTRY-2500
> URL: https://issues.apache.org/jira/browse/SENTRY-2500
> Project: Sentry
> Issue Type: Bug
> Components: Sentry
>Affects Versions: 2.2.0
>Reporter: Na Li
>Assignee: Na Li
>Priority: Major
> Attachments: SENTRY-2500.001.patch
>
>
> If a user has CREATE privileges on server, they are not able to see any
> tables with the direct call to the HMS api method get_all_tables when server
> side filtering is enabled.
> Ideally, CREATE privileges on server should give one an unfiltered view of
> the tables when the user with that privilege calls HMS api method
> get_all_tables(database_name).
> The solution is to add "CREATE" privilege as one of the required privileges
> (any one of the privilege will allow) in listing table operation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-1392) Umask 077 leads to Hive crash with Sentry
[
https://issues.apache.org/jira/browse/SENTRY-1392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16771958#comment-16771958
]
Hadoop QA commented on SENTRY-1392:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12959248/SENTRY-1392.001.patch
against master.
{color:red}Overall:{color} -1 due to an error
{color:red}ERROR:{color} failed to build with patch (exit code 1)
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4380/console
This message is automatically generated.
> Umask 077 leads to Hive crash with Sentry
> -
>
> Key: SENTRY-1392
> URL: https://issues.apache.org/jira/browse/SENTRY-1392
> Project: Sentry
> Issue Type: Bug
> Components: Hive Binding
>Affects Versions: 1.5.1
> Environment: CDH 5.7.1, Sentry 1.5.1
>Reporter: Marek Sušický
>Assignee: Lars Francke
>Priority: Major
> Labels: easyfix
> Attachments: SENTRY-1392.001.patch
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Hi,
> I installed CDH with Sentry and in Impala everything works fine. We have
> security demands that umask 077 should be used, so I changed default 022 to
> 077.
> But Hive says "No databases found.". In /var/log/hive is following stacktrace:
> 2016-07-08 16:05:58,085 WARN
> org.apache.sentry.binding.metastore.SentryMetaStoreFilterHook:
> [HiveServer2-Handler-Pool: Thread-54]: Error getting DB list
> org.apache.hadoop.hive.ql.parse.SemanticException:
> org.apache.sentry.binding.hive.conf.InvalidConfigurationException:
> fs.permissions.umask-mode should be 077 in non-testing mode
> at
> org.apache.sentry.binding.hive.HiveAuthzBindingHook.getHiveBindingWithPrivilegeCache(HiveAuthzBindingHook.java:978)
> at
> org.apache.sentry.binding.hive.HiveAuthzBindingHook.filterShowDatabases(HiveAuthzBindingHook.java:836)
> at
> org.apache.sentry.binding.metastore.SentryMetaStoreFilterHook.filterDb(SentryMetaStoreFilterHook.java:131)
> at
> org.apache.sentry.binding.metastore.SentryMetaStoreFilterHook.filterDatabases(SentryMetaStoreFilterHook.java:59)
> at
> org.apache.hadoop.hive.metastore.HiveMetaStoreClient.getDatabases(HiveMetaStoreClient.java:1014)
> ..
> ..
> Caused by: org.apache.sentry.binding.hive.conf.InvalidConfigurationException:
> fs.permissions.umask-mode should be 077 in non-testing mode
> at
> org.apache.sentry.binding.hive.authz.HiveAuthzBinding.validateHiveServer2Config(HiveAuthzBinding.java:196)
> at
> org.apache.sentry.binding.hive.authz.HiveAuthzBinding.validateHiveConfig(HiveAuthzBinding.java:148)
> at
> org.apache.sentry.binding.hive.authz.HiveAuthzBinding.(HiveAuthzBinding.java:96)
> at
> org.apache.sentry.binding.hive.HiveAuthzBindingHook.getHiveBindingWithPrivilegeCache(HiveAuthzBindingHook.java:974)
> ... 30 more
> I investigated this issue and in sourcecode I found following lines:
> if("077".equalsIgnoreCase(defaultUmask)) {
> LOG.error("HiveServer2 required a default umask of 077");
> throw new
> InvalidConfigurationException(CommonConfigurationKeys.FS_PERMISSIONS_UMASK_KEY
> +
> " should be 077 in non-testing mode");
> }
> I think, that one exclamation mark is missing:
> if (!"077".equalsIgnoreCase(defaultUmask)).
> Thanks
> Marek
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2495) Support Conjunctive Matching in Solr QueryDocAuthorizationComponent
[
https://issues.apache.org/jira/browse/SENTRY-2495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16770376#comment-16770376
]
Hadoop QA commented on SENTRY-2495:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12959016/SENTRY-2495.patch
against master.
{color:red}Overall:{color} -1 due to an error
{color:red}ERROR:{color} failed to build with patch (exit code 1)
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4379/console
This message is automatically generated.
> Support Conjunctive Matching in Solr QueryDocAuthorizationComponent
> ---
>
> Key: SENTRY-2495
> URL: https://issues.apache.org/jira/browse/SENTRY-2495
> Project: Sentry
> Issue Type: Sub-task
>Reporter: Tristan Stevens
>Assignee: Tristan Stevens
>Priority: Major
> Attachments: SENTRY-2495.patch.001, SENTRY-2495.patch.002
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2498) Exception while deleting paths that does't exist
[
https://issues.apache.org/jira/browse/SENTRY-2498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16769583#comment-16769583
]
Hadoop QA commented on SENTRY-2498:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12958909/SENTRY-2498.001.patch
against master.
{color:green}Overall:{color} +1 all checks pass
{color:green}SUCCESS:{color} all tests passed
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4378/console
This message is automatically generated.
> Exception while deleting paths that does't exist
>
>
> Key: SENTRY-2498
> URL: https://issues.apache.org/jira/browse/SENTRY-2498
> Project: Sentry
> Issue Type: Bug
> Components: Sentry
>Affects Versions: 2.2.0
>Reporter: kalyan kumar kalvagadda
>Assignee: kalyan kumar kalvagadda
>Priority: Major
> Fix For: 2.2.0
>
> Attachments: SENTRY-2498.001.patch, SENTRY-2498.001.patch
>
>
> Currently, HMSPaths is throwing an exception while deleting the paths for an
> object that is not known. Here is the stack trace for the exception
> {noformat}
> 2019-02-13 10:19:16,351 WARN org.apache.sentry.hdfs.SentryAuthorizationInfo:
> Failed to update, will retry in [3]ms, error:
> java.lang.NullPointerException
> at
> org.apache.sentry.hdfs.HMSPaths.deletePathsFromAuthzObject(HMSPaths.java:801)
> at
> org.apache.sentry.hdfs.UpdateableAuthzPaths.applyPartialUpdate(UpdateableAuthzPaths.java:155)
> at
> org.apache.sentry.hdfs.UpdateableAuthzPaths.updatePartial(UpdateableAuthzPaths.java:89)
> at
> org.apache.sentry.hdfs.SentryAuthorizationInfo.processUpdates(SentryAuthorizationInfo.java:202)
> at
> org.apache.sentry.hdfs.SentryAuthorizationInfo.update(SentryAuthorizationInfo.java:135)
> at
> org.apache.sentry.hdfs.SentryAuthorizationInfo.run(SentryAuthorizationInfo.java:220)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> 2019-02-13 10:19:17,670 INFO SecurityLogger.
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2498) Exception while deleting paths that does't exist
[
https://issues.apache.org/jira/browse/SENTRY-2498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16768826#comment-16768826
]
Hadoop QA commented on SENTRY-2498:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12958795/SENTRY-2498.001.patch
against master.
{color:red}Overall:{color} -1 due to 2 errors
{color:red}ERROR:{color} mvn test exited 1
{color:red}ERROR:{color} Failed:
org.apache.sentry.hdfs.TestSentryHDFSServiceProcessor
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4377/console
This message is automatically generated.
> Exception while deleting paths that does't exist
>
>
> Key: SENTRY-2498
> URL: https://issues.apache.org/jira/browse/SENTRY-2498
> Project: Sentry
> Issue Type: Bug
> Components: Sentry
>Affects Versions: 2.2.0
>Reporter: kalyan kumar kalvagadda
>Assignee: kalyan kumar kalvagadda
>Priority: Major
> Fix For: 2.2.0
>
> Attachments: SENTRY-2498.001.patch
>
>
> Currently, HMSPaths is throwing an exception while deleting the paths for an
> object that is not known. Here is the stack trace for the exception
> {noformat}
> 2019-02-13 10:19:16,351 WARN org.apache.sentry.hdfs.SentryAuthorizationInfo:
> Failed to update, will retry in [3]ms, error:
> java.lang.NullPointerException
> at
> org.apache.sentry.hdfs.HMSPaths.deletePathsFromAuthzObject(HMSPaths.java:801)
> at
> org.apache.sentry.hdfs.UpdateableAuthzPaths.applyPartialUpdate(UpdateableAuthzPaths.java:155)
> at
> org.apache.sentry.hdfs.UpdateableAuthzPaths.updatePartial(UpdateableAuthzPaths.java:89)
> at
> org.apache.sentry.hdfs.SentryAuthorizationInfo.processUpdates(SentryAuthorizationInfo.java:202)
> at
> org.apache.sentry.hdfs.SentryAuthorizationInfo.update(SentryAuthorizationInfo.java:135)
> at
> org.apache.sentry.hdfs.SentryAuthorizationInfo.run(SentryAuthorizationInfo.java:220)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> 2019-02-13 10:19:17,670 INFO SecurityLogger.
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2492) Consecutive ALL grants get deleted when multiple roles have ALL grants on that object
[
https://issues.apache.org/jira/browse/SENTRY-2492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16767745#comment-16767745
]
Hadoop QA commented on SENTRY-2492:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12958633/SENTRY-2492.02.patch
against master.
{color:green}Overall:{color} +1 all checks pass
{color:green}SUCCESS:{color} all tests passed
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4376/console
This message is automatically generated.
> Consecutive ALL grants get deleted when multiple roles have ALL grants on
> that object
> -
>
> Key: SENTRY-2492
> URL: https://issues.apache.org/jira/browse/SENTRY-2492
> Project: Sentry
> Issue Type: Bug
> Components: Sentry
>Affects Versions: 2.1.0
>Reporter: Arjun Mishra
>Assignee: Arjun Mishra
>Priority: Major
> Attachments: SENTRY-2492.01.patch, SENTRY-2492.02.patch
>
>
> Have multiple roles with ALL grant on the same object. Then repeat grant ALL
> on object to a any role. That role will lose its grant
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2492) Consecutive ALL grants get deleted when multiple roles have ALL grants on that object
[
https://issues.apache.org/jira/browse/SENTRY-2492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16766697#comment-16766697
]
Hadoop QA commented on SENTRY-2492:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12958472/SENTRY-2492.01.patch
against master.
{color:green}Overall:{color} +1 all checks pass
{color:green}SUCCESS:{color} all tests passed
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4375/console
This message is automatically generated.
> Consecutive ALL grants get deleted when multiple roles have ALL grants on
> that object
> -
>
> Key: SENTRY-2492
> URL: https://issues.apache.org/jira/browse/SENTRY-2492
> Project: Sentry
> Issue Type: Bug
> Components: Sentry
>Affects Versions: 2.1.0
>Reporter: Arjun Mishra
>Assignee: Arjun Mishra
>Priority: Major
> Attachments: SENTRY-2492.01.patch
>
>
> Have multiple roles with ALL grant on the same object. Then repeat grant ALL
> on object to a any role. That role will lose its grant
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2494) Fix TestRollingFileWithoutDeleteAppender test case testFileNamePattern
[
https://issues.apache.org/jira/browse/SENTRY-2494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16765382#comment-16765382
]
Hadoop QA commented on SENTRY-2494:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12958288/SENTRY-2494.001.patch
against master.
{color:green}Overall:{color} +1 all checks pass
{color:green}SUCCESS:{color} all tests passed
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4374/console
This message is automatically generated.
> Fix TestRollingFileWithoutDeleteAppender test case testFileNamePattern
> --
>
> Key: SENTRY-2494
> URL: https://issues.apache.org/jira/browse/SENTRY-2494
> Project: Sentry
> Issue Type: Bug
> Components: Sentry
>Affects Versions: 2.0.1
>Reporter: Arjun Mishra
>Assignee: Arjun Mishra
>Priority: Major
> Attachments: SENTRY-2494.001.patch, SENTRY-2494.01.patch
>
>
> The log size is set to 10 bytes. However if the message size is 15 bytes, it
> creates a 15, 15 and 0 byte file ( which is sometimes flaky)
> Explanation:
> Before we logged a string that was at 15 bytes each. The assumption was
> Logger would split that across 2 files but it never did that. It would put 15
> bytes of line on one file.
> Previously we had 2 log statements:
> debug."123456789012345";
> debug."123456789012345";
> The file being created was "123456789012345", "123456789012345", "" (LAST ONE
> empty)
> as opposed to "1234567890", "1234512345", "6789012345"
> The above output would be flaky because LOGGER.appender did not handle a LONG
> string properly. It would sometimes generate two files with
> "123456789012345", "" (LAST ONE empty)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2494) Fix TestRollingFileWithoutDeleteAppender test case testFileNamePattern
[
https://issues.apache.org/jira/browse/SENTRY-2494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16765251#comment-16765251
]
Hadoop QA commented on SENTRY-2494:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12958280/SENTRY-2494.01.patch
against master.
{color:red}Overall:{color} -1 due to 2 errors
{color:red}ERROR:{color} mvn test exited 1
{color:red}ERROR:{color} Failed:
org.apache.sentry.hdfs.TestSentryHDFSServiceProcessor
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4373/console
This message is automatically generated.
> Fix TestRollingFileWithoutDeleteAppender test case testFileNamePattern
> --
>
> Key: SENTRY-2494
> URL: https://issues.apache.org/jira/browse/SENTRY-2494
> Project: Sentry
> Issue Type: Bug
> Components: Sentry
>Affects Versions: 2.0.1
>Reporter: Arjun Mishra
>Assignee: Arjun Mishra
>Priority: Major
> Attachments: SENTRY-2494.01.patch
>
>
> The log size is set to 10 bytes. However if the message size is 15 bytes, it
> creates a 15, 15 and 0 byte file ( which is sometimes flaky)
> Explanation:
> Before we logged a string that was at 15 bytes each. The assumption was
> Logger would split that across 2 files but it never did that. It would put 15
> bytes of line on one file.
> Previously we had 2 log statements:
> debug."123456789012345";
> debug."123456789012345";
> The file being created was "123456789012345", "123456789012345", "" (LAST ONE
> empty)
> as opposed to "1234567890", "1234512345", "6789012345"
> The above output would be flaky because LOGGER.appender did not handle a LONG
> string properly. It would sometimes generate two files with
> "123456789012345", "" (LAST ONE empty)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2146) Add better error handling to ResourceAuthorizationProvider and improve logging in related classes
[
https://issues.apache.org/jira/browse/SENTRY-2146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16764343#comment-16764343
]
Hadoop QA commented on SENTRY-2146:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12958155/SENTRY-2146.005.patch
against master.
{color:green}Overall:{color} +1 all checks pass
{color:green}SUCCESS:{color} all tests passed
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4372/console
This message is automatically generated.
> Add better error handling to ResourceAuthorizationProvider and improve
> logging in related classes
> -
>
> Key: SENTRY-2146
> URL: https://issues.apache.org/jira/browse/SENTRY-2146
> Project: Sentry
> Issue Type: Bug
> Components: Sentry
>Affects Versions: 2.0.0
>Reporter: Arjun Mishra
>Assignee: Arjun Mishra
>Priority: Major
> Attachments: SENTRY-2146.002.patch, SENTRY-2146.005.patch,
> SENTRY-2146.01.patch, SENTRY-2146.02.patch, SENTRY-2146.03.patch,
> SENTRY-2146.04.patch, SENTRY-2146.05.patch
>
>
> There are a bunch of improvements that should be made to
> ResourceAuthorizationProvider. For example, exceptions thrown by
> privilegeFactory.createPrivilege are not gracefully handled. Makes debugging
> hard.
> We also need to add a lot more logging to related classes
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2146) Add better error handling to ResourceAuthorizationProvider and improve logging in related classes
[
https://issues.apache.org/jira/browse/SENTRY-2146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16764034#comment-16764034
]
Hadoop QA commented on SENTRY-2146:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12958098/SENTRY-2146.05.patch
against master.
{color:red}Overall:{color} -1 due to 2 errors
{color:red}ERROR:{color} mvn test exited 1
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.hdfs.TestHDFSIntegrationWithHA
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4371/console
This message is automatically generated.
> Add better error handling to ResourceAuthorizationProvider and improve
> logging in related classes
> -
>
> Key: SENTRY-2146
> URL: https://issues.apache.org/jira/browse/SENTRY-2146
> Project: Sentry
> Issue Type: Bug
> Components: Sentry
>Affects Versions: 2.0.0
>Reporter: Arjun Mishra
>Assignee: Arjun Mishra
>Priority: Major
> Attachments: SENTRY-2146.002.patch, SENTRY-2146.01.patch,
> SENTRY-2146.02.patch, SENTRY-2146.03.patch, SENTRY-2146.04.patch,
> SENTRY-2146.05.patch
>
>
> There are a bunch of improvements that should be made to
> ResourceAuthorizationProvider. For example, exceptions thrown by
> privilegeFactory.createPrivilege are not gracefully handled. Makes debugging
> hard.
> We also need to add a lot more logging to related classes
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2440) Add a new thrift API for checking if a user is in admin group
[
https://issues.apache.org/jira/browse/SENTRY-2440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16763254#comment-16763254
]
Hadoop QA commented on SENTRY-2440:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12957989/SENTRY-2440.001.patch
against master.
{color:green}Overall:{color} +1 all checks pass
{color:green}SUCCESS:{color} all tests passed
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4370/console
This message is automatically generated.
> Add a new thrift API for checking if a user is in admin group
> -
>
> Key: SENTRY-2440
> URL: https://issues.apache.org/jira/browse/SENTRY-2440
> Project: Sentry
> Issue Type: Improvement
>Reporter: Hao Hao
>Assignee: Hao Hao
>Priority: Major
> Attachments: SENTRY-2440.001.patch
>
>
> It can be helpful to Sentry client if there is a way to tell if the requestor
> user is within admin group. In order to recognize failure earlier than
> actually making a call to privileged API such as 'create_role', 'drop_role'.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2146) Add better error handling to ResourceAuthorizationProvider and improve logging in related classes
[
https://issues.apache.org/jira/browse/SENTRY-2146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16762343#comment-16762343
]
Hadoop QA commented on SENTRY-2146:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12957839/SENTRY-2146.04.patch
against master.
{color:green}Overall:{color} +1 all checks pass
{color:green}SUCCESS:{color} all tests passed
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4368/console
This message is automatically generated.
> Add better error handling to ResourceAuthorizationProvider and improve
> logging in related classes
> -
>
> Key: SENTRY-2146
> URL: https://issues.apache.org/jira/browse/SENTRY-2146
> Project: Sentry
> Issue Type: Bug
> Components: Sentry
>Affects Versions: 2.0.0
>Reporter: Arjun Mishra
>Assignee: Arjun Mishra
>Priority: Major
> Attachments: SENTRY-2146.002.patch, SENTRY-2146.01.patch,
> SENTRY-2146.02.patch, SENTRY-2146.03.patch, SENTRY-2146.04.patch
>
>
> There are a bunch of improvements that should be made to
> ResourceAuthorizationProvider. For example, exceptions thrown by
> privilegeFactory.createPrivilege are not gracefully handled. Makes debugging
> hard.
> We also need to add a lot more logging to related classes
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2471) Table rename should sync Sentry privilege even without location information
[
https://issues.apache.org/jira/browse/SENTRY-2471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16762333#comment-16762333
]
Hadoop QA commented on SENTRY-2471:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12957846/SENTRY-2471.002.patch
against master.
{color:green}Overall:{color} +1 all checks pass
{color:green}SUCCESS:{color} all tests passed
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4369/console
This message is automatically generated.
> Table rename should sync Sentry privilege even without location information
> ---
>
> Key: SENTRY-2471
> URL: https://issues.apache.org/jira/browse/SENTRY-2471
> Project: Sentry
> Issue Type: Bug
>Affects Versions: 2.1.0
>Reporter: Hao Hao
>Assignee: Hao Hao
>Priority: Major
> Attachments: SENTRY-2471.001.patch, SENTRY-2471.002.patch
>
>
> SENTRY-2143 syncs table rename with Sentry privilege. However, this will be
> skipped if table location information is not provided.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2493) Sentry store api's for path mapping should handle empty/null paths.
[
https://issues.apache.org/jira/browse/SENTRY-2493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16762301#comment-16762301
]
Hadoop QA commented on SENTRY-2493:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12957837/SENTRY-2493.002.patch
against master.
{color:green}Overall:{color} +1 all checks pass
{color:green}SUCCESS:{color} all tests passed
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4367/console
This message is automatically generated.
> Sentry store api's for path mapping should handle empty/null paths.
> ---
>
> Key: SENTRY-2493
> URL: https://issues.apache.org/jira/browse/SENTRY-2493
> Project: Sentry
> Issue Type: Bug
>Affects Versions: 2.2.0
>Reporter: kalyan kumar kalvagadda
>Assignee: kalyan kumar kalvagadda
>Priority: Major
> Fix For: 2.2.0
>
> Attachments: SENTRY-2493.001.patch, SENTRY-2493.002.patch
>
>
> Current API's for adding and deleting path mapping throw exceptions when
> paths provided are either empty/null. API's should handle it gracefully.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2493) Sentry store api's for path mapping should handle empty/null paths.
[
https://issues.apache.org/jira/browse/SENTRY-2493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16761961#comment-16761961
]
Hadoop QA commented on SENTRY-2493:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12957792/SENTRY-2493.001.patch
against master.
{color:green}Overall:{color} +1 all checks pass
{color:green}SUCCESS:{color} all tests passed
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4366/console
This message is automatically generated.
> Sentry store api's for path mapping should handle empty/null paths.
> ---
>
> Key: SENTRY-2493
> URL: https://issues.apache.org/jira/browse/SENTRY-2493
> Project: Sentry
> Issue Type: Bug
>Affects Versions: 2.2.0
>Reporter: kalyan kumar kalvagadda
>Assignee: kalyan kumar kalvagadda
>Priority: Major
> Fix For: 2.2.0
>
> Attachments: SENTRY-2493.001.patch
>
>
> Current API's for adding and deleting path mapping throw exceptions when
> paths provided are either empty/null. API's should handle it gracefully.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2477) When requesting for deltas check if nn seq num is 1 more than latest sequence num
[
https://issues.apache.org/jira/browse/SENTRY-2477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16760287#comment-16760287
]
Hadoop QA commented on SENTRY-2477:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12957532/SENTRY-2477.0002.patch
against master.
{color:green}Overall:{color} +1 all checks pass
{color:green}SUCCESS:{color} all tests passed
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4364/console
This message is automatically generated.
> When requesting for deltas check if nn seq num is 1 more than latest sequence
> num
> -
>
> Key: SENTRY-2477
> URL: https://issues.apache.org/jira/browse/SENTRY-2477
> Project: Sentry
> Issue Type: Bug
>Reporter: Arjun Mishra
>Assignee: Arjun Mishra
>Priority: Major
> Attachments: SENTRY-2477.0002.patch, SENTRY-2477.002.patch,
> SENTRY-2477.01.patch, SENTRY-2477.02.patch
>
>
> If NN seq number and latest sentry sequence number is larger than 1 we need
> to request a full update
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2205) Improve Sentry NN Logging
[
https://issues.apache.org/jira/browse/SENTRY-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16760180#comment-16760180
]
Hadoop QA commented on SENTRY-2205:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12957522/SENTRY-2205.003.patch
against master.
{color:green}Overall:{color} +1 all checks pass
{color:green}SUCCESS:{color} all tests passed
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4363/console
This message is automatically generated.
> Improve Sentry NN Logging
> -
>
> Key: SENTRY-2205
> URL: https://issues.apache.org/jira/browse/SENTRY-2205
> Project: Sentry
> Issue Type: Bug
> Components: Sentry
>Affects Versions: 2.1.0
>Reporter: Arjun Mishra
>Assignee: kalyan kumar kalvagadda
>Priority: Major
> Attachments: SENTRY-2205.001.patch, SENTRY-2205.002.patch,
> SENTRY-2205.003.patch
>
>
> Logging in SentryAuthorizationInfo, UpdateForwarder, and SentryStore classes
> are weak and make debugging hard. Improve logging in these classes
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2205) Improve Sentry NN Logging
[
https://issues.apache.org/jira/browse/SENTRY-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16758790#comment-16758790
]
Hadoop QA commented on SENTRY-2205:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12957332/SENTRY-2205.003.patch
against master.
{color:red}Overall:{color} -1 due to 2 errors
{color:red}ERROR:{color} mvn test exited 1
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.dbprovider.TestDbPrivilegesAtDatabaseScope
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4362/console
This message is automatically generated.
> Improve Sentry NN Logging
> -
>
> Key: SENTRY-2205
> URL: https://issues.apache.org/jira/browse/SENTRY-2205
> Project: Sentry
> Issue Type: Bug
> Components: Sentry
>Affects Versions: 2.1.0
>Reporter: Arjun Mishra
>Assignee: kalyan kumar kalvagadda
>Priority: Major
> Attachments: SENTRY-2205.001.patch, SENTRY-2205.002.patch,
> SENTRY-2205.003.patch
>
>
> Logging in SentryAuthorizationInfo, UpdateForwarder, and SentryStore classes
> are weak and make debugging hard. Improve logging in these classes
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
