Apache Hive : Hive deprecated authorization mode / Legacy Mode

This document describes Hive security using the basic authorization scheme, which regulates access to Hive metadata on the client side. This was the default authorization mode used when authorization was enabled. The default was changed to SQL Standard authorization in Hive 2.0 (HIVE-12429).

Disclaimer

Hive authorization is not completely secure. The basic authorization scheme is intended primarily to prevent good users from accidentally doing bad things, but makes no promises about preventing malicious users from doing malicious things.  See the Hive authorization main page for the secure options.

Prerequisites

In order to use Hive authorization, there are two parameters that should be set in hive-site.xml:

<property>
  <name>hive.security.authorization.enabled</name>
  <value>true</value>
  <description>enable or disable the hive client authorization</description>
</property>

<property>
  <name>hive.security.authorization.createtable.owner.grants</name>
  <value>ALL</value>
  <description>the privileges automatically granted to the owner whenever a table gets created. 
   An example like "select,drop" will grant select and drop privilege to the owner of the table</description>
</property>

Note that, by default, the hive.security.authorization.createtable.owner.grants are set to null, which would result in the creator of a table having no access to the table.

Users, Groups, and Roles

At the core of Hive’s authorization system are users, groups, and roles. Roles allow administrators to give a name to a set of grants which can be easily reused. A role may be assigned to users, groups, and other roles. For example, consider a system with the following users and groups:

If we wanted to restrict each user to a specific set of databases, we could use roles to build the authorization mechanism. The administrator would create two roles, called role_db1 and role_db2. The role_db1 role would provide privileges just for the first database, and the role_db2 role would provide privileges just for the second database. The administrator could then grant the role_db1 role to group_db1, or explicitly for the users in the group, and do the same for role_db2 with the users of the second database. In order to allow users who need to see all databases to get their appropriate privileges, a third role could be created called role_all_dbs, which would be granted role_db1 and role_db2. When user_all_dbs is granted the role_all_dbs role, the user implicitly is granted all the privileges of role_db1 and role_db2.

Hive roles must be created manually before being used, unlike users and groups. Users and groups are managed by the hive.security.authenticator.manager. When a user connects to a Metastore Server and issues a query, the Metastore will determine the username of the connecting user, and the groups associated with that ushive.security.authorization.ername. That information is then used to determine if the user should have access to the metadata being requested, by comparing the required privileges of the Hive operation to the user privileges using the following rules:

By default, the Metastore uses the HadoopDefaultAuthenticator for determing user -> group mappings, which determines authorization by using the Unix usernames and groups on the machine where the Metastore is running. To make this more clear, consider a scenario where a user foo is a member of group bar on the machine running the Hive CLI, and connects to a Metastore running on a separate server that also has a user named foo, but on the Metastore Server, foo is a member of group baz. When an operation is executed, the Metastore will determine foo to be in the group baz.

Taking this a step further, it is also possible for the groups that a user belongs to on the Metastore Server may differ from the groups that the same user belongs to, as determined by HDFS. This could be the case if Hive or HDFS are configured to use non-default user -> group mappers, or the Metastore and the Namenode both use the defaults, but the processes are running on different machines, and the user -> group mappings are not the same on each machine.

It is important to realize that Hive Metastore only controls authorization for metadata, and the underlying data is controlled by HDFS, so if permissions and privileges between the two systems are not in sync, users may have access to metadata, but not the physical data. If the user -> group mappings across the Metastore and Namenode are not in sync, as in the scenarios above, a user may have the privileges required to access a table according to the Metastore, but may not have permission to access the underlying files according to the Namenode. This could also happen due to administrator intervention, if permissions on the files were changed by hand, but Metastore grants had not been updated.

Names of Users and Roles

Role names are case sensitive. In Hive 0.13, however, there was a bug that caused it to have case insensitive behavior. That issue has been fixed in Hive 0.14.

User names are also case sensitive. Unlike role names, user names are not managed within Hive.

Quoted Identifiers in Version 0.13.0+

