rm -F

[simont]

The build system at work occasionally generates entire directory trees full of files and directories with read-only permissions. Trying to delete such a directory is always a pain, because the procedure goes something like

• rm -rf directory
• rm gets EPERM on every file in a read-only subdirectory
• swear
• chmod -r +w directory
• chmod tries to take the r permission away from the nonexistent file +w
• swear
• chmod -R +w directory
• chmod now gets EPERM, because the previous invocation also successfully took the r permission away from directory
• swear
• chmod -R +rw directory
• rm -rf directory

… and since I mostly try to avoid generating these directories in the first place, this happens just infrequently enough that the next time I've forgotten all the pitfalls and do pretty much the same thing again.

What I want is for rm to support the -F option, which is like -f except that it also authorises rm to temporarily restore write permission (if permitted to) on any directory from which the lack of it is preventing it from deleting a file. Or possibly it should only be allowed to do that if the directory is one it's planning to delete completely later in the operation anyway; that might be safer. But either way, the point is, if the Unix permissions system makes it possible in principle to arrange for the directory not to be there any more, then I want to be able to get rm to just do so, by any means necessary short of requesting the root password, and not bother me with trivial details of how.

Comments

[emperor]

rm -FFS ? :-)

[simont]

Since you mention it, I did have a clear idea about what -F should stand for. My official rationale is that it's the upper-case form of the existing -f, but really it stands for "F**KING DO IT THIS TIME!".

[ewx.livejournal.com]

Personally I think -f ought to do whatever it takes to remove the files, but it's probably too late for that.

[gerald_duck]

Thinking about it, I agree. Though I'm not in the habit of ending up with directories I own but can't modify, anyway.

Meanwhile, thinking about it I also have a nasty feeling in my waters: is rm -r secure? Particularly, what if someone suddenly replaces a subdirectory with a symlink to another point in the filesystem?

Hohum…

[mooism.livejournal.com]

Doesn’t it just remove the symlink? I suppose a hard link would be different.

[gerald_duck]

What I had in mind was:

• rm -r starts deleting stuff
  
• It determines that foo is a subdirectory
  
• A Bad Person quickly does mv foo old-foo; ln -s /home/victim foo
  
• rm -r descends into foo, which is now in reality the victim's home directory
  
• It recursively deletes everything it finds there.

I suspect the GNU version, at least, checks this hasn't happened. But I'm not sure, and I really ought to know.

[mooism.livejournal.com]

Oh, a race condition; argh.

[cjwatson]

  /* There is a race condition in that an attacker could replace the nonempty
     directory, DIR, with a symlink between the preceding call to rmdir
     (in our caller) and the chdir below.  However, the following lstat,
     along with the `stat (".",...' and dev/ino comparison in AD_push
     ensure that we detect it and fail.  */

(coreutils-5.96/src/remove.c:remove_dir(); not quite current but I had it handy.)