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:
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...