hive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phabricator (Commented) (JIRA)" <>
Subject [jira] [Commented] (HIVE-2809) StorageHandler authorization providers
Date Wed, 29 Feb 2012 00:18:56 GMT


Phabricator commented on HIVE-2809:

enis has commented on the revision "HIVE-2809 [jira] StorageHandler authorization providers".

  Yes, clientnegative/url_hook.q, and TestURLHook have been moved to TestEmbeddedHiveMetaStore.
  The reason is that, url_hook.q assumes that the SHOW TABLES operation will cause only only
metastore call, however, it shouldn't make this assumption, since this patch for example,
changes that. So I replaced the test with a more direct test against metastore. Moreover,
the test belongs to metastore not contrib.


> StorageHandler authorization providers
> --------------------------------------
>                 Key: HIVE-2809
>                 URL:
>             Project: Hive
>          Issue Type: New Feature
>    Affects Versions: 0.9.0
>            Reporter: Enis Soztutar
>            Assignee: Enis Soztutar
>         Attachments: HIVE-2809.D1953.1.patch, HIVE-2809.D1953.2.patch, HIVE-2809.D1953.3.patch
> In this issue, we would like to discuss the possibility of supplementing the Hive authorization
model with authorization at the storage level. As discussed in HIVE-1943, Hive should also
check for operation permissions in hdfs and hbase, since otherwise, data and metadata can
be in an inconsistent state or be orphaned. Going a step further, some of the setups might
not need the full featured auth model by Hive, but want to rely on managing the permissions
at the data layer. In this model, the metadata operations are checked first from hdfs/hbase
and it is allowed only if they are allowed at the data layer. The semantics are documented
> So, the goals of this issue are: 
>  - Port storage handler specific authorization providers, and the StorageDelegationAuthorizationProvider
from HCATALOG-245 and HCATALOG-260 to Hive. 
>  - Keep current Hive's default authorization provider, and enable user to use this and/or
the storage one. auth providers are already configurable.
>  - Move the manual checks that had to be performed about authorization in Hcat to Hive,
>   -- CREATE DATABASE/TABLE, ADD PARTITION statements does not call 
>    HiveAuthorizationProvider.authorize() with the candidate objects, which means that
>    we cannot do checks against defined LOCATION.
>   -- HiveOperation does not define sufficient Privileges for most of the operations,

>     especially database operations. 
>   -- For some of the operations, Hive SemanticAnalyzer does not add the changed 
>     object as a WriteEntity or ReadEntity.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message