hive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Casey Brotherton (JIRA)" <>
Subject [jira] [Commented] (HIVE-6225) doesn't respect sticky bit
Date Fri, 17 Jan 2014 23:08:20 GMT


Casey Brotherton commented on HIVE-6225:

Appears to be a problem with drop_table_core from HiveMetaStore calling isWritable on the
parent path of a table. 

isWritable is a method in the Warehouse object, and just does a normal check of writable permissions.

It appears a new method is required, that will be passed in the path for the table, and will
check for the sticky bit of the parent, and in that case, check the owner of the table path.

Otherwise will call isWritable on the parent.

In addition to drop_table_core, there are other suspect calls to isWritable within

 ( All of the calls below to a getParent should be evaluated to see if there is a change,
or delete to a child within the parent...In that case, the sticky bit may need to be checked.

 if (!wh.isWritable(path)) { 
 if (!wh.isWritable(tablePath.getParent())) { 
 if (!wh.isWritable(tblPath.getParent())) { 
 if (!wh.isWritable(partPath.getParent())) { 
 if (!wh.isWritable(archiveParentDir.getParent())) { 
 if (!wh.isWritable(partPath.getParent())) { 
 if (!wh.isWritable(tblPath.getParent())) {

How HDFS handles the permissions is by definition correct. It is just that the
forces Hive to guess how HDFS will react before starting the action.
For example: with the current code, with /user/hive/warehouse having permissions 1777 , and
a table foo created by casey.
If you logged in as johndoe, and dropped foo...It would remove foo from the metastore, and
then there would be an error within the Hive logs as johndoe was not able to remove the directory
from HDFS. 

( Adapted from logs in the customer's environment to remove customer host names. )
2013-09-19 14:33:00,485 INFO hive.metastore.hivemetastoressimpl: deleting hdfs://
2013-09-19 14:33:00,499 WARN org.apache.hadoop.fs.TrashPolicyDefault: Can't create trash directory:
2013-09-19 14:33:00,602 ERROR hive.log: Got exception: Failed to move
to trash: hdfs://
2013-09-19 14:33:00,603 ERROR hive.log: Failed to move to trash: hdfs://
at org.apache.hadoop.fs.TrashPolicyDefault.moveToTrash(
at org.apache.hadoop.fs.Trash.moveToTrash(

Why I suggest a new method, is that knowledge of the table ownership is needed as well as
the permissions of the parent directory.

Interesting side note, when one enables to be 
and enables hive.metastore.pre.event.listeners ( With
), the StorageBasedAuthorizationProvider 
attempts to perform similar checks, but seems to always check the current table directory,
and not the parent at all. In addition, the code does not check the 
sticky bit of any directories.

> doesn't respect sticky bit
> ----------------------------------------------------------------------
>                 Key: HIVE-6225
>                 URL:
>             Project: Hive
>          Issue Type: Bug
>          Components: Authorization
>            Reporter: Casey Brotherton
> Sticky bit works on HDFS, preventing a user from removing an item created by another
user in a directory with permissions of 1777.
> However, Hive allows the table to be dropped even after setting
to true and /user/hive/metastore to 1777 

This message was sent by Atlassian JIRA

View raw message