As of Hive 0.13.0, user and role names may optionally be surrounded by backtick characters () when the configuration parameter hive.support.quoted.identifiers is set to column (default value). All [Unicode](http://en.wikipedia.org/wiki/List_of_Unicode_characters) characters are permitted in the quoted identifiers, with double backticks (``) representing a backtick character. However when hive.support.quoted.identifiers is set to none`, or in Hive 0.12.0 and earlier, only alphanumeric and underscore characters are permitted in user names and role names.

For details, see HIVE-6013 and Supporting Quoted Identifiers in Column Names.

As of Hive 0.14, user may be optionally surrounded by backtick characters () irrespective of the hive.support.quoted.identifiers` setting.

Creating/Dropping/Using Roles

Create/Drop Role

CREATE ROLE role\_name

DROP ROLE role\_name

Grant/Revoke Roles

GRANT ROLE role\_name [, role\_name] ...
TO principal\_specification [, principal\_specification] ...
[WITH ADMIN OPTION]

REVOKE [ADMIN OPTION FOR] ROLE role\_name [, role\_name] ...
FROM principal\_specification [, principal\_specification] ...

principal\_specification:
    USER user
  | GROUP group
  | ROLE role

Version

GRANT ROLE added the optional WITH ADMIN OPTION clause in Hive 0.13.0 (HIVE-5923).

REVOKE ROLE will add the optional ADMIN OPTION FOR clause in Hive 0.14.0 (HIVE-6252).

 

Viewing Granted Roles

SHOW ROLE GRANT principal\_specification
 
principal\_specification:
    USER user
  | GROUP group
  | ROLE role

Version

The output of SHOW ROLE GRANT is in tabular format starting with Hive 0.13.0 (HIVE-6204).

Privileges

The following privileges are supported in Hive:

Grant/Revoke Privileges

GRANT
    priv\_type [(column\_list)]
      [, priv\_type [(column\_list)]] ...
    [ON object\_specification]
    TO principal\_specification [, principal\_specification] ...
    [WITH GRANT OPTION]

REVOKE [GRANT OPTION FOR]
    priv\_type [(column\_list)]
      [, priv\_type [(column\_list)]] ...
    [ON object\_specification]
    FROM principal\_specification [, principal\_specification] ...

REVOKE ALL PRIVILEGES, GRANT OPTION
    FROM user [, user] ...

priv\_type:
    ALL | ALTER | UPDATE | CREATE | DROP
  | INDEX | LOCK | SELECT | SHOW\_DATABASE 
 
object\_specification:
    TABLE tbl\_name
  | DATABASE db\_name
 
principal\_specification:
    USER user
  | GROUP group
  | ROLE role

Version

REVOKE priv_type will add the optional GRANT OPTION FOR clause in Hive 0.14.0 (HIVE-7404).

 

Viewing Granted Privileges

SHOW GRANT principal\_specification
[ON object\_specification [(column\_list)]]
 
principal\_specification:
    USER user
  | GROUP group
  | ROLE role
 
object\_specification:
    TABLE tbl\_name
  | DATABASE db\_name

Version

The output of SHOW GRANT is in tabular format starting with Hive 0.13.0 (HIVE-6204).

 

Hive Operations and Required Privileges

As of the release of Hive 0.7, only these operations require permissions, according to org.apache.hadoop.hive.ql.plan.HiveOperation:

| Operation | ALTER | UPDATE | CREATE | DROP | INDEX | LOCK | SELECT | SHOW_DATABASE | | LOAD |   | X |   |   |   |   |   |   | | EXPORT |   |   |   |   |   |   | X |   | | IMPORT | X | X |   |   |   |   |   |   | | CREATE TABLE |   |   | X |   |   |   |   |   | | CREATE TABLE AS SELECT |   |   | X |   |   |   | X |   | | DROP TABLE |   |   |   | X |   |   |   |   | | SELECT |   |   |   |   |   |   | X |   | | ALTER TABLE ADD COLUMN | X |   |   |   |   |   |   |   | | ALTER TABLE REPLACE COLUMN | X |   |   |   |   |   |   |   | | ALTER TABLE RENAME | X |   |   |   |   |   |   |   | | ALTER TABLE ADD PARTITION |   |   | X |   |   |   |   |   | | ALTER TABLE DROP PARTITION |   |   |   | X |   |   |   |   | | ALTER TABLE ARCHIVE |   | X |   |   |   |   |   |   | | ALTER TABLE UNARCHIVE |   | X |   |   |   |   |   |   | | ALTER TABLE SET PROPERTIES | X |   |   |   |   |   |   |   | | ALTER TABLE SET SERDE | X |   |   |   |   |   |   |   | | ALTER TABLE SET SERDE | X |   |   |   |   |   |   |   | | ALTER TABLE SET SERDEPROPERTIES | X |   |   |   |   |   |   |   | | ALTER TABLE CLUSTER BY | X |   |   |   |   |   |   |   | | ALTER TABLE PROTECT MODE | X |   |   |   |   |   |   |   | | ALTER PARTITION PROTECT MODE | X |   |   |   |   |   |   |   | | ALTER TABLE SET FILEFORMAT | X |   |   |   |   |   |   |   | | ALTER PARTITION SET FILEFORMAT | X |   |   |   |   |   |   |   | | ALTER TABLE SET LOCATION |   | X |   |   |   |   |   |   | | ALTER PARTITION SET LOCATION |   | X |   |   |   |   |   |   | | ALTER TABLE CONCATENATE |   | X |   |   |   |   |   |   | | ALTER PARTITION CONCATENATE |   | X |   |   |   |   |   |   | | SHOW DATABASES |   |   |   |   |   |   |   | X | | LOCK TABLE |   |   |   |   |   | X |   |   | | UNLOCK TABLE |   |   |   |   |   | X |   |   |