[
https://issues.apache.org/jira/browse/HDFS-8312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15407456#comment-15407456
]
Weiwei Yang edited comment on HDFS-8312 at 8/12/16 1:12 AM:
------------------------------------------------------------
Hello [~eyang] and [~luisfernandoantonioli]
I was able to reproduce this issue with following steps
I created user1 and user2, they both belongs to users group
{code}
uid=1007(user1) gid=1007(user1) groups=1007(user1),100(users)
uid=1009(user2) gid=1010(user2) groups=1010(user2),100(users)
{code}
As super user,
{code}
su hdfs
hadoop fs -mkdir /BSS
hadoop fs -chmod 777 /BSS
{code}
As user1
{code}
su user1
hadoop fs -mkdir /BSS/user1/
hadoop fs -put /tmp/test /BSS/user1/
hadoop chmod 600 /BSS/user1/test
hdfs dfs -ls -R /BSS
drwxr-xr-x - user1 users 0 2016-08-11 18:06 /BSS/user1
-rw------- 3 user1 users 4308 2016-08-11 18:06 /BSS/user1/test
{code}
As user2, try to delete /BSS/user1 directory with -skipTrash, it gives
permission denied error (expected)
{code}
su user2
hadoop dfs -rmr -skipTrash /BSS/user1/
rmr: Permission denied: user=user2, access=ALL,
inode="/BSS/user1":user1:users:drwxr-xr-x
{code}
try to delete the directory again without disabling trash,
{code}
su user2
hadoop dfs -rmr /BSS/user1/
16/08/04 01:47:53 INFO fs.TrashPolicyDefault: Namenode trash configuration:
Deletion interval = 360 minutes, Emptier interval = 0 minutes.
Moved: 'hdfs://bdavm1542.svl.ibm.com:8020/BSS/user1' to trash at:
hdfs://bdavm1542.svl.ibm.com:8020/user/user2/.Trash/Current
{code}
directory removed (unexpected).
This opens security hole that user is able to delete other user files, this
should be fixed. Agree ?
Internally, trash calls {{rename}} and rm calls {{delete}}, that's why the
behavior was not consistent, user2 has the permission to move the directory but
not to delete
{code}
su user2
hadoop dfs -mv /BSS/user1 /user/user2/.Trash
hadoop dfs -ls /user/user2/.Trash
Found 2 items
drwx------ - user2 hdfs 0 2016-08-04 01:39
/user/user2/.Trash/Current
drwxr-xr-x - user1 users 0 2016-08-04 01:59 /user/user2/.Trash/user1
{code}
To fix this, when trash enabled, even it runs rename, we need to check delete
permission because that is the intention (and the result) of the command.
Assigned to myself to work on.
was (Author: cheersyang):
Hello [~eyang] [~luisfernandoantonioli]
I was able to reproduce this issue with following steps
I created user1 and user2, they both belongs to users group
{code}
uid=1007(user1) gid=1007(user1) groups=1007(user1),100(users)
uid=1009(user2) gid=1010(user2) groups=1010(user2),100(users)
{code}
As user1
{code}
su user1
hadoop fs -mkdir /BSS/user1/
hadoop fs -put /tmp/test /BSS/user1/
hadoop chmod 600 /BSS/user1/test
{code}
As user2, try to delete /BSS/user1 directory with -skipTrash, it gives
permission denied error (expected)
{code}
su user2
hadoop dfs -rmr -skipTrash /BSS/user1/
rmr: Permission denied: user=user2, access=ALL,
inode="/BSS/user1":user1:users:drwxr-xr-x
{code}
try to delete the directory again without disabling trash,
{code}
su user2
hadoop dfs -rmr /BSS/user1/
16/08/04 01:47:53 INFO fs.TrashPolicyDefault: Namenode trash configuration:
Deletion interval = 360 minutes, Emptier interval = 0 minutes.
Moved: 'hdfs://bdavm1542.svl.ibm.com:8020/BSS/user1' to trash at:
hdfs://bdavm1542.svl.ibm.com:8020/user/user2/.Trash/Current
{code}
directory removed (unexpected).
This opens security hole that user is able to delete other user files, this
should be fixed. Agree ?
Internally, trash calls {{rename}} and rm calls {{delete}}, that's why the
behavior was not consistent, user2 has the permission to move the directory but
not to delete
{code}
su user2
hadoop dfs -mv /BSS/user1 /user/user2/.Trash
hadoop dfs -ls /user/user2/.Trash
Found 2 items
drwx------ - user2 hdfs 0 2016-08-04 01:39
/user/user2/.Trash/Current
drwxr-xr-x - user1 users 0 2016-08-04 01:59 /user/user2/.Trash/user1
{code}
To fix this, when trash enabled, even it runs rename, we need to check delete
permission because that is the intention (and the result) of the command.
Assigned to myself to work on.
> 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: fs, security
> Affects Versions: 2.2.0, 2.6.0, 2.7.2
> Reporter: Eric Yang
> Assignee: Weiwei 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)
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
