bugfindutils - Bugs: bug #27369, 'ftsfind -ok ... <&-' ...


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

Submitted by:  Eric Blake <ericb>
Submitted on:  Tue Sep 1 16:52:09 2009  
Category: findSeverity: 3 - Normal
Item Group: Wrong resultStatus: Code Review
Privacy: PublicAssigned to: Eric Blake <ericb>
Originator Name: Eric BlakeOpen/Closed: Open
Release: NoneFixed Release: None

Add a New Comment (Rich MarkupRich Markup):

You are not logged in

Please log in, so followups can be emailed to you.


Mon Dec 28 19:12:04 2015, comment #5:

Eric, are you still working on this bug?

James Youngman <jay>
Project Administrator
Sun Sep 29 19:54:45 2013, comment #4:

Eric, are you still working on this bug?

James Youngman <jay>
Project Administrator
Sat May 14 23:42:51 2011, comment #3:

Git implies that at least one of these patches was applied as 56682c9ff55c8de70f1c67129e2f82d0c4605385, in April last year.

Is this bug fixed already?

James Youngman <jay>
Project Administrator
Sun Apr 11 11:42:04 2010, comment #2:

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)

James Youngman <jay>
Project Administrator
Wed Sep 2 18:20:04 2009, comment #1:

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)

Eric Blake <ericb>
Project AdministratorIn charge of this item.
Tue Sep 1 16:52:09 2009, original submission:


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.

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.

Eric Blake <ericb>
Project AdministratorIn charge of this item.


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):

Attached Files
file #20192:  0001-Don-t-error-out-if-stdin-stdout-stderr-was-already-c.patch added by jay (3kB - text/x-patch - Patch against gnulib to avoid spurious errors when stdin/out/err is closed)
file #20193:  0001-Make-sure-we-don-t-open-a-file-on-a-standard-fd-that.patch added by jay (2kB - text/x-patch - Patch against gnulib to avoid spurious errors when stdin/out/err is closed)
file #18670:  findutils.patch1 added by ericb (3kB - application/octet-stream)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by jay (Updated the item)
  • -unavailable- added by ericb (Submitted the item)

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.


    Please enter the title of George Orwell's famous dystopian book (it's a date):



    Follow 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun Apr 11 12:51:45 2010jayStatusConfirmed=>Code Review
    Sun Apr 11 11:42:04 2010jayAttached File-=>Added 0001-Don-t-error-out-if-stdin-stdout-stderr-was-already-c.patch, #20192
      Attached File-=>Added 0001-Make-sure-we-don-t-open-a-file-on-a-standard-fd-that.patch, #20193
    Wed Sep 2 18:20:04 2009ericbAttached File-=>Added findutils.patch1, #18670

    Back to the top

    Powered by Savane 3.1-cleanup1