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: [email protected]
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/
