[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
