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

 
 

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

Submitter:  Eric Blake <ericb>
Submitted:  Tue 01 Sep 2009 04:52:09 PM UTC
 
Category:  find Severity:  3 - Normal
Item Group:  Wrong result Status:  Code Review
Privacy:  Public Assigned to:  ericb
Originator Name:  Eric Blake Open/Closed:  Open
Release:  None Fixed Release:  None
* Mandatory Fields

Add a New Comment (Rich Markup)
   

Comment Type & Canned Response:
       

 

Mon 28 Dec 2015 07:12:04 PM UTC, comment #5: 

Eric, are you still working on this bug?

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

Eric, are you still working on this bug?

James Youngman <jay>
Project Administrator
Sat 14 May 2011 11:42:51 PM UTC, 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 11 Apr 2010 11:42:04 AM UTC, 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 02 Sep 2009 06:20:04 PM UTC, 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 Administrator
Tue 01 Sep 2009 04:52:09 PM UTC, original submission:  

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.

Eric Blake <ericb>
Project Administrator

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #20192:  0001-Don-t-error-out-if-stdin-stdout-stderr-was-already-c.patch added by jay (3KiB - 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 (2KiB - text/x-patch - Patch against gnulib to avoid spurious errors when stdin/out/err is closed)
file #18670:  findutils.patch1 added by ericb (3KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

     

     

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-04-11 jay StatusConfirmed Code Review
    2010-04-11 jay Attached 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
    2009-09-02 ericb Attached File- Added findutils.patch1, #18670

    Back to the top


    Powered by Savane 3.9