This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/13983] __libc_message() shouldn't blindly write to STDERR_FILENO
- From: "nenolod at dereferenced dot org" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: Mon, 16 Apr 2012 07:02:41 +0000
- Subject: [Bug libc/13983] __libc_message() shouldn't blindly write to STDERR_FILENO
- Auto-submitted: auto-generated
- References: <bug-13983-131@http.sourceware.org/bugzilla/>
http://sourceware.org/bugzilla/show_bug.cgi?id=13983
--- Comment #6 from William Pitcock <nenolod at dereferenced dot org> 2012-04-16 07:02:41 UTC ---
(In reply to comment #4)
> Personally, I would flag this INVALID. The only times __libc_message message
> are called are when the calling program has already invoked undefined behavior,
> so there is no question of whether this violating requirements of POSIX; once
> you invoke UB, POSIX has nothing more to say.
No. POSIX has something to say: don't write to stderr (including STDERR_FILENO)
if someone closed it. See Austin Group bug #555.
Invoking undefined behaviour by causing a memory error or fortify error does
not give the libc license to invoke further undefined behaviour. Sorry, but it
doesn't.
>
> With that said, there is some security argument to be made for avoiding
> potentially-dangerous writes. However, I think it's mostly nullified by the
> stupidity of closing fd 2. The correct way to suppress stderr is to open
> /dev/null and dup2 it onto fd 2.
This is not presently mandated by POSIX. See Austin Group bug #555. I have
suggested to them that they should mandate this in their specification for
fclose(). That said, we still should not blindly write to STDERR_FILENO.
> If you close any of the standard file descriptors, it's your responsibility
> to make sure that no further file descriptors are created, or if they are,
> that no functions that would perform io on the new file descriptor expecting
> it to be one of the standard streams can be called.
Which is impossible because libc blindly performs I/O on the new file
descriptor because it calls writev() on STDERR_FILENO, without checking if it
is still stderr or not. This is at least presently incorrect per POSIX, unless
such a crash debugger is explicitly requested by the end user. See Austin
Group bug #555.
>
> Note that isatty is not sufficient to avoid clobbering unrelated data; there
> are plenty of non-interactive (even non-tty-like) uses for ptys, and one could
> envision uses where erroneously writing text directed for stderr into them
> could be very destructive.
As I said in comment 3, isatty is not a sufficient diagnostic anyway.
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.