This is the documentation for Cloudera 5.2.x.
Documentation for other versions is available at Cloudera Documentation.

Sentry Service Configuration

  Important: This is the documentation for the Sentry service introduced in CDH 5.1. If you want to use Sentry's previous policy file approach to secure your data, see Sentry Policy File Configuration.

The Sentry service is a RPC server that stores the authorization metadata in an underlying relational database and provides RPC interfaces to retrieve and manipulate privileges. It supports secure access to services using Kerberos. The service serves authorization metadata from the database backed storage; it does not handle actual privilege validation. The Hive and Impala services are clients of this service and will enforce Sentry privileges when configured to use Sentry.

The motivation behind introducing a new Sentry service is to make it easier to handle user privileges than the existing policy file approach. Providing a database instead, allows you to use the more traditional GRANT/REVOKE statements to modify privileges.

Continue reading:

  Important: The following sections contain several instances where a procedure can be completed using either Cloudera Manager or the following command-line instructions. Ensure you complete the procedures using any one of those methods.

Prerequisites

Privilege Model

With CDH 5.1, the privilege model has undergone changes to accommodate the new grant/revoke syntax that is used with the Sentry service. These changes are common to both the new database-backed Sentry service, as well as the previous policy file approach.

The Sentry privilege model has the following characteristics:
  • Allows any user to execute show function, desc function, and show locks.
  • Allows the user to see only those tables and databases for which this user has privileges.
  • Requires a user to have the necessary privileges on the URI to execute HiveQL operations that take in a location. Examples of such operations include LOAD, IMPORT, and EXPORT.
  Important: When Sentry is enabled, a user with no privileges on a database will not be allowed to connect to HiveServer2. This is because the use <database> command is now executed as part of the connection to HiveServer2, which is why the connection fails. See HIVE-4256.

For more information, see Appendix: Authorization Privilege Model for Hive and Impala.

Users and Groups

  • A user is an entity that is permitted by the authentication subsystem to access the Hive service. This entity can be a Kerberos principal, an LDAP userid, or an artifact of some other pluggable authentication system supported by HiveServer2.
  • A group connects the authentication system with the authorization system. It is a collection of one or more users who have been granted one or more authorization roles. Sentry allows a set of roles to be configured for a group.
  • A configured group provider determines a user’s affiliation with a group. The current release supports HDFS-backed groups and locally configured groups.

User to Group Mapping

You can configure Sentry to use either Hadoop groups or groups defined in the policy file. By default, Sentry looks up groups locally, but it can be configured to look up Hadoop groups using LDAP (for Active Directory). Local groups will be looked up on the host Sentry runs on. For Hive, this will be the host running HiveServer2. Group mappings in Sentry can be summarized as in the figure below:

  Important: You can use either Hadoop groups or local groups, but not both at the same time. Use local groups if you want to do a quick proof-of-concept. For production, use Hadoop groups. Refer Configuring LDAP Group Mappings for details on configuring LDAP group mappings in Hadoop.

Configuring Hadoop Groups

Using Cloudera Manager:

Required Role:

  1. Go to the Hive service.
  2. Click the Configuration tab.
  3. Under the Service-Wide category, go to the Sentry section.
  4. Set the Sentry User to Group Mapping Class property to org.apache.sentry.provider.file.HadoopGroupResourceAuthorizationProvider.
  5. Click Save Changes.
  6. Restart the Hive service.
OR

Using the Command Line:

Set the hive.sentry.provider property in sentry-site.xml.
<property>
<name>hive.sentry.provider</name>
<value>org.apache.sentry.provider.file.HadoopGroupResourceAuthorizationProvider</value>
</property>

Configuring Local Groups

  1. Define local groups in the [users] section of the Policy File. For example:
    [users]
    user1 = group1, group2, group3
    user2 = group2, group3
  2. Modify Sentry configuration as follows:

    Using Cloudera Manager:

    Required Role:

    1. Go to the Hive service.
    2. Click the Configuration tab.
    3. Under the Service-Wide category, go to the Sentry section.
    4. Set the Sentry User to Group Mapping Class property to org.apache.sentry.provider.file.LocalGroupResourceAuthorizationProvider.
    5. Click Save Changes.
    6. Restart the Hive service.

    OR

    Using the Command Line: In sentry-site.xml, set hive.sentry.provider as follows:
    <property>
    <name>hive.sentry.provider</name>
    <value>org.apache.sentry.provider.file.LocalGroupResourceAuthorizationProvider</value>
    </property>

