You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hive.apache.org by "Carter Shanklin (JIRA)" <ji...@apache.org> on 2017/01/21 04:46:26 UTC

[jira] [Created] (HIVE-15689) SQL standard auth makes privilege manage difficult by throwing errors aggressively

Carter Shanklin created HIVE-15689:
--------------------------------------

             Summary: SQL standard auth makes privilege manage difficult by throwing errors aggressively
                 Key: HIVE-15689
                 URL: https://issues.apache.org/jira/browse/HIVE-15689
             Project: Hive
          Issue Type: Improvement
            Reporter: Carter Shanklin
            Priority: Minor


Consider an application that tries to help users manage Hive authorizations by generating SQL statements based on a selection of privileges.

Suppose the user first select to only allow select, then later allows the user to both select and update.

{code}
0: jdbc:hive2://localhost:10000/default> grant select on table secured to role public;
No rows affected (0.029 seconds)
0: jdbc:hive2://localhost:10000/default> grant select, update on table secured to role public;
Error: Error while processing statement: FAILED: Execution Error, return code 1 from org.apache.hadoop.hive.ql.exec.DDLTask. org.apache.hadoop.hive.ql.metadata.HiveException: java.lang.RuntimeException: InvalidObjectException(message:SELECT is already granted on table [default,secured] by hive) (state=08S01,code=1)
{code}

The update privilege is in fact not granted. To get around this the application would have to probe all privileges, determine that select is already present, then generate just a grant of update. Alternatively the app could generate grants individually and just ignore all errors.

It would be more convenient if this just wasn't treated as an error.

Compare: Postgres:
{code}
vagrant=# grant select on table secured to public;
GRANT
vagrant=# grant select, update on table secured to public;
GRANT
vagrant=# grant select, update on table secured to public;
GRANT
vagrant=# revoke select, update on table secured from public;
REVOKE
vagrant=# revoke select, update on table secured from public;
REVOKE
{code}

Here even revokes that don't have any effect are ignored.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)