[Bug libc/13983] __libc_message() shouldn't blindly write to STDERR_FILENO

["nenolod at dereferenced dot org" <sourceware-bugzilla at sourceware dot org>]

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.