Setup and Configuration

Using Cloudera Manager

Adding the Sentry Service

Required Role:

If you are already using Sentry policy files, for instructions on how to migrate to the new service, refer Migrating to the Sentry Service.
  1. On the Home page, click to the right of the cluster name and select Add a Service. A list of service types display. You can add one type of service at a time.
  2. Select the Sentry service and click Continue.
  3. Select the radio button next to the services on which the new service should depend and click Continue.
  4. Customize the assignment of role instances to hosts. The wizard evaluates the hardware configurations of the hosts to determine the best hosts for each role. These assignments are typically acceptable, but you can reassign role instances to hosts of your choosing, if desired.

    Click a field below a role to display a dialog containing a pageable list of hosts. If you click a field containing multiple hosts, you can also select All Hosts to assign the role to all hosts or Custom to display the pageable hosts dialog.

    The following shortcuts for specifying host names are supported:
    • Range of hostnames (without the domain portion)
      Range Definition Matching Hosts
      10.1.1.[1-4] 10.1.1.1, 10.1.1.2, 10.1.1.3, 10.1.1.4
      host[1-3].company.com host1.company.com, host2.company.com, host3.company.com
      host[07-10].company.com host07.company.com, host08.company.com, host09.company.com, host10.company.com
    • IP addresses
    • Rack name

    Click the View By Host button for an overview of the role assignment by host ranges.

  5. Configure database settings:
    1. Choose the database type:
      • Leave the default setting of Use Embedded Database to have Cloudera Manager create and configure required databases. Make a note of the auto-generated passwords.
      • Select Use Custom Databases to specify external databases.
        1. Enter the database host, database type, database name, username, and password for the database that you created when you set up the database.
    2. Click Test Connection to confirm that Cloudera Manager can communicate with the database using the information you have supplied. If the test succeeds in all cases, click Continue; otherwise check and correct the information you have provided for the database and then try the test again. (For some servers, if you are using the embedded database, you will see a message saying the database will be created at a later step in the installation process.) The Review Changes page displays.
  6. Click Continue to start the service.
  7. Click Continue then click Finish. You are returned to the Home page.
  8. Verify the new service is started properly by checking the health status for the new service. If the Health Status is Good, then the service started properly.
  9. To use the Sentry service, begin by enabling Hive and Impala for the service.

Migrating to the Sentry Service

Required Role:

The following steps describe how you can upgrade from Sentry's policy file-based approach to the new database-backed Sentry service.
  1. If you haven't already done so, upgrade your cluster to the latest version of CDH and Cloudera Manager. Refer the Cloudera Manager Administration Guide for instructions.
  2. Disable the existing Sentry policy file for any Hive or Impala services on the cluster. To do this:
    1. Navigate to the Hive or Impala service.
    2. Click the Configuration tab.
    3. Under the Service-Wide > Policy File Based Sentry category, uncheck the Enable Sentry Authorization using Policy Files checkbox. Cloudera Manager will throw a validation error if you attempt to configure the Sentry service while this property is checked.
    4. Repeat for any remaining Hive or Impala services.
  3. Add the new Sentry service to your cluster. For instructions, see Adding the Sentry Service.
  4. To begin using the Sentry service, see Enabling the Sentry Service for Hive and Enabling the Sentry Service for Impala.
  5. Use the command-line interface Beeline to issue grants to the Sentry service to match the contents of your old policy file(s). For more details on the Sentry service and examples on using Grant/Revoke statements to match your policy file, see Hive SQL Syntax.

Using the Command Line

Installing and Upgrading Sentry

  Important:
  • If you use Cloudera Manager, do not use these command-line instructions.
  • This information applies specifically to CDH 5.2.x. If you use an earlier version of CDH, see the documentation for that version located at Cloudera Documentation.
Upgrading Sentry from CDH 4 to CDH 5

