[
https://issues.apache.org/jira/browse/HIVE-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12970662#action_12970662
]
John Sichi commented on HIVE-78:
--------------------------------
First batch of review comments.
JDO:
* Do we want roles to be contained by databases? Let's discuss this
at next design review.
* Instead of two separate flags (IS_ROLE/IS_GROUP) should we instead use
an enum for principal type { USER, GROUP, ROLE }?
* Naming suggestions (if accepted, propagate to Thrift API also):
** SECURITYROLE -> ROLES
** SECURITYROLEMAP -> ROLE_MAP
** SECURITYUSER -> GLOBAL_PRIVS
** SECURITYDB -> DB_PRIVS
** SECURITYTBLPART -> TBLPART_PRIVS
** SECURITYCOLUMN -> COL_PRIVS
* VARCHAR precision for "privileges" fields should be 4000
* Since we're going to need to record GRANT OPTION eventually, maybe
we should add it now so that we don't have to ALTER TABLE later?
Thrift API:
* Avoid embedding objects inside of other objects except where
necessary. For example, in the definition of struct Role, use
dbName instead of a Database object (assuming we keep roles as
contained by databases). Likewise, in PrivilegeBag, the map keys
should be identifiers, not objects. This applies to quite a few of
the new structs.
* Can we reduce the number of new structs and API calls by
consolidating different object types? For example, for the
get_XXX_privilege_set calls, just have one, and take object
type+identifier.
* Add comments for all new methods.
Config:
* Why is hive.exec.security used for some config params instead of
hive.security? Also, those parameter names should make it clear
that they are default grants. Also, do we really need owner grants
(don't owners automatically have full privileges implicitly)?
* Looks like hive.variable.substitute crept in from some other patch.
* Comments for plugin-loading parameters should make it explicit
exactly which interface they are supposed to implement.
* Comment for role grants says "to some groups" instead.
Pluggable Interfaces:
* I don't think we need the factory classes; just add new methods to
HiveUtils (and follow the classloading pattern used there)
* Rename AuthorizationProvider to HiveAuthorizationProvider
and make it extend Configurable
* Rename AuthorizationProviderManager to AbstractAuthorizationProvider
* All outside references should be to the interface (HiveAuthorizationProvider)
not the abstract class.
* Rename Authenticator to HiveAuthenticationProvider and make it
extend Configurable
* Javadoc?
Typos:
* principla
* Authrization
* GrantInfor
* privielges
* "Table is partitioned, but partition spec found"
* DummpyAuthenticator
* detroy
* wheenve
Implementation:
* why does doAuthorization return a boolean when it just throws
anyway?
* more coming...
> Authorization infrastructure for Hive
> -------------------------------------
>
> Key: HIVE-78
> URL: https://issues.apache.org/jira/browse/HIVE-78
> Project: Hive
> Issue Type: New Feature
> Components: Metastore, Query Processor, Server Infrastructure
> Reporter: Ashish Thusoo
> Assignee: He Yongqiang
> Attachments: createuser-v1.patch, hive-78-metadata-v1.patch,
> hive-78-syntax-v1.patch, HIVE-78.1.nothrift.patch, HIVE-78.1.thrift.patch,
> HIVE-78.2.nothrift.patch, HIVE-78.2.thrift.patch, HIVE-78.4.complete.patch,
> HIVE-78.4.no_thrift.patch, HIVE-78.5.complete.patch,
> HIVE-78.5.no_thrift.patch, HIVE-78.6.complete.patch,
> HIVE-78.6.no_thrift.patch, hive-78.diff
>
>
> Allow hive to integrate with existing user repositories for authentication
> and authorization infromation.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
