Aman Sinha has posted comments on this change. ( http://gerrit.cloudera.org:8080/16976 )
Change subject: IMPALA-9234: Support Ranger row filtering policies ...................................................................... Patch Set 10: (2 comments) http://gerrit.cloudera.org:8080/#/c/16976/9/fe/src/main/java/org/apache/impala/authorization/TableMask.java File fe/src/main/java/org/apache/impala/authorization/TableMask.java: http://gerrit.cloudera.org:8080/#/c/16976/9/fe/src/main/java/org/apache/impala/authorization/TableMask.java@109 PS9, Line 109: String stmtSql = String.format("SELECT * FROM %s.%s WHERE %s", > Note that only the WHERE clause is returned. So "SELECT *" is used for > simplicity. That's a good point...but in that case could we just say SELECT 1 ? Not a big deal. Right, I was thinking about IMPALA-9223 in my comment above. http://gerrit.cloudera.org:8080/#/c/16976/9/fe/src/main/java/org/apache/impala/authorization/TableMask.java@111 PS9, Line 111: SelectStmt selectStmt = (SelectStmt) Parser.parse(stmtSql); > Yes, good question. For example if table functional.alltypestiny has an ill I would think that the admin user who has access to the row filter definition should see the parse exception details such that he can fix it but for the normal user there should be some level of obscuring of the error message ..otherwise it would reveal the filter details and in any case the normal user won't be able to fix it by himself. BTW, in the above execution I assume you were the privileged user. But it sounds like the behavior would have been the same if you were not. I am ok if you want to create an enhancement JIRA for this and see what makes sense for Impala. It is probably not a blocker for the feature. I think the Hive message is also problematic ..it just happened to show less for this case but what if the row filter subquery had some syntax issue ? EDIT: I see later that you mention both Impala and Hive will show the full rewritten query in the EXPLAIN plan and the query profile. This contains the expanded row filter even for the normal user .. so I am not sure if the parse exception is that relevant. I would be curious to know how other products like Spark deal with such things. The row filter could have things like Salary or Social Security number predicate etc which should ideally be hidden. -- To view, visit http://gerrit.cloudera.org:8080/16976 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-Project: Impala-ASF Gerrit-Branch: master Gerrit-MessageType: comment Gerrit-Change-Id: I580517be241225ca15e45686381b78890178d7cc Gerrit-Change-Number: 16976 Gerrit-PatchSet: 10 Gerrit-Owner: Quanlong Huang <huangquanl...@gmail.com> Gerrit-Reviewer: Aman Sinha <amsi...@cloudera.com> Gerrit-Reviewer: Csaba Ringhofer <csringho...@cloudera.com> Gerrit-Reviewer: Fang-Yu Rao <fangyu....@cloudera.com> Gerrit-Reviewer: Impala Public Jenkins <impala-public-jenk...@cloudera.com> Gerrit-Reviewer: Quanlong Huang <huangquanl...@gmail.com> Gerrit-Reviewer: Tim Armstrong <tarmstr...@cloudera.com> Gerrit-Comment-Date: Wed, 17 Mar 2021 16:01:21 +0000 Gerrit-HasComments: Yes