To upgrade Sentry from CDH 4 to CDH 5, you must uninstall the old version and install the new version. If you have already performed the steps to uninstall CDH 4 and all components, as described under Upgrading from CDH 4 to CDH 5, you can skip Step 1 below and proceed with installing the new CDH 5 version of Sentry.

  1. Remove the CDH 4 Version of Sentry

    Remove Sentry as follows, depending on your operating system:

    OS Command
    RHEL
    $ sudo yum remove sentry
    SLES
    $ sudo zypper remove sentry
    Ubuntu or Debian
    $ sudo apt-get remove sentry
  2. Install the New Version of Sentry

    Follow instructions in the Installing Sentry section to install the CDH 5 version of Sentry.

      Important: Configuration files
    • If you install a newer version of a package that is already on the system, configuration files that you have modified will remain intact.
    • If you uninstall a package, the package manager renames any configuration files you have modified from <file> to <file>.rpmsave. If you then re-install the package (probably to install a new version) the package manager creates a new <file> with applicable defaults. You are responsible for applying any changes captured in the original configuration file to the new configuration file. In the case of Ubuntu and Debian upgrades, you will be prompted if you have made changes to a file for which there is a new version; for details, see Automatic handling of configuration files by dpkg.

    The upgrade is now complete.

Upgrading Sentry from CDH 5.x to the latest version of CDH 5
  1. Stop the Sentry Service
    To stop the Sentry service, identify the PID of the Sentry Service and use the kill command to end the process:
    ps -ef | grep sentry
    kill -9 <PID>
    Replace <PID> with the PID of the Sentry Service.
  2. Install the New Version of Sentry

    Use the appropriate commands from the Installing Sentry section below to install the latest CDH 5 version of Sentry.

  3. Upgrade Sentry Database Schema
    Use the Sentry schematool to upgrade the database schema as follows:
    bin/sentry --command schema-tool --conffile <sentry-site.xml> --dbType <db-type> --upgradeSchema
    Where <db-type> should be either mysql, postgres or oracle.
  4. Start the Sentry Service
    1. Set the SENTRY_HOME and HADOOP_HOME parameters.
    2. Run the following command:
      bin/sentry --command service --conffile <sentry-site.xml>
Installing Sentry
Install Sentry as follows, depending on your operating system:
OS Command
RHEL
$ sudo yum install sentry
SLES
$ sudo zypper install sentry
Ubuntu or Debian
$ sudo apt-get update; 
$ sudo apt-get install sentry

Starting the Sentry Service

Perform the following steps to start the Sentry service on your cluster.
  1. Set the SENTRY_HOME and HADOOP_HOME parameters.
  2. Create the Sentry database schema using the Sentry schematool. Sentry, by default, does not initialize the schema. The schematool is a built-in way for you to deploy the backend schema required by the Sentry service. For example, the following command uses the schematool to initialize the schema for a MySQL database.
    bin/sentry --command schema-tool --conffile <sentry-site.xml> --dbType mysql --initSchema
    Alternatively, you can set the sentry.verify.schema.version configuration property to false. However, this is not recommended.
  3. Start the Sentry service.
    bin/sentry --command service --conffile <sentry-site.xml>

Enabling the Sentry Service for Hive

  Important: Ensure you have unchecked the Enable Sentry Authorization using Policy Files configuration property for both Hive and Impala under the Service-Wide > Policy File Based Sentry category.

Before you begin:

  • Ensure all the action items under Prerequisites are complete.
  • The Hive warehouse directory (/user/hive/warehouse or the path you have specified as hive.metastore.warehouse.dir in your Hive configuration) must be owned by the hive user and group.
  • Permissions on the Hive warehouse directory and all subdirectories must be 771. All files and directories should be owned by hive:hive. For example:
    $ sudo -u hdfs hdfs dfs -chmod -R 771 /user/hive/warehouse
    $ sudo -u hdfs hdfs dfs -chown -R hive:hive /user/hive/warehouse
  • Disable impersonation for HiveServer2 in the Cloudera Manager Admin Console:
    1. Go to the Hive service.
    2. Click the Configuration tab.
    3. Under the HiveServer2 role group, uncheck the HiveServer2 Enable Impersonation property, and click Save Changes.
  • To enable the Hive user to submit MapReduce jobs, under TaskTracker role group(s) set the Minimum User ID for Job Submission to 0. You must do this for every TaskTracker role group for the MapReduce service that is associated with Hive, if more than one exists.
    1. Go to the MapReduce service.
    2. Click the Configuration tab.
    3. Under a TaskTracker role group go to the Security category.
    4. Set the Minimum User ID for Job Submission property to zero (the default is 1000) and click Save Changes.
    5. Restart the MapReduce service.
  • To enable the Hive user to submit YARN jobs, ensure the Allowed System Users property includes the hive user. You must do this for every NodeManager role group for the YARN service that is associated with Hive, if more than one exists.
    1. Go to the YARN service.
    2. Click the Configuration tab.
    3. Under a NodeManager role group go to the Security category.
    4. Ensure the Allowed System Users property includes the hive user. If not, add hive and click Save Changes.
    5. Restart the YARN service.

