[bug #27369] 'ftsfind -ok ... <&-' attempts to read directory fd

[anonymous-98]

URL:
  <http://savannah.gnu.org/bugs/?27369>

                 Summary: 'ftsfind -ok ... <&-'  attempts to read directory
fd
                 Project: findutils
            Submitted by: ericb
            Submitted on: Tue 01 Sep 2009 10:52:09 AM MDT
                Category: find
                Severity: 3 - Normal
              Item Group: Wrong result
                  Status: Confirmed
                 Privacy: Public
             Assigned to: ericb
         Originator Name: Eric Blake
        Originator Email: ebb9@...
             Open/Closed: Open
         Discussion Lock: Any
                 Release: None
           Fixed Release: None

    _______________________________________________________

Details:

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.





    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?27369>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/

[anonymous-98]

Follow-up Comment #1, bug #27369 (project findutils):

We are NOT consistently using the gnulib *_safer modules.  Both find.c and
ftsfind.c called unprotected open() in main(), and ftsfind.c called
unprotected dup().  Furthermore, find.c uses the closein module, but ftsfind.c
only used the closeout module.

We need at least this patch in addition to bumping import-gnulib.config to
the latest gnulib (although I'm toying with the idea of making defs.h just
include all the headers up front, rather than trying to the includes of each
affected file).  This patch would also need a NEWS entry and testsuite
addition.


(file #18670)
    _______________________________________________________

Additional Item Attachment:

File name: findutils.patch1               Size:3 KB


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?27369>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/