Re: Race condition in "rm -r"

[glynn () SENSEI CO UK (Glynn Clements)]

[Haven't we been here before?]

Morten Welinder wrote:

>   If root ever does "rm -rf /tmp/foo" for a directory structure
>   not completely owned by root,

Did you mean the last line literally? Or do you mean "with unsafe
write permissions"?

> a local user can delete all files
>   that root can.

Note that the same applies to non-root users. I.e. if a normal user
runs "rm -rf" on a directory to which unsafe accounts have write
permission, they could be tricked into deleting arbitrary files (from
directories on which they have write permission).

>   Such deletions are common for (a) /tmp cleanup and (b) before
>   creating a specific directory in /tmp/.

They shouldn't be. I believed it to be generally understood that using
"rm -rf" in /tmp was a bad idea.

> Details:
>
>   "rm -r" implementations (Solaris 7, Gnu 4.0 checked) walk the
>   directories, lstats files, and chdirs into directories (and
>   recurs).  Oh, and deletes stuff, of course.
>
>   It is possible to replace a directory by a symlink, say "/",
>   and have rm cheerfully follow it.
>
>   The race window is small -- it will take thousands upon thousands
>   of tries.  Moreover, since the racing involves rmdir -- which
>   typically is not very fast -- you'll need patience and "nice"
>   and any other help you can get.
>
>
> Solutions:

Use a statically-linked "rm" and "chroot /tmp" first.

>   Maybe stat "." after chdir to verify that we ended up the
>   expected place?

My "rm" (GNU fileutils 4.0) does this:

    getdents(3, /* 45 entries */, 3933)     = 924
    lstat("Imakefile", {st_mode=S_IFREG|0644, st_size=2842, ...}) = 0
    unlink("Imakefile")                     = 0
    lstat("pixmaps", {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
    chdir("pixmaps")                        = 0
    close(3)                                = 0
1>  open(".", O_RDONLY|O_NONBLOCK)          = 3
    fcntl(3, F_SETFD, FD_CLOEXEC)           = 0
2>  fstat(3, {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
    lseek(3, 0, SEEK_CUR)                   = 0
    getdents(3, /* 49 entries */, 3933)     = 1112
    lstat("about.xpm", {st_mode=S_IFREG|0644, st_size=43055, ...}) = 0
    unlink("about.xpm")                     = 0
    lstat("apple.xpm", {st_mode=S_IFREG|0644, st_size=927, ...}) = 0
    unlink("apple.xpm")                     = 0

Any suggestions as to why it is doing the fstat() in (2) if it isn't
checking for symlink games? [Note: I'm not saying that it *is*
checking, just that it seems odd if it isn't.]

> Also affected:
>
>   chmod, chown, chgrp.  (Probably; this is guesswork.)

... and every other program that modifies the filesystem in any way,
unless it jumps through the same hoops.

If, that is, you let them near directories with unsafe permissions.

In the long term, there are three main options:

1. Abolish symlinks. This might be considered overkill, though.

2. Write every program as if it was a /tmp cleaner. I.e. never pass
full pathnames to system calls, but chdir() down one level at a time
from "/", [lf]stat()ing as you go and never following symlinks, then
open("./filename"). In which case, you may as well abolish symlinks.

3. Don't do dangerous things in world-writable directories. Better
still, get rid of world-writable directories altogether; it isn't that
difficult. IOW, fix the bug, not the symptoms.

And if users can do dodgy things in directories which aren't
world-writable, then that's a bug in itself.

There is a line of though that says that it isn't the responsibility
of every single program to deal with situations which should not be
allowed to occur in the first place.

--
Glynn Clements <glynn () sensei co uk>