You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues-all@impala.apache.org by "ASF subversion and git services (Jira)" <ji...@apache.org> on 2019/08/29 12:45:01 UTC

[jira] [Commented] (IMPALA-8851) Drop table if exists throws authorization exception when table does not exist

    [ https://issues.apache.org/jira/browse/IMPALA-8851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16918576#comment-16918576 ] 

ASF subversion and git services commented on IMPALA-8851:
---------------------------------------------------------

Commit 026c5345e0e27383244d757660856e8a157aac20 in impala's branch refs/heads/master from Vihang Karajgaonkar
[ https://gitbox.apache.org/repos/asf?p=impala.git;h=026c534 ]

IMPALA-8851: Do not throw authorization exception in drop if exists queries

Note that this is the continuation of work in
https://github.com/vihangk1/impala/commits/IMPALA-8851

This patch's goal is to change Impala's behavior in the following case:
- the query is a DROP TABLE/VIEW/DATABASE/FUNCTIONS IF EXISTS statement
- the given object does not exist
- the user has some kind of privilege on the object, which imples the
  privilege to know whether object exists, but does not have DROP
  privilege on the object

Until now this lead to an authorization exception, while it will be
allowed with this change.

An example where this is useful is a user who has CREATE privilege on
a database, and creates table t_owned, and gets ownership of the
table. In this case DROP TABLE IF EXISTS was non idempotent:
DROP TABLE IF EXISTS t_owned;
-> success
DROP TABLE IF EXISTS t_owned;
-> authorization error, as the privileges for the table were
   deleted when the table was successfully dropped

After this change the second statement will be also successful.

The authorization logic has to avoid leaking information that the
user has no right to know. For this reason DROP IF EXISTS has to
return the same error message regardless whether the object exists
or not if the user has no right to know it's existence. This is
achieved with the following pattern:
- in the IF EXISTS case first an ANY privilege is registered, then
  the existence of the object is checked and if it doesn't exist,
  the analysis returns successfully
- if the object exists, the DROP privilege is registered (if there is
  no IF EXISTS in the query, this always happens)
- as the authorization logic checks privileges in the order of
  registration, first the ANY will be checked, and DROP will be only
  checked if the user has ANY privileges

Testing:
- Added a new test case in the sentry tests which confirms that the
authorization exception is not thrown when a drop if exists query is
issued on a object which does not exist.
- Changed several tests affected by the new behavior.
- Ran core tests.

Change-Id: Iba068935e5da92d71e16e2321afdb8e7b781086a
Reviewed-on: http://gerrit.cloudera.org:8080/14121
Reviewed-by: Impala Public Jenkins <im...@cloudera.com>
Tested-by: Impala Public Jenkins <im...@cloudera.com>


> Drop table if exists throws authorization exception when table does not exist
> -----------------------------------------------------------------------------
>
>                 Key: IMPALA-8851
>                 URL: https://issues.apache.org/jira/browse/IMPALA-8851
>             Project: IMPALA
>          Issue Type: Bug
>            Reporter: Vihang Karajgaonkar
>            Assignee: Vihang Karajgaonkar
>            Priority: Major
>
> When authorization is enabled, a {{drop table if exists <tablename>}} on a non-existing table throws an authorization exception. In such a case if the user has required permissions to the query the tables on the database, this is unnecessary and the SQL should succeed saying the table does not exists instead of erroring out.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-all-unsubscribe@impala.apache.org
For additional commands, e-mail: issues-all-help@impala.apache.org