|
From: | Paul Eggert |
Subject: | Re: handling of closed file descriptors |
Date: | Sun, 6 Jan 2019 18:05:15 -0800 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 |
Thanks for writing all that. One comment about the list containing this item:
Isn't the problem more general than what this list suggests? Considering the list item quoted above, even if your program opens just one file descriptor, if that happens to be fd 2 and your program writes to the file and also accesses fd 2 for an error message, you can be in trouble.address@hidden +If your program opens only one new file descriptor or FILE stream at a time, +it is @emph{not affected}.
The situation is complicated a bit by the fact that the stdin stream might correspond to some file descriptor other than fd 0 after freopen is called, and similarly for stdout and stderr.
I suggest simplifying the list by replacing the list with something like the following. This statement may be a bit too broad, but it's much simpler (which is good) and being too broad is better than being too narrow.
"Your program is vulnerable if it opens a file descriptor or stream, and then while the file is open your program accesses file descriptors 0, 1, or 2 either directly or indirectly via the stdin, stdout, or stderr streams."
[Prev in Thread] | Current Thread | [Next in Thread] |