Fredy Wijaya has posted comments on this change. ( http://gerrit.cloudera.org:8080/9942 )
Change subject: IMPALA-6817: Clean up Impala privilege model ...................................................................... Patch Set 9: (7 comments) http://gerrit.cloudera.org:8080/#/c/9942/8/fe/src/compat-minicluster-profile-3/java/org/apache/impala/authorization/ImpalaActionFactory.java File fe/src/compat-minicluster-profile-3/java/org/apache/impala/authorization/ImpalaActionFactory.java: http://gerrit.cloudera.org:8080/#/c/9942/8/fe/src/compat-minicluster-profile-3/java/org/apache/impala/authorization/ImpalaActionFactory.java@35 PS8, Line 35: actions.add(new BitFieldAction(action.getValue(), action.getCode())); > There is a small and finite number of BitFieldActions, can we just create s Putting static values here, isn't it going to defeat the purpose of having to list down the list of privileges in a single place? Introducing a privilege will require an update two two places, i.e. Privilege.java and ImpalaActionFactory.java. http://gerrit.cloudera.org:8080/#/c/9942/8/fe/src/main/java/org/apache/impala/authorization/Privilege.java File fe/src/main/java/org/apache/impala/authorization/Privilege.java: http://gerrit.cloudera.org:8080/#/c/9942/8/fe/src/main/java/org/apache/impala/authorization/Privilege.java@53 PS8, Line 53: public enum ImpalaAction implements Action { > Why would we not make this ImpalaAction a BitFieldAction directly? Java doesn't allow extending a class in enums: https://github.com/apache/sentry/blob/master/sentry-core/sentry-core-common/src/main/java/org/apache/sentry/core/common/BitFieldAction.java http://gerrit.cloudera.org:8080/#/c/9942/8/fe/src/main/java/org/apache/impala/authorization/Privilege.java@60 PS8, Line 60: ALL("*", > Is this somehow changing the meaning of ALL? We generally treat ALL as a di Nope. The behavior remains the same, such that revoking SELECT from ALL is a no-op. Prior to Sentry 2.0, Sentry defines what ALL means. In Sentry 2.0, we can definite what ALL means, but ALL is still treated as a distinct privilege. http://gerrit.cloudera.org:8080/#/c/9942/8/fe/src/test/java/org/apache/impala/authorization/ImpalaActionFactoryTest.java File fe/src/test/java/org/apache/impala/authorization/ImpalaActionFactoryTest.java: http://gerrit.cloudera.org:8080/#/c/9942/8/fe/src/test/java/org/apache/impala/authorization/ImpalaActionFactoryTest.java@33 PS8, Line 33: ImpalaActionFactory factory = new ImpalaActionFactory(); > factory? (here and elsewhere) Done http://gerrit.cloudera.org:8080/#/c/9942/8/fe/src/test/java/org/apache/impala/authorization/ImpalaActionFactoryTest.java@52 PS8, Line 52: expected = Lists.newArrayList( > fix indentation Done http://gerrit.cloudera.org:8080/#/c/9942/8/fe/src/test/java/org/apache/impala/authorization/ImpalaActionFactoryTest.java@59 PS8, Line 59: ImpalaAction.ALL); > This makes it look like ALL is a distinct privilege? Yes. http://gerrit.cloudera.org:8080/#/c/9942/8/fe/src/test/java/org/apache/impala/authorization/ImpalaActionFactoryTest.java@71 PS8, Line 71: assertBitFieldActions(expected, actual); > what happens if you pass in a code 1 << 10 or something invalid? When 1 << 10, expected should be empty. I'll add a test. When a value isn't a bitwise OR of all valid action codes, the behavior is undefined. We can do some validation, but I don't know if it's worth doing it since it's a pretty common pattern to do bitwise OR for storing some settings. Furthermore, this method isn't actually used in Sentry. I just implemented here for completeness: https://github.com/apache/sentry/blob/master/sentry-core/sentry-core-model-db/src/main/java/org/apache/sentry/core/model/db/HiveActionFactory.java#L60-L62 -- To view, visit http://gerrit.cloudera.org:8080/9942 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-Project: Impala-ASF Gerrit-Branch: master Gerrit-MessageType: comment Gerrit-Change-Id: I65f3f9b4d06f3b03bfa2f484737bb746ec598a6b Gerrit-Change-Number: 9942 Gerrit-PatchSet: 9 Gerrit-Owner: Fredy Wijaya <[email protected]> Gerrit-Reviewer: Alex Behm <[email protected]> Gerrit-Reviewer: Fredy Wijaya <[email protected]> Gerrit-Reviewer: Philip Zeyliger <[email protected]> Gerrit-Comment-Date: Tue, 10 Apr 2018 01:05:24 +0000 Gerrit-HasComments: Yes
