Re: Race condition in "rm -r"

[abs () MONO ORG (David Brownlee)]

On Mon, 8 May 2000, Glynn Clements wrote:

> > > 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.
> >
> >     4. Add an option to not traverse symlinks in system calls.
>
> That seems somewhat like option 2, but with the code in the kernel or
> the standard library. There doesn't seem to be much point in having
> symlinks if programs religiously refuse to follow them.
        You would only set the option in programs that need to traverse
        a directory tree without following symlinks - something like
        ignore_symlinks(1) and ignoresymlinks(0).

> >        Call realpath() on initial argument before setting.
>
> Does that help any? I would have thought that it would suffer from
> exactly the same sort of race conditions. On a pre-emptive
> multi-tasking OS, any system call that returns information about
> shared structures (e.g. the filesystem) is returning information about
> the past, which may not match the present.

        This is in combination with the above - if you're ignoring
        symlinks and the path of the initial argument contains a symlink,
        you need to realpath() it before you can proceed.

                David/absolute
                                       -- www.netbsd.org: No hype required --