[14836] in bugtraq
Re: Race condition in "rm -r"
daemon@ATHENA.MIT.EDU (Glynn Clements)
Mon May 8 14:49:45 2000
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <14614.7796.34344.270862@cerise.sensei.co.uk>
Date: Mon, 8 May 2000 02:55:00 +0100
Reply-To: Glynn Clements <glynn@SENSEI.CO.UK>
From: Glynn Clements <glynn@SENSEI.CO.UK>
X-To: abs@mono.org
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <Pine.NEB.4.21.0005071952120.2199-100000@IP113.BM.PurpleI.com>
abs@mono.org wrote:
> > > 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.
>
> 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.
> 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.
--
Glynn Clements <glynn@sensei.co.uk>
