Date: Wed, 25 Feb 1998 15:19:54 -0500 (EST) From: Robert Watson <robert@cyrus.watson.org> To: "David E. Tweten" <tweten@frihet.com> Cc: Cy Schubert - ITSD Open Systems Group <cschuber@uumail.gov.bc.ca>, freebsd-security@FreeBSD.ORG Subject: Re: Find, Rm, and Root's Crontab Message-ID: <Pine.BSF.3.96.980225150111.18575B-100000@trojanhorse.pr.watson.org> In-Reply-To: <199802251750.JAA05503@ns.frihet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 25 Feb 1998, David E. Tweten wrote: > Concerning use by root of find -delete, cschuber@uumail.gov.bc.ca said: > >A race condition can exist because the time it takes, however small, > >between finding a file that should be deleted and issuing the > >remove(3) or unlink(2) call. The instruction stream in find could be > >interrupted and another process, possibly a process racing with find > >to insert a symlink into the tree, could get control. > > If I'm not misreading the man page and if it is an accurate reflection of the > code, that race should not be a problem. Of "-delete", the man page says, > "This executes from the current working directory as find recurses down the > tree. It will not attempt to delete a filename with a ``/'' character in its > pathname relative to "." for security reasons." Since the current working > directory is held as an inode, not as a path, "-delete" should not be able to > get out of sync with the rest of find, even if someone inserts a symbolic > link into the path to the current working directory. It still looks safe to > me. I am concerned that the following race condition may exist, but have not looked at the find code: 1) Find retrieves directory contents 2) Find determines which are directories, and recurses to them If find opens each directory entry, fstats the fd, then fchdirs to the fd, does business (recurding through and unlinking contents), and returns out unlinking on the way, all is well. If it retrieves contents and stats them, but then chdirs to them without using fchdir, find could suffer from a race attack if the directory were replaced with a symlink to another directory in between the two calls. For example, I create /tmp/beans; find begins executing and sees /tmp/beans -- it determines it is a directory. I remove /tmp/beans and replace it with a symlink to /var/log. Now find recurses into the directory and mayhem ensues. Note that I have not read the code and am merely talking about how it may be implemented, not how it is. :) This can occur even with the use of chdir to the directory for removal. Robert N Watson Carnegie Mellon University http://www.cmu.edu/ SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org http://www.watson.org/~robert/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.980225150111.18575B-100000>