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.
Steps to Reproduce:
1. mkdir -p a/b/c
2. chmod 0 a
3. rm -rf a
"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
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.
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...