[
https://issues.apache.org/jira/browse/HDFS-11100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15765280#comment-15765280
]
Wei-Chiu Chuang commented on HDFS-11100:
----------------------------------------
Note that HDFS is not meant to be _Linux compatible_, rather, it's meant to be
*POSIX-compatible*
Quoting _Hadoop Security_ on sticky bit:
{quote}
... it \[sticky bit\] means that files in a directory can only be deleted by
the owner of that file. Without the sticky bit set, a file can be deleted by
anyone that has write access to the directory. In HDFS, the owner of a
directory and the HDFS superuser can also delete files regardless of whether
the sticky bit is set. The sticky bit is useful for directories, such as /tmp,
where you want all users to have write access to the directory but only the
owner of the data should be able to delete data.
{quote}
The Linux's behavior is documented/defined here:
http://man7.org/linux/man-pages/man1/chmod.1.html
{quote}
RESTRICTED DELETION FLAG OR STICKY BIT
The restricted deletion flag or sticky bit is a single bit, whose
interpretation depends on the file type. For directories, it
prevents unprivileged users from removing or renaming a file in the
directory unless they own the file or the directory; this is called
the restricted deletion flag for the directory, and is commonly found
on world-writable directories like /tmp. For regular files on some
older systems, the bit saves the program's text image on the swap
device so it will load more quickly when run; this is called the
sticky bit.
{quote}
However, I found no mention of sticky bit handling in Open Group specification
regarding rm command:
http://pubs.opengroup.org/onlinepubs/009695399/utilities/rm.html
This wikipage describes the behavior of removing files under sticky-bit
attributed directories: https://en.wikipedia.org/wiki/Sticky_bit
As you can see, there is no common behavior across all Unix-like operating
systems. But for operating systems that use sticky bit to protect files
removals, HDFS's behavior is definitely different. So I think it's safe to say
the old behavior is unexpected to most Unix-like users, and the new behavior is
what most Unix-like users would expect.
> Recursively deleting file protected by sticky bit should fail
> -------------------------------------------------------------
>
> Key: HDFS-11100
> URL: https://issues.apache.org/jira/browse/HDFS-11100
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: fs
> Affects Versions: 2.6.0
> Reporter: John Zhuge
> Assignee: John Zhuge
> Priority: Critical
> Labels: permissions
> Attachments: HDFS-11100.001.patch, HDFS-11100.002.patch,
> HDFS-11100.003.patch, hdfs_cmds
>
>
> Recursively deleting a directory that contains files or directories protected
> by sticky bit should fail but it doesn't in HDFS. In the case below,
> {{/tmp/test/sticky_dir/f2}} is protected by sticky bit, thus recursive
> deleting {{/tmp/test/sticky_dir}} should fail.
> {noformat}
> + hdfs dfs -ls -R /tmp/test
> drwxrwxrwt - jzhuge supergroup 0 2016-11-03 18:08
> /tmp/test/sticky_dir
> -rwxrwxrwx 1 jzhuge supergroup 0 2016-11-03 18:08
> /tmp/test/sticky_dir/f2
> + sudo -u hadoop hdfs dfs -rm -skipTrash /tmp/test/sticky_dir/f2
> rm: Permission denied by sticky bit: user=hadoop,
> path="/tmp/test/sticky_dir/f2":jzhuge:supergroup:-rwxrwxrwx,
> parent="/tmp/test/sticky_dir":jzhuge:supergroup:drwxrwxrwt
> + sudo -u hadoop hdfs dfs -rm -r -skipTrash /tmp/test/sticky_dir
> Deleted /tmp/test/sticky_dir
> {noformat}
> Centos 6.4 behavior:
> {noformat}
> $ ls -lR /tmp/test
> /tmp/test:
> total 4
> drwxrwxrwt 2 systest systest 4096 Nov 3 18:36 sbit
> /tmp/test/sbit:
> total 0
> -rw-rw-rw- 1 systest systest 0 Nov 2 13:45 f2
> $ sudo -u mapred rm -fr /tmp/test/sbit
> rm: cannot remove `/tmp/test/sbit/f2': Operation not permitted
> $ chmod -t /tmp/test/sbit
> $ sudo -u mapred rm -fr /tmp/test/sbit
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
