O_NOFOLLOWThe strategy for preventing this type of problem on systems that lack
support for the O_NOFOLLOW flag is more complex. Each time
find changes directory, it examines the directory it is about
to move to, issues the chdir() system call, and then checks
that it has ended up in the subdirectory it expected. If all is as
expected, processing continues as normal. However, there are two main
reasons why the directory might change: the use of an automounter and
someone removing the old directory and replacing it with something
else while find is trying to descend into it.
Where a filesystem “automounter” is in use it can be the case that
the use of the chdir() system call can itself cause a new
filesystem to be mounted at that point. On systems that do not
support O_NOFOLLOW, this will cause find’s security check to
fail.
However, this does not normally represent a security problem, since
the automounter configuration is normally set up by the system
administrator. Therefore, if the chdir() sanity check fails,
find will make one more attempt5. If that succeeds, execution
carries on as normal. This is the usual case for automounters.
Where an attacker is trying to exploit a race condition, the problem
may not have gone away on the second attempt. If this is the case,
find will issue a warning message and then ignore that
subdirectory. When this happens, actions such as ‘-exec’ or
‘-print’ may already have taken place for the problematic
subdirectory. This is because find applies tests and actions
to directories before searching within them (unless ‘-depth’ was
specified).
Because of the nature of the directory-change operation and security
check, in the worst case the only things that find would have
done with the directory are to move into it and back out to the
original parent. No operations would have been performed within that
directory.