Eric, are you still working on this bug?

Subsequent changes to findutils have led to differences in the needed patch.   I attach a modified path plus a change to gnulib to avoid an unnecessary error message.

(file #20192, file #20193)

http://lists.gnu.org/archive/html/bug-gnulib/2009-08/msg00406.html

When executing ftsfind with stdin closed, find ends up reading from stdin while a directory fd occupies position 0, rather than failing because stdin was closed.  On Linux, the read just returns EOF, and the -ok test passes with no indication in the overall find exit status, forming a regression from oldfind's behavior.  And on systems where calling read() on a directory succeeds in retrieving binary information, such as EMX OS/2, this could be classified as a minor security bug, as find then tries to make decisions based on the contents of a directory.

$ find dir -mindepth 1 -ok echo {} \; <&-
< echo ... dir/sub > ?
$ echo $?
0
$ oldfind dir -mindepth 1 -ok echo {} \; <&-
< echo ... dir/sub > ? oldfind: error closing file
$ echo $?
1

There might be related bugs with starting find with stdout or stderr closed, although we are already consistently using the existing gnulib *_safer modules, and opening a read-only directory fd in slot 1 or 2 generally provokes a reasonable failure when writing via stdout/stderr.  In other words, I don't think there are any other cases where our use of stdio is jeopardized by rogue fds.

The fix is to update to the latest gnulib once my new dirent-safer module is implicitly used by fts, thus guaranteeing that no directory fd's will ever interfere with stdin in a single-threaded process.