Enabling the Sentry service for Hive:

  1. Go to the Hive service.
  2. Click the Configuration tab.
  3. In the Service-Wide category, set the Sentry Service property to Sentry.
  4. Restart the Hive service.

Configuring HiveServer2 for the Sentry Service

Add the following property to hive-site.xml to allow the Hive service to communicate with the Sentry policy store.
<property>
   <name>hive.security.authorization.task.factory</name>
   <value>org.apache.sentry.binding.hive.SentryHiveAuthorizationTaskFactoryImpl</value>
</property>
<property>
   <name>hive.server2.session.hook</name>
   <value>org.apache.sentry.binding.hive.HiveAuthzBindingSessionHook</value>
</property>
<property>
   <name>hive.sentry.conf.url</name>
   <value>file:///{{CMF_CONF_DIR}}/sentry-site.xml</value>
</property>
<property>
   <name>hive.security.authorization.task.factory</name>
   <value>org.apache.sentry.binding.hive.SentryHiveAuthorizationTaskFactoryImpl</value>
</property>

Configuring the Hive Metastore for the Sentry Service

Configuring Pig and HCatalog for the Sentry Service

Once you have the Sentry service up and running, and Hive has been configured to use the Sentry service, there are some configuration changes you must make to your cluster to allow Pig, MapReduce (using HCatLoader, HCatStorer) and WebHCat queries to access Sentry-secured data stored in Hive.

With HDFS extended ACLs enabled, Cloudera recommends you set the permissions for the Hive warehouse directory, /user/hive/warehouse, to 771 so users other than the owner and group only have execute permissions. Since by default, the /user/hive/warehouse directory is owned by hive:hive, this also restricts requests from any other users at the HDFS level.

With these permissions, other user requests may fail, such as commands coming through Pig jobs, WebHCat queries, and MapReduce jobs. In order to give these users access, perform the following configuration changes:
  • Use HDFS ACLs to define permissions on a specific directory or file of HDFS. This directory/file is generally mapped to a database, table, partition, or a data file.
  • Users running these jobs should have the required permissions in Sentry to add new metadata or read metadata from the Hive Metastore Server. For instructions on how to set up the required permissions, see Hive SQL Syntax. You can use HiveServer2's command line interface, Beeline to update the Sentry database with the user privileges.
Examples:
  • A user who is using Pig HCatLoader will require read permissions on a specific table or partition. In such a case, you can GRANT read access to the user in Sentry and set the ACL to read and execute, on the file being accessed.
  • A user who is using Pig HCatStorer will require ALL permissions on a specific table. In this case, you GRANT ALL access to the user in Sentry and set the ACL to write and execute, on the table being used.

Configuring the Hive Metastore to Communicate with Sentry

Add the following properties to hive-site.xml to allow the Hive Metastore to communicate with the Sentry policy store.
<property>
    <name>hive.metastore.client.impl</name>
    <value>org.apache.sentry.binding.metastore.SentryHiveMetaStoreClient</value>
    <description>Sets custom Hive Metastore client which Sentry uses to filter out metadata.</description>
</property>

<property>  
    <name>hive.metastore.pre.event.listeners</name>  
    <value>org.apache.sentry.binding.metastore.MetastoreAuthzBinding</value>  
    <description>list of comma separated listeners for metastore events.</description>
</property>

<property>
    <name>hive.metastore.event.listeners</name>  
    <value>org.apache.sentry.binding.metastore.SentryMetastorePostEventListener</value>  
    <description>list of comma separated listeners for metastore, post events.</description>
</property>

Configuring Impala for the Sentry Service

Required Role:

Enabling the Sentry Service for Impala

  Important: Ensure you have unchecked the Enable Sentry Authorization using Policy Files configuration property for both Hive and Impala under the Service-Wide > Policy File Based Sentry category.
