[
https://issues.apache.org/jira/browse/HDFS-8312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14940109#comment-14940109
]
Luis Fernando Antonioli commented on HDFS-8312:
-----------------------------------------------
I have been able to reproduce the bug in Hadoop 2.6.0, but not by following the
same steps you proposed. Following your steps, I got permission denied in both
cases and could not delete the files. In my test, I used the super user account
to create a shared folder (every user can upload files to this directory) in
the root directory of the HDFS and then used two different non root accounts
(user1 and user2) to upload files to this folder (one user does not have
permission to edit the files of the other). Finally, I could reproduce the
inconsistency. When the HDFS thash was disabled, I got permission denied when
trying to delete the files with one of the non root accounts and when the trash
was enabled I was able to move all the files to the trash folder. Although I
cannot delete the files directly from the trash folder, they will be deleted
when the deletion interval set in the Hadoop configuration is reached. I could
not reproduce this issue in Hadoop 2.7.1, I got permission denied in both
cases. I think this bug was fixed in newer versions of Hadoop.
> Trash does not descent into child directories to check for permissions
> ----------------------------------------------------------------------
>
> Key: HDFS-8312
> URL: https://issues.apache.org/jira/browse/HDFS-8312
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: HDFS, security
> Affects Versions: 2.2.0, 2.6.0
> Reporter: Eric Yang
>
> HDFS trash does not descent into child directory to check if user has
> permission to delete files. For example:
> Run the following command to initialize directory structure as super user:
> {code}
> hadoop fs -mkdir /BSS/level1
> hadoop fs -mkdir /BSS/level1/level2
> hadoop fs -mkdir /BSS/level1/level2/level3
> hadoop fs -put /tmp/appConfig.json /BSS/level1/level2/level3/testfile.txt
> hadoop fs -chown user1:users /BSS/level1/level2/level3/testfile.txt
> hadoop fs -chown -R user1:users /BSS/level1
> hadoop fs -chown -R 750 /BSS/level1
> hadoop fs -chmod -R 640 /BSS/level1/level2/level3/testfile.txt
> hadoop fs -chmod 775 /BSS
> {code}
> Change to a normal user called user2.
> When trash is enabled:
> {code}
> sudo su user2 -
> hadoop fs -rm -r /BSS/level1
> 15/05/01 16:51:20 INFO fs.TrashPolicyDefault: Namenode trash configuration:
> Deletion interval = 3600 minutes, Emptier interval = 0 minutes.
> Moved: 'hdfs://bdvs323.svl.ibm.com:9000/BSS/level1' to trash at:
> hdfs://bdvs323.svl.ibm.com:9000/user/user2/.Trash/Current
> {code}
> When trash is disabled:
> {code}
> /opt/ibm/biginsights/IHC/bin/hadoop fs -Dfs.trash.interval=0 -rm -r
> /BSS/level1
> 15/05/01 16:58:31 INFO fs.TrashPolicyDefault: Namenode trash configuration:
> Deletion interval = 0 minutes, Emptier interval = 0 minutes.
> rm: Permission denied: user=user2, access=ALL,
> inode="/BSS/level1":user1:users:drwxr-x---
> {code}
> There is inconsistency between trash behavior and delete behavior. When
> trash is enabled, files owned by user1 is deleted by user2. It looks like
> trash does not recursively validate if the child directory files can be
> removed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
