This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 251653

Summary: rm -rf cannot kill directory that is protected
Product: [Fedora] Fedora Reporter: Krzysio (Chris) Leszczynski <chris>
Component: coreutilsAssignee: Ondrej Vasik <ovasik>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 7   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-11-23 07:03:42 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description Krzysio (Chris) Leszczynski 2007-08-10 05:20:09 EDT
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:
always

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 07:03:42 EST
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...