To use the Sentry service:
  1. Enable the Sentry service for Hive. For details on how to do this, see Enabling the Sentry Service for Hive.
  2. Go to the Impala service.
  3. Click the Configuration tab.
  4. In the Service-Wide category, set the Sentry Service property to Sentry.
  5. Restart Impala.

Configuring Impala as a Client for the Sentry Service

Set the following configuration properties in sentry-site.xml.
<property>
   <name>sentry.service.client.server.rpc-port</name>
   <value>3893</value>
</property>
<property>
   <name>sentry.service.client.server.rpc-address</name>
   <value>hostname</value>
</property>
<property>
   <name>sentry.service.client.server.rpc-connection-timeout</name>
   <value>200000</value>
</property>
<property>
   <name>sentry.service.security.mode</name>
   <value>none</value>
</property>
Other configuration changes required include:
  • To enable the Sentry policy service, the following flag should be set on the catalogd and the impalad.
    --sentry_config=<absolute path to sentry service configuration file>
  • To enable authorization based on policy server metadata set the following flag on the impalad.
    --server_name=<server name>
  • To enable authorization based on a file-based policy set the following flags on the impalad.
    --server_name=<server name>
    --authorization_policy_file=<path to policy file>

    If the --authorization_policy_file flag is set, Impala will use the policy file-based approach. Otherwise, the policy server metadata approach will be used to implement authorization.

  • The impala user also needs to be added to list of administrative users of the Sentry Policy Server. For more details, see SENTRY-191.

Hive SQL Syntax

Permissions stored in the Sentry service are configured through Grant and Revoke statements issued either interactively or programmatically through the HiveServer2 SQL command line interface, Beeline. The syntax described below is very similar to the GRANT/REVOKE commands available in well-established relational database systems.
  Important: Note that there are some differences in syntax between Hive and the corresponding Impala SQL statements. For the Impala syntax, see SQL Statements.

CREATE ROLE Statement

The CREATE ROLE statement creates a role to which privileges can be granted. Privileges can be granted to roles, which can then be assigned to users. A user that has been assigned a role will only be able to exercise the privileges of that role.

Only users that have administrative privileges can create/drop roles. By default, the hive, impala and hue users have admin privileges in Sentry.

CREATE ROLE [role_name];

DROP ROLE Statement

The DROP ROLE statement can be used to remove a role from the database. Once dropped, the role will be revoked for all users to whom it was previously assigned. Queries that are already executing will not be affected. However, since Hive checks user privileges before executing each query, active user sessions in which the role has already been enabled will be affected.
DROP ROLE [role_name];

GRANT ROLE Statement

The GRANT ROLE statement can be used to grant roles to groups. Only Sentry admin users can grant roles to a group.
GRANT ROLE role_name [, role_name]    
    TO GROUP <groupName> [,GROUP <groupName>]

REVOKE ROLE Statement

The REVOKE ROLE statement can be used to revoke roles from groups. Only Sentry admin users can revoke the role from a group.
REVOKE ROLE role_name [, role_name]    
    FROM GROUP <groupName> [,GROUP <groupName>]

GRANT <PRIVILEGE> Statement

In order to grant privileges on an object to a role, the user must be a Sentry admin user.
GRANT    
    <PRIVILEGE> [, <PRIVILEGE> ]    
    ON <OBJECT> <object_name>    
    TO ROLE <roleName> [,ROLE <roleName>]

REVOKE <PRIVILEGE> Statement

Since only authorized admin users can create roles, consequently only Sentry admin users can revoke privileges from a group.
REVOKE    
    <PRIVILEGE> [, <PRIVILEGE> ]    
    ON <OBJECT> <object_name>    
    FROM ROLE <roleName> [,ROLE <roleName>]

GRANT <PRIVILEGE> ... WITH GRANT OPTION

As of CDH 5.2, you can delegate granting and revoking privileges to other roles. For example, a role that is granted a privilege WITH GRANT OPTION can GRANT/REVOKE the same privilege to/from other roles. Hence, if a role has the ALL privilege on a database and the WITH GRANT OPTION set, users granted that role can execute GRANT/REVOKE statements only for that database or child tables of the database.
GRANT
    <PRIVILEGE> 
    ON <OBJECT> <object_name>
    TO ROLE <roleName> 
    WITH GRANT OPTION
