You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hive.apache.org by "Daniel Dai (JIRA)" <ji...@apache.org> on 2016/11/04 21:58:58 UTC

[jira] [Commented] (HIVE-15120) Storage based auth: allow option to enforce write checks for external tables

    [ https://issues.apache.org/jira/browse/HIVE-15120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15637833#comment-15637833 ] 

Daniel Dai commented on HIVE-15120:
-----------------------------------

Create external table do require write permission for the directory, here is the stack if not:
{code}
	StorageBasedAuthorizationProvider.checkPermissions(FileSystem, FileStatus, EnumSet<FsAction>, String) line: 412	
	StorageBasedAuthorizationProvider.checkPermissions(Configuration, Path, EnumSet<FsAction>) line: 377	
	StorageBasedAuthorizationProvider.authorize(Path, Privilege[], Privilege[]) line: 350	
	StorageBasedAuthorizationProvider.authorize(Table, Privilege[], Privilege[]) line: 195	
	AuthorizationPreEventListener.authorizeCreateTable(PreCreateTableEvent) line: 265	
	AuthorizationPreEventListener.onEvent(PreEventContext) line: 140	
	HiveMetaStore$HMSHandler.firePreEvent(PreEventContext) line: 2148	
	HiveMetaStore$HMSHandler.create_table_core(RawStore, Table, EnvironmentContext, List<SQLPrimaryKey>, List<SQLForeignKey>) line: 1354	
	HiveMetaStore$HMSHandler.create_table_with_environment_context(Table, EnvironmentContext) line: 1442	
	NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]	
	NativeMethodAccessorImpl.invoke(Object, Object[]) line: 57	
	DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43	
	Method.invoke(Object, Object...) line: 606	
	RetryingHMSHandler.invokeInternal(Object, Method, Object[]) line: 140	
	RetryingHMSHandler.invoke(Object, Method, Object[]) line: 99	
	$Proxy20.create_table_with_environment_context(Table, EnvironmentContext) line: not available	
	ThriftHiveMetastore$Processor$create_table_with_environment_context<I>.getResult(I, create_table_with_environment_context_args) line: 10939	
	ThriftHiveMetastore$Processor$create_table_with_environment_context<I>.getResult(Object, TBase) line: 10923	
	ThriftHiveMetastore$Processor$create_table_with_environment_context<I>(ProcessFunction<I,T>).process(int, TProtocol, TProtocol, I) line: 39	
	TUGIBasedProcessor$1.run() line: 110	
	TUGIBasedProcessor$1.run() line: 106	
	AccessController.doPrivileged(PrivilegedExceptionAction<T>, AccessControlContext) line: not available [native method]	
	Subject.doAs(Subject, PrivilegedExceptionAction<T>) line: 415	
	UserGroupInformation.doAs(PrivilegedExceptionAction<T>) line: 1628	
	TUGIBasedProcessor<I>.process(TProtocol, TProtocol) line: 118	
	TThreadPoolServer$WorkerProcess.run() line: 286	
	ThreadPoolExecutor.runWorker(ThreadPoolExecutor$Worker) line: 1145	
	ThreadPoolExecutor$Worker.run() line: 615	
	Thread.run() line: 745	
{code}

Only at deletion time, we distinguish external table and managed table, which is inconsistent. Not sure why we do that initially, but to maintain backward compatibility, I will still use a flag for this.

> Storage based auth: allow option to enforce write checks for external tables
> ----------------------------------------------------------------------------
>
>                 Key: HIVE-15120
>                 URL: https://issues.apache.org/jira/browse/HIVE-15120
>             Project: Hive
>          Issue Type: Bug
>          Components: Authorization
>            Reporter: Thejas M Nair
>            Assignee: Daniel Dai
>
> Under storage based authorization, we don't require write permissions on table directory for external table create/drop.
> This is because external table contents are populated often from outside of hive and are not written into from hive. So write access is not needed. Also, we can't require write permissions to drop a table if we don't require them for creation (users who created them should be able to drop them).
> However, this difference in behavior of external tables is not well documented. So users get surprised to learn that drop table can be done by just any user who has read access to the directory. At that point changing the large number of scripts that use external tables is hard. 
> It would be good to have a user config option to have external tables to be treated same as managed tables.
> The option should be off by default, so that the behavior is backward compatible by default.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)