[ https://issues.apache.org/jira/browse/IMPALA-10211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17253284#comment-17253284 ]
ASF subversion and git services commented on IMPALA-10211: ---------------------------------------------------------- Commit 1b863132c6fbe1b45aabea9986653a9ec7817092 in impala's branch refs/heads/master from Fang-Yu Rao [ https://gitbox.apache.org/repos/asf?p=impala.git;h=1b86313 ] IMPALA-10211 (Part 1): Add support for role-related statements This patch adds the support for the following role-related statements. 1. CREATE ROLE <role_name>. 2. DROP ROLE <role_name>. 3. GRANT ROLE <role_name> TO GROUP <group_name>. 4. REVOKE ROLE <role_name> FROM GROUP <group_name>. 5. GRANT <privilege> ON <resource> TO ROLE <role_name>. 6. REVOKE <privilege> ON <resource> FROM ROLE <role_name>. 7. SHOW GRANT ROLE <role_name> ON <resource>. 8. SHOW ROLES. 9. SHOW CURRENT ROLES. 10. SHOW ROLE GRANT GROUP <group_name>. To support the first 4 statements, we implemented the methods of createRole()/dropRole(), and grantRoleToGroup()/revokeRoleFromGroup() with their respective API calls provided by Ranger. To support the 5th and 6th statements, we modified createGrantRevokeRequest() so that the cases in which the grantee or revokee is a role could be processed. We slightly extended getPrivileges() so as to include the case when the principal is a role for the 7th statement. For the last 3 statements, to make Impala's behavior consistent with that when Sentry was the authorization provider, we based our implementation on SentryImpaladAuthorizationManager#getRoles() at https://gerrit.cloudera.org/c/15833/8/fe/src/main/java/org/apache/impala/authorization/sentry/SentryImpaladAuthorizationManager.java, which was removed in IMPALA-9708 when we dropped the support for Sentry. To test the implemented functionalities, we based our test cases on those at https://gerrit.cloudera.org/c/15833/8/testdata/workloads/functional-query/queries/QueryTest/grant_revoke.test. We note that before our tests could be automatically run in a Kerberized environment (IMPALA-9360), in order to run the statements of CREATE/DROP ROLE <role_name>, GRANT/REVOKE ROLE <role_name> TO/FROM GROUP <group_name>, and SHOW ROLES, we revised security-applicationContext.xml, one of the files needed when the Ranger server is started, so that the corresponding API calls could be performed in a non-Kerberized environment. During the process of adding test cases to grant_revoke.test, we found the following differences in Impala's behavior between the case when Ranger is the authorization provider and that when Sentry is the authorization provider. Specifically, we have the following two major differences. 1. Before dropping a role in Ranger, we have to remove all the privileges granted to the role in advance, which is not the case when Sentry is the authorization provider. 2. The resource has to be specified for the statement of SHOW GRANT ROLE <role_name> ON <resource>, which is different when Sentry is the authorization provider. This could be partly due to the fact that there is no API provided by Ranger that allows Impala to directly retrieve the list of all privileges granted to a specified role. Due to the differences in Impala's behavior described above, we had to revise the test cases in grant_revoke.test accordingly. On the other hand, to include as many test cases that were in the original grant_revoke.test as possible, we had to explicitly add the test section of 'USER' to specify the connecting user to Impala for some queries that require the connecting user to be a Ranger administrator, e.g., CREATE/DROP ROLE <role_name> and GRANT/REVOKE <role_name> TO/FROM GROUP <group_name>. The user has to be 'admin' in the current grant_revoke.test, whereas it could be the default user 'getuser()' in the original grant_revoke.test because previously 'getuser()' was also a Sentry administrator. Moreover, for some test cases, we had to explicitly alter the owner of a resource in the original grant_revoke.test when we would like to prevent the original owner of the resource, e.g., the creator of the resource, from accessing the resource since the original grant_revoke.test was run without object ownership being taken into consideration. We also note that in this patch we added the decorator of @pytest.mark.execute_serially to each test in test_ranger.py since we have observed that in some cases, e.g., if we are only running the E2E tests in the Jenkins environment, some tests do not seem to be executed sequentially. Testing: - Briefly verified that the implemented statements work as expected in a Kerberized cluster. - Verified that test_ranger.py passes in a local development environment. - Verified that the patch passes the exhaustive tests in the DEBUG build. Change-Id: Ic2b204e62a1d8ae1932d955b4efc28be22202860 Reviewed-on: http://gerrit.cloudera.org:8080/16837 Reviewed-by: Quanlong Huang <huangquanl...@gmail.com> Tested-by: Impala Public Jenkins <impala-public-jenk...@cloudera.com> > Add support for role-related statements > --------------------------------------- > > Key: IMPALA-10211 > URL: https://issues.apache.org/jira/browse/IMPALA-10211 > Project: IMPALA > Issue Type: New Feature > Components: Frontend, Security > Reporter: Fang-Yu Rao > Assignee: Fang-Yu Rao > Priority: Major > Labels: backwards-compatibility > > After IMPALA-9708, we dropped the support for Sentry, an authorization > service providing role-based authorization. Since then Impala lacks support > for role-based authorization. > On the other hand, after RANGER-2425, Ranger added APIs for role-related SQL > statements. It would be nice to enable role-related SQL statements in Impala > with Ranger being the authorization provider so that users that were using > Sentry as the authorization provider could still be using Impala if > role-based authorization is required. -- This message was sent by Atlassian Jira (v8.3.4#803005) --------------------------------------------------------------------- To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org