[
https://issues.apache.org/jira/browse/HDFS-6165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yongjun Zhang updated HDFS-6165:
--------------------------------
Attachment: HDFS-6165.002.patch
Thank you all for the comments and discussions and reviews.
Uploaded version 002 to fix all three issues summarized in my last update.
There are a few questions to ask you experienced folks:
1. This fix involves changing ClientNamenodeProtocol.proto by adding an
optional bit to message DeleteRequestProto to indicate whether "-f" is
specified. Is there any implication of API compatibility here?
2. This change involves both files in hadoop-common-project and
hadoop-hdfs-project, is it fine to be covered by this single JIRA?
3. To address Andrew's comments on how the test is written, I discussed with
him, and we had an agreement that it would be beneficial to have this new
testing infrastructure for FsShelll operations (TestFsShellPrivilege.java
introduced with this fix). It has the advantage of manipulating file structure,
ownership, permission, and calling FsShell with command line arguments, and
easy debugging with eclipse.
My test result with the fix:
{code}
[usrxyz@vm001 hadoop]$ hadoop fs -lsr /
lsr: DEPRECATED: Please use 'ls -R' instead.
drwxr-xr-x - hdfs supergroup 0 2014-03-25 16:29 /user
drwxr-xr-x - hdfs supergroup 0 2014-03-25 16:28 /user/hdfs
drwxr-xr-x - usrxyz users 0 2014-03-29 10:19 /user/usrxyz
drwxr-xr-x - abc users 0 2014-03-25 16:32 /user/usrxyz/foo
-rw-r--r-- 1 abc users 5 2014-03-25 16:32
/user/usrxyz/foo/test.txt
drwxr-xr-x - abc users 0 2014-03-29 10:18
/user/usrxyz/foo-empty
drwxr-xr-x - abc users 0 2014-03-29 10:18
/user/usrxyz/foo-empty1
drwxr-xr-x - abc users 0 2014-03-29 10:19
/user/usrxyz/foo-empty2
[usrxyz@vm001 hadoop]$ whoami
usrxyz
[usrxyz@vm001 hadoop]$ hdfs dfs -rm -r /user/usrxyz/foo
14/03/29 10:20:42 INFO fs.TrashPolicyDefault: Namenode trash configuration:
Deletion interval = 0 minutes, Emptier interval = 0 minutes.
rm: Permission denied: user=usrxyz, access=ALL,
inode="/user/usrxyz/foo":abc:users:drwxr-xr-x
[usrxyz@vm001 hadoop]$ hdfs dfs -rm -r /user/usrxyz/foo-empty
14/03/29 10:20:54 INFO fs.TrashPolicyDefault: Namenode trash configuration:
Deletion interval = 0 minutes, Emptier interval = 0 minutes.
rm: Permission denied: user=usrxyz, access=ALL,
inode="/user/usrxyz/foo-empty":abc:users:drwxr-xr-x. Consider trying again with
-f switch.
[usrxyz@vm001 hadoop]$ hdfs dfs -rm -r -f /user/usrxyz/foo-empty
14/03/29 10:21:06 INFO fs.TrashPolicyDefault: Namenode trash configuration:
Deletion interval = 0 minutes, Emptier interval = 0 minutes.
Deleted /user/usrxyz/foo-empty
[usrxyz@vm001 hadoop]$ hdfs dfs -rmdir /user/usrxyz/foo-empty1
[usrxyz@vm001 hadoop]$ hdfs dfs -rmdir /user/usrxyz/foo
rmdir: `/user/usrxyz/foo is non empty
[usrxyz@vm001 hadoop]$ whoami
usrxyz
[usrxyz@vm001 hadoop]$ su abc
Password:
[abc@vm001 hadoop]$ whoami
abc
[abc@vm001 hadoop]$ hdfs dfs -rmdir /user/usrxyz/foo-empty2
rmdir: Permission denied: user=abc, access=WRITE,
inode="/user/usrxyz":usrxyz:users:drwxr-xr-x
{code}
Thanks a lot for reviewing the fix.
> "hdfs dfs -rm -r" is slightly different from the Unix "rm -r" for deleting an
> empty directory
> ---------------------------------------------------------------------------------------------
>
> Key: HDFS-6165
> URL: https://issues.apache.org/jira/browse/HDFS-6165
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: hdfs-client
> Affects Versions: 2.3.0
> Reporter: Yongjun Zhang
> Assignee: Yongjun Zhang
> Priority: Minor
> Attachments: HDFS-6165.001.patch, HDFS-6165.002.patch
>
>
> Given a directory owned by user A with permissions 0700 containing an empty
> directory owned by user B, it is not possible to delete user B's directory.
> This is incorrect. Write permission on the containing directory should be all
> that is needed to delete the child directory. Here's a reproduction:
> {code}
> [root@vm01 ~]# hdfs dfs -ls /user/
> Found 4 items
> drwxr-xr-x - userabc users 0 2013-05-03 01:55 /user/userabc
> drwxr-xr-x - hdfs supergroup 0 2013-05-03 00:28 /user/hdfs
> drwxrwxrwx - mapred hadoop 0 2013-05-03 00:13 /user/history
> drwxr-xr-x - hdfs supergroup 0 2013-04-14 16:46 /user/hive
> [root@vm01 ~]# hdfs dfs -ls /user/userabc
> Found 8 items
> drwx------ - userabc users 0 2013-05-02 17:00 /user/userabc/.Trash
> drwxr-xr-x - userabc users 0 2013-05-03 01:34 /user/userabc/.cm
> drwx------ - userabc users 0 2013-05-03 01:06
> /user/userabc/.staging
> drwxr-xr-x - userabc users 0 2013-04-14 18:31 /user/userabc/apps
> drwxr-xr-x - userabc users 0 2013-04-30 18:05 /user/userabc/ds
> drwxr-xr-x - hdfs users 0 2013-05-03 01:54 /user/userabc/foo
> drwxr-xr-x - userabc users 0 2013-04-30 16:18
> /user/userabc/maven_source
> drwxr-xr-x - hdfs users 0 2013-05-03 01:40
> /user/userabc/test-restore
> [root@vm01 ~]# hdfs dfs -ls /user/userabc/foo/
> [root@vm01 ~]# sudo -u userabc hdfs dfs -rm -r -skipTrash /user/userabc/foo
> rm: Permission denied: user=userabc, access=ALL,
> inode="/user/userabc/foo":hdfs:users:drwxr-xr-x
> {code}
> The super user can delete the directory.
> {code}
> [root@vm01 ~]# sudo -u hdfs hdfs dfs -rm -r -skipTrash /user/userabc/foo
> Deleted /user/userabc/foo
> {code}
> The same is not true for files, however. They have the correct behavior.
> {code}
> [root@vm01 ~]# sudo -u hdfs hdfs dfs -touchz /user/userabc/foo-file
> [root@vm01 ~]# hdfs dfs -ls /user/userabc/
> Found 8 items
> drwx------ - userabc users 0 2013-05-02 17:00 /user/userabc/.Trash
> drwxr-xr-x - userabc users 0 2013-05-03 01:34 /user/userabc/.cm
> drwx------ - userabc users 0 2013-05-03 01:06
> /user/userabc/.staging
> drwxr-xr-x - userabc users 0 2013-04-14 18:31 /user/userabc/apps
> drwxr-xr-x - userabc users 0 2013-04-30 18:05 /user/userabc/ds
> -rw-r--r-- 1 hdfs users 0 2013-05-03 02:11
> /user/userabc/foo-file
> drwxr-xr-x - userabc users 0 2013-04-30 16:18
> /user/userabc/maven_source
> drwxr-xr-x - hdfs users 0 2013-05-03 01:40
> /user/userabc/test-restore
> [root@vm01 ~]# sudo -u userabc hdfs dfs -rm -skipTrash /user/userabc/foo-file
> Deleted /user/userabc/foo-file
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
