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

Thejas M Nair commented on HIVE-15120:
--------------------------------------

Not related to the patch -
I am not sure if current behavior of requiring write access for external table 
creation makes sense. Afterall, only read access is required to access the 
contents. This is something to be revisited in a follow up jira. Maybe allow 
only 'temporary table' creation with readonly access ?

cc [~sushanth]

> 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
>         Attachments: HIVE-15120.1.patch
>
>
> 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)

Reply via email to