[
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)
