Child pages
  • AuthDev
Skip to end of metadata
Go to start of metadata

Index

Authorization modes

This is the design document for the original Hive authorization mode. See Authorization for an overview of authorization modes, which include storage based authorization and SQL standards based authorization.

1. Privilege

1.1 Access Privilege

Admin privilege, DB privilege, Table level privilege, column level privilege

1.1.1 Admin privileges are global privileges, and are used to perform administration.

1.1.2 DB privileges are database specific, and apply to all objects inside that database.

1.1.3 Table privileges apply to table/view/index in a given database

1.1.4 Column privileges apply to column level.

All DB/Table/Column privilege differentiate read and write privileges even though now hive does not support column level overwrite. And there is no partition level privilege.

2. Hive Operations

create index/drop index

create database/drop database

create table/drop table

create view/drop view

alter table

show databases

lock table/unlock table/show lock

add partition

archive

Select

insert overwrite directory

insert overwrite table

others include "create table as ", "create table like" etc

3. Metadata

Store the privilege information in the new metastore tables 'user', 'db', 'tables_priv', 'columns_priv'.

The user table indicates user's global privileges, which apply to all databases.
The db table determine database level access privileges, which apply to all objects inside that database.

3.1 user, group, and roles

User can belong to some groups. The group information is provided by authenticator.

And each user or group can have some privileges and roles. A role can be a member of another role, but not in a circular manner.

So hive metadata needs to store:

1) roles -> privileges, roles mapping

2) Hive user/group -> privileges, role mapping

3.1.1 Role management

create role

drop role

grant a role to a user

revoke a role from a user

3.1.2 role metadata

role_name - string

create_time - int

3.1.3 hive role user membership table

role_name - string

user_name - string

is_group – is the user name a group name

is_role – is the user name a role name

3.2 Privileges to be supported by Hive

3.2.1 metadata

The below shows how we store the grant information in metastore. The deny information is stored in a same matter (just in different tables).

So for each grant table, there will also be a deny table. The metastore tables are

user, deny_user, db, deny_db, tables_priv, deny_tables_priv, columns_priv, deny_columns_priv

Another way to do it is to add a column in the grant table to record this row is grant or deny.

We store privileges in one column, and use comma to separate different privileges.

hive> desc user;

Field

  • - - -

User

isRole

isGroup

isSuper

db_priv – set (Select_priv, Insert_priv, Create_priv, Drop_priv, Reload_priv,

Grant_priv, Index_priv, Alter_priv, Show_db_priv,

Lock_tables_priv, Create_view_priv, Show_view_priv)

hive> desc db;

Field

  • - - -

Db

User

isRole

isGroup

Table_priv – set (Select_priv, Insert_priv, Create_priv, Drop_priv, Grant_priv,

Index_priv, Reload_priv, Alter_priv, Create_tmp_table_priv,

Lock_tables_priv, Create_view_priv, Show_view_priv)

hive> desc tables_priv;

Field

  • - - -

Db

User

isRole

isGroup

Table_name

Grantor

Timestamp

Table_priv – set('Select','Insert',,'Create','Drop','Grant','Index','Alter','Create View','Show view')

Column_priv – set('Select','Insert',)

mysql> desc columns_priv;

Field

  • - - -

Db

User

isRole

isGroup

Table_name

Column_name

Timestamp

Column_priv – set('Select','Insert','Update')

4. grant/revoke access privilege

4.1 Privilege names/types:

ALL Privileges

ALTER

Create

Create view

Delete

Drop

Index

Insert

Lock Tables

Select

Show databases

Super

4.2 show grant

4.3 grant/revoke statement

5. Authorization verification

5.1 USER/GROUP/ROLE

USER

GROUP

ROLE

GROUP is very similar to a role. And we support Group is because we may need to pass the group information to HDFS/Map-reduce.

A role can also contain other roles and privileges - and they can be granted to users and groups.

Role can be nested but not circular.

5.2 The verification steps

When a user logins to the system, he has a user name, one or few groups that he belongs to.
So it is

[

].

  • Steps to authorize one access: *

5.3 Examples

5.3.1 I want to grant everyone (new people may join at anytime) to
db_name.*, and then later i want to protect one table db_name.T from ALL
users but a few

1) Add all users to a group 'users'. (assumption: new users will
automatically join this group). And grant 'users' ALL privileges to db_name.*

2) Add those few users to a new group 'users2'. AND REMOVE them from 'users'

3) DENY 'users' to db_name.T

4) Grant ALL on db_name.T to users2

5.3.2 I want to protect one table db_name.T from one/few users, but all
other people can access it

1) Add all users to a group 'users'. (assumption: new users will automatically
join this group). And grant 'users' ALL privileges to db_name.*.

2) Add those few users to a new group 'users2'. (Note: those few users will now
belong to 2 groups: users and user2)

3) DENY 'users2' to db_name.T

6. Where to add authorization in Hive

CliDriver and HiveServer. Basically they share the same code. If HiveServer invokes CliDriver, we can just add it into CliDriver. And we also need to make HiveServer be able to support multiple user/connections.
This still does not solve the problem if someone accesses the metastore directly (without going through Hive).

7. Implementation

7.1 Authenticator interface

We only get the user's user name, group names from the authenticator. The authenticator implementations need to provide these information. This is the only interface between authenticator and authorization.

7.2 Authorization

Authorization decision manager manages a set of authorization provider, and each provider can decide to accept or deny. And it is the decision manager to do the final decision. Can be vote based, or one -1 then deny, or one +1 then accept. Authorization provider decides whether to accept or deny an access based on his own information.

8. Metastore upgrade script for mysql


HDFS Permission

The above has a STRONG assumption on the file layer security. Users can easily by-pass the security if the hdfs file permission is open to him. We hope we can easily plug in external authorizations (like HDFS permission/Howl permission) to alter the authorization result or even the rule.

  • No labels