bug-findutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eric Blake
Subject: [bug #27369] 'ftsfind -ok ... <&-' attempts to read directory fd
Date: Tue, 01 Sep 2009 16:52:10 +0000
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2 (.NET CLR 3.5.30729)

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: address@hidden
             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/





reply via email to

[Prev in Thread] Current Thread [Next in Thread]