[
https://issues.apache.org/jira/browse/HDFS-6165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13954803#comment-13954803
]
Yongjun Zhang commented on HDFS-6165:
-------------------------------------
Hello [~daryn],
I did the same set of experiments on my OS and saw different results than
yours. It indicates different OS implements it differently.
Platform, user and command info
{code}
[usrxyz@yjzsn ~]$ whoami
usrxyz
[usrxyz@yjzsn ~]$ groups usrxyz
usrxyz : usrxyz
[usrxyz@yjzsn ~]$ which rm
/bin/rm
[usrxyz@yjzsn ~]$ alias | grep rm
[usrxyz@yjzsn ~]$ uname -a
Linux yjzsn 2.6.32-358.2.1.el6.x86_64 #1 SMP Wed Mar 13 00:26:49 UTC 2013
x86_64 x86_64 x86_64 GNU/Linux
[usrxyz@yjzsn ~]$ cat /etc/*release*
CentOS release 6.4 (Final)
LSB_VERSION=base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch
cat: /etc/lsb-release.d: Is a directory
CentOS release 6.4 (Final)
CentOS release 6.4 (Final)
cpe:/o:centos:linux:6:GA
{code}
Test 1 (no permissions)
{code}
[usrxyz@yjzsn ~]$
[usrxyz@yjzsn ~]$ mkdir -p test/bar; sudo chown root test/bar; sudo chmod a=
test/bar
[usrxyz@yjzsn ~]$ ls -lrt -R test
test:
total 4
d--------- 2 root usrxyz 4096 Mar 30 11:56 bar
ls: cannot open directory test/bar: Permission denied
[usrxyz@yjzsn ~]$ rm -rf test
{code}
Test 2 (no read perm)
{code}
[usrxyz@yjzsn ~]$ mkdir -p test/bar; sudo chown root test/bar; sudo chmod a=x
test/bar
[usrxyz@yjzsn ~]$ rm -rf test
[usrxyz@yjzsn ~]$
{code}
Test 3 (has read perm and -f)
{code}
[usrxyz@yjzsn ~]$ mkdir -p test/bar; sudo chown root test/bar; sudo chmod a=r
test/bar
[usrxyz@yjzsn ~]$ rm -rf test
[usrxyz@yjzsn ~]$
{code}
Test 4 (has read perm and no -f, prompt)
{code}
[usrxyz@yjzsn ~]$ mkdir -p test/bar; sudo chown root test/bar; sudo chmod a=r
test/bar
[usrxyz@yjzsn ~]$ rm -r test
rm: remove write-protected directory `test/bar'? n
[usrxyz@yjzsn ~]$
{code}
Test 5 (has read perm, no STDIN):
{code}
[usrxyz@yjzsn ~]$ mkdir -p test/bar; sudo chown root test/bar; sudo chmod a=r
test/bar
[usrxyz@yjzsn ~]$ perl -e 'close(STDIN); system("rm -r test")'
[usrxyz@yjzsn ~]$
{code}
Quick summary: on CentOs, both "rmdir" and "rm -r -f " removes empty subdir,
even if the empty subdir
doesn't have read permission. It even delete when there is no permission at all.
These experiments are just for info collection purpose. I think we should
probably comply with the most stringent system
rather than the most relaxing system.
BTW, Please ignore my earlier comment about "BTW, your second to last
experiment..."), I interpreted it incorrectly.
Thanks.
> "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,
> HDFS-6165.003.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)
