[jira] [Created] (IMPALA-7285) Restructure analyzer code to perform security/access checks before re-analysis
Zoram Thanga created IMPALA-7285:
Summary: Restructure analyzer code to perform security/access
checks before re-analysis
Key: IMPALA-7285
URL: https://issues.apache.org/jira/browse/IMPALA-7285
Project: IMPALA
Issue Type: Bug
Components: Frontend, Security
Affects Versions: Impala 2.12.0
Reporter: Zoram Thanga
This came out during the review for
[https://gerrit.cloudera.org/#/c/10850/|https://gerrit.cloudera.org/#/c/10850/]:
{quote}
supposing the folded fn reveals something interesting, e.g., getSSN("some user
name") ... this approach evaluates it and outputs it to the log. while I don't
think we output this rewritten query in an error (or possibly elsewhere
downstream), have you looked at avoiding the evaluation of fn in the first
place if access is not permitted? the approach here seems prone to currently
leak and can get worse depending on future changes.
{quote}
In general, it would be good to handle query analysis in the following sequence:
# Parse
# Check security/access
# Analyze
# Re-write
# Re-analyze
# etc.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Created] (IMPALA-7285) Restructure analyzer code to perform security/access checks before re-analysis
Zoram Thanga created IMPALA-7285:
Summary: Restructure analyzer code to perform security/access
checks before re-analysis
Key: IMPALA-7285
URL: https://issues.apache.org/jira/browse/IMPALA-7285
Project: IMPALA
Issue Type: Bug
Components: Frontend, Security
Affects Versions: Impala 2.12.0
Reporter: Zoram Thanga
This came out during the review for
[https://gerrit.cloudera.org/#/c/10850/|https://gerrit.cloudera.org/#/c/10850/]:
{quote}
supposing the folded fn reveals something interesting, e.g., getSSN("some user
name") ... this approach evaluates it and outputs it to the log. while I don't
think we output this rewritten query in an error (or possibly elsewhere
downstream), have you looked at avoiding the evaluation of fn in the first
place if access is not permitted? the approach here seems prone to currently
leak and can get worse depending on future changes.
{quote}
In general, it would be good to handle query analysis in the following sequence:
# Parse
# Check security/access
# Analyze
# Re-write
# Re-analyze
# etc.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