Only a role with GRANT option on a specific privilege or its parent privilege can revoke that privilege from other roles. Once the following statement is executed, all privileges with and without grant option are revoked.
REVOKE
    <PRIVILEGE>
    ON <OBJECT> <object_name>
    FROM ROLE <roleName>
Hive does not currently support revoking only the WITH GRANT OPTION from a privilege previously granted to a role. To remove the WITH GRANT OPTION, revoke the privilege and grant it again without the WITH GRANT OPTION flag.

SET ROLE Statement

The SET ROLE statement can be used to specify a role to be enabled for the current session. A user can only enable a role that has been granted to them. Any roles not listed and not already enabled are disabled for the current session. If no roles are enabled, the user will have the privileges granted by any of the roles that (s)he belongs to.
To enable a specific role:
SET ROLE <roleName>;
To enable all roles:
SET ROLE ALL;
No roles enabled:
SET ROLE NONE;

SHOW Statement

To list all the roles in the system (only for sentry admin users):
SHOW ROLES;
To list all the roles in effect for the current user session:
SHOW CURRENT ROLES;
To list all the roles assigned to the given <groupName> (only allowed for Sentry admin users and others users that are part of the group specified by <groupName>):
SHOW ROLE GRANT GROUP <groupName>;

The SHOW statement can also be used to list the privileges that have been granted to a role or all the grants given to a role for a particular object.

To list all the grants for the given <roleName> (only allowed for Sentry admin users and other users that have been granted the role specified by <roleName>):
SHOW GRANT ROLE <roleName>;
To list all the grants for a role on the given <objectName> (only allowed for Sentry admin users and other users that have been granted the role specified by <roleName>):
SHOW GRANT ROLE <roleName> on OBJECT <objectName>;

Example: Using Grant/Revoke Statements to Match an Existing Policy File

Here is a sample policy file:
[groups] 
# Assigns each Hadoop group to its set of roles  
manager = analyst_role, junior_analyst_role 
analyst = analyst_role 
jranalyst = junior_analyst_role 
customers_admin = customers_admin_role 
admin = admin_role  

[roles] # The uris below define a define a landing skid which 
# the user can use to import or export data from the system. 
# Since the server runs as the user "hive" files in that directory 
# must either have the group hive and read/write set or 
# be world read/write. 
analyst_role = server=server1->db=analyst1, \     
    server=server1->db=jranalyst1->table=*->action=select         
    server=server1->uri=hdfs://ha-nn-uri/landing/analyst1 
junior_analyst_role = server=server1->db=jranalyst1, \     
    server=server1->uri=hdfs://ha-nn-uri/landing/jranalyst1  

# Implies everything on server1. 
admin_role = server=server1

The following sections show how you can use the new GRANT statements to assign privileges to roles (and assign roles to groups) to match the sample policy file above.

Grant privileges to analyst_role:
CREATE ROLE analyst_role;
GRANT ALL ON DATABASE analyst1 TO ROLE analyst_role;
GRANT SELECT ON DATABASE jranalyst1 TO ROLE analyst_role;
GRANT ALL ON URI 'hdfs://ha-nn-uri/landing/analyst1' \
TO ROLE analyst_role;
Grant privileges to junior_analyst_role:
CREATE ROLE junior_analyst_role;
GRANT ALL ON DATABASE jranalyst1 TO ROLE junior_analyst_role;
GRANT ALL ON URI 'hdfs://ha-nn-uri/landing/jranalyst1' \
TO ROLE junior_analyst_role;
Grant privileges to admin_role:
CREATE ROLE admin_role
GRANT ALL ON SERVER server TO ROLE admin_role;
Grant roles to groups:
GRANT ROLE admin_role TO GROUP admin;
GRANT ROLE analyst_role TO GROUP analyst;
GRANT ROLE jranalyst_role TO GROUP jranalyst;

Appendix: Authorization Privilege Model for Hive and Impala

Privileges can be granted on different objects in the Hive warehouse. Any privilege that can be granted is associated with a level in the object hierarchy. If a privilege is granted on a container object in the hierarchy, the base object automatically inherits it. For instance, if a user has ALL privileges on the database scope, then (s)he has ALL privileges on all of the base objects contained within that scope.

