Bug 251653 - rm -rf cannot kill directory that is protected
Summary: rm -rf cannot kill directory that is protected
Alias: None
Product: Fedora
Classification: Fedora
Component: coreutils   
(Show other bugs)
Version: 7
Hardware: All
OS: All
Target Milestone: ---
Assignee: Ondrej Vasik
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2007-08-10 09:20 UTC by Krzysio (Chris) Leszczynski
Modified: 2007-11-30 22:12 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-11-23 12:03:42 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Krzysio (Chris) Leszczynski 2007-08-10 09:20:09 UTC
Description of problem:
rm -f kills files even if the user doesn't have write permission.
But it doesn't remove directories

Version-Release number of selected component (if applicable):
all versions of core utils.

How reproducible:

Steps to Reproduce:
1. mkdir -p a/b/c
2. chmod 0 a
3. rm -rf a
Actual results:
"a" is not removed even if rm could change its permission. The unix manual
incorrectly states that one should do chown +rwx first. This is incorrect,
because some of files could be hard-linked to others. Oh, ther

Expected results:
I'd expect rm to try hard to remove the directory by changing its mode. If it
can't remove the directory it should restore the mode. It would be even better
if it try to chmod just to read and then chmod just to x to remove subdirs.
It's hard to do safely and simply by shell script.

Additional info:

Comment 1 Ondrej Vasik 2007-11-23 12:03:42 UTC
Sorry, that's not good idea. This will allow to use rm -rf / even without root
writing rights to wipeout entire disk... 

Just want to say that rm -f DOESN'T kill the files if the user DOESN'T have
write permissions for current directory. Permissions on file itself are irrelevant. 

citation from wikipedia(Because it is correct and easy to use in this case):

"Usually, on most filesystems, deleting a file requires write permission on the
parent directory (and execute permission, in order to enter the directory in the
first place). (Note that, confusingly for beginners, permissions on the file
itself are irrelevant.)

To delete a directory (with rm -r), one must delete all of its contents
recursively. This requires that one must have write and execute permission to
that directory (if it's not empty) and all non-empty subdirectories recursively
(if there are any). This sometimes leads to an odd situation where a non-empty
directory cannot be deleted because one doesn't have write permission to it and
so cannot delete its contents; but if the same directory were empty, one would
be able to delete it.

If a file resides in a directory with the sticky bit set, then deleting the file
requires one to be the owner of the file."

NOTABUG for me...

Note You need to log in before you can comment on or make changes to this bug.