Re: Changes to the filesystem while find is running - comments?

[Solar Designer]

On Mon, Nov 22, 2004 at 10:05:04AM -0800, Martin Buchholz wrote:
> Before a chdir to "foo", take stock:
> - record stat(".");  DOTFD = open("."); (get a fd to ".")
> - record stat("foo"); (make sure foo is a regular directory)
> Then
> - chdir "foo"
> - stat("."); compare dev, inode with recorded stat("foo")
> - if different, we suspect either symlinks or automounter.
> In this case, go back to original directory.
> - if we have fchdir, then
>   fchdir(DOTFD); and try again.  give up if we fail a second
>   time.  This means that a very rare collision with an
>   asynchronous symlink creation will not be fatal;

This sounds reasonable.

> - If we don't have fchdir, getting back to the parent might be
>   tougher.  In the case of the automounter, we can do chdir(".."),
>   then stat(".") and check that we're back in original directory.
>   If that doesn't work, we chdir("/absolute/real/path/to/parent"),
>   again stat(".") and compare dev/inode with saved stat of parent
>   directory.

That last fallback would be a security hole.  The long path to parent
might have gotten intermediate directories replaced with symlinks to
somewhere outside of the intended directory tree while we were running.

> The functional programming people might suggest,
> instead of a stack of open fd, forking and chdiring
> whenever a subdir is explored.  In this case
> getting back to the parent is simply exit().
> But this is very likely to be too inefficient
> in the Real World.

tmpwatch once had a forkbomb feature like that.  That was then fixed
as a security bug; current versions of tmpwatch don't use this approach.

-- 
Alexander Peslyak <solar at openwall.com>
GPG key ID: B35D3598  fp: 6429 0D7E F130 C13E C929  6447 73C3 A290 B35D 3598
http://www.openwall.com - bringing security into open computing environments