Csaba Ringhofer has posted comments on this change. ( http://gerrit.cloudera.org:8080/23569 )
Change subject: IMPALA-14507: Register column-level privilege requests for INSERT ...................................................................... Patch Set 14: (3 comments) http://gerrit.cloudera.org:8080/#/c/23569/14/fe/src/main/java/org/apache/impala/authorization/BaseAuthorizationChecker.java File fe/src/main/java/org/apache/impala/authorization/BaseAuthorizationChecker.java: http://gerrit.cloudera.org:8080/#/c/23569/14/fe/src/main/java/org/apache/impala/authorization/BaseAuthorizationChecker.java@156 PS14, Line 156: // The table-level SELECT, INSERT, or CREATE must be the first table-level : // request, and it must precede all column-level privilege requests. : // We allow the CREATE privilege because in CreateTableAsSelectStmt#analyze(), : // we call InsertStmt#analyze(), which in turn registers column-level INSERT : // privilege requests. : // We allow the ALL privilege because for the UPSERT operation against Kudu : // tables, we set the required privilege to ALL since we don't have an UPSERT : // privilege yet. Refer to InsertStmt#analyzeTargetTable(). : Preconditions.checkState((requests.isEmpty() || : !(privReq.getAuthorizable().getType() == Authorizable.Type.COLUMN)) || : (requests.get(0).getAuthorizable().getType() == Authorizable.Type.TABLE && : ALLOWED_HIER_AUTHZ_TABLE_PRIVILEGES.contains( : requests.get(0).getPrivilege()))); This precondition is very hard to understand - the condition seems false only if there is a column priv request, and there is already a first request that is not a table level request, e.g. it will fail for 2 column level requests, but not for 1 column level requests or a column level request followed by a table level request. Is this really what we want to check here? http://gerrit.cloudera.org:8080/#/c/23569/14/fe/src/main/java/org/apache/impala/authorization/BaseAuthorizationChecker.java@191 PS14, Line 191: Type.COLUMN nit: Authorizable.Type.COLUMN would be more consistent http://gerrit.cloudera.org:8080/#/c/23569/14/fe/src/test/java/org/apache/impala/authorization/ranger/RangerAuditLogTest.java File fe/src/test/java/org/apache/impala/authorization/ranger/RangerAuditLogTest.java: http://gerrit.cloudera.org:8080/#/c/23569/14/fe/src/test/java/org/apache/impala/authorization/ranger/RangerAuditLogTest.java@511 PS14, Line 511: // It's possible that we still have a policy with exactly the same resource : // specified by ('databaseName', 'tableName', 'columnName') e Why is this possible? Don't every test clean up the policies it has created after running? If this is not a normal scenario, then I think that we should return an error in this case. -- To view, visit http://gerrit.cloudera.org:8080/23569 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-Project: Impala-ASF Gerrit-Branch: master Gerrit-MessageType: comment Gerrit-Change-Id: I2ef61801d3b394c56702b193c250492a62b111df Gerrit-Change-Number: 23569 Gerrit-PatchSet: 14 Gerrit-Owner: Fang-Yu Rao <[email protected]> Gerrit-Reviewer: Csaba Ringhofer <[email protected]> Gerrit-Reviewer: Fang-Yu Rao <[email protected]> Gerrit-Reviewer: Impala Public Jenkins <[email protected]> Gerrit-Reviewer: Noemi Pap-Takacs <[email protected]> Gerrit-Reviewer: Quanlong Huang <[email protected]> Gerrit-Reviewer: Riza Suminto <[email protected]> Gerrit-Comment-Date: Mon, 05 Jan 2026 14:11:34 +0000 Gerrit-HasComments: Yes