Object Hierarchy in Hive

Server
     Database
         Table
             Partition
             Columns
         View
         Index
     Function/Routine
     Lock
Table 1. Valid privilege types and objects they apply to
Privilege Object
INSERT DB, TABLE
SELECT DB, TABLE
ALL SERVER, TABLE, DB, URI
Table 2. Privilege hierarchy
Base Object Granular privileges on object Container object that contains the base object Privileges on container object that implies privileges on the base object
DATABASE ALL SERVER ALL
TABLE INSERT DATABASE ALL
TABLE SELECT DATABASE ALL
VIEW SELECT DATABASE ALL
Table 3. Privilege table for Hive & Impala operations
Operation Scope Privileges URI Others
CREATE DATABASE SERVER ALL    
DROP DATABASE DATABASE ALL
CREATE TABLE DATABASE ALL
DROP TABLE TABLE ALL
CREATE VIEW DATABASE; SELECT on TABLE ALL SELECT on TABLE
DROP VIEW VIEW/TABLE ALL
CREATE INDEX TABLE ALL
DROP INDEX TABLE ALL
ALTER TABLE .. ADD COLUMNS TABLE ALL
ALTER TABLE .. REPLACE COLUMNS TABLE ALL
ALTER TABLE .. CHANGE column TABLE ALL
ALTER TABLE .. RENAME TABLE ALL
ALTER TABLE .. SET TBLPROPERTIES TABLE ALL
ALTER TABLE .. SET FILEFORMAT TABLE ALL
ALTER TABLE .. SET LOCATION TABLE ALL URI  
ALTER TABLE .. ADD PARTITION TABLE ALL
ALTER TABLE .. ADD PARTITION location TABLE ALL URI  
ALTER TABLE .. DROP PARTITION TABLE ALL
ALTER TABLE .. PARTITION SET FILEFORMAT TABLE ALL
SHOW TBLPROPERTIES TABLE SELECT/INSERT    
SHOW CREATE TABLE TABLE SELECT/INSERT    
SHOW PARTITIONs TABLE SELECT/INSERT    
DESCRIBE TABLE TABLE SELECT/INSERT    
DESCRIBE TABLE .. PARTITION TABLE SELECT/INSERT    
LOAD DATA TABLE INSERT URI  
SELECT TABLE SELECT    
INSERT OVERWRITE TABLE TABLE INSERT    
CREATE TABLE .. AS SELECT DATABASE; SELECT on TABLE ALL SELECT on TABLE
USE <dbName> Any
ALTER TABLE .. SET SERDEPROPERTIES TABLE ALL
ALTER TABLE .. PARTITION SET SERDEPROPERTIES TABLE ALL
Hive-Only Operations
INSERT OVERWRITE DIRECTORY TABLE INSERT URI  
Analyze TABLE TABLE SELECT + INSERT    
IMPORT TABLE DATABASE ALL URI  
EXPORT TABLE TABLE SELECT URI  
ALTER TABLE TOUCH TABLE ALL
ALTER TABLE TOUCH PARTITION TABLE ALL
ALTER TABLE .. CLUSTERED BY SORTED BY TABLE ALL
ALTER TABLE .. ENABLE/DISABLE TABLE ALL
ALTER TABLE .. PARTITION ENABLE/DISABLE TABLE ALL
ALTER TABLE .. PARTITION.. RENAME TO PARTITION TABLE ALL    
ALTER DATABASE DATABASE ALL    
DESCRIBE DATABASE DATABASE SELECT/INSERT    
SHOW COLUMNS TABLE SELECT/INSERT    
SHOW INDEXES TABLE SELECT/INSERT    
GRANT PRIVILEGE Allowed only for Sentry admin users
REVOKE PRIVILEGE Allowed only for Sentry admin users
SHOW GRANTS Allowed only for Sentry admin users
ADD JAR Not Allowed      
ADD FILE Not Allowed      
DFS Not Allowed      
Impala-Only Operations
EXPLAIN TABLE SELECT    
INVALIDATE METADATA SERVER ALL    
INVALIDATE METADATA <table name> TABLE SELECT/INSERT    
REFRESH <table name> TABLE SELECT/INSERT    
CREATE FUNCTION SERVER ALL    
DROP FUNCTION SERVER ALL    
COMPUTE STATS TABLE ALL