[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 #16 from William Pitcock <nenolod at dereferenced dot org> 2012-04-16 16:44:37 UTC ---
(In reply to comment #15)
> William, you're wrong. Undefined behavior is undefined behavior. A great
> example would be if you overflow a buffer on the stack (without fortify) and
> overwrite the return value. Now, when your program is run with input from an
> attacker, the attacker's shellcode (which is not part of your program) is able
> to write to fd #2 all it likes. This does not violate the requirements of POSIX
> because undefined behavior is undefined behavior. If you invoke undefined
> behavior, ANYTHING can happen. All bets are off. Note that, per the C standard,
> undefined behavior is even prescient. It's not just code after the UB is
> invoked that can do ANYTHING. Even code that runs conceptually before the UB is
> invoked can do anything, provided it can be determined that UB is invoked at
> some point in the program.
> 
> If you don't like this, you should be programming in Java rather than C.

If you believe that libc should blindly write to fd=2, then by all means
implement such functionality in Musl.

The fact of the matter is that there is a patch to ensure that we do not have
undefined behaviour.

If you want developers to dup2, then push for an update to POSIX.1 to have
fclose() documentation explicitly instruct people to use dup2.  There is
presently no such documentation, and the general consensus (that we should not
use STDERR_FILENO if stderr is closed) appears to be that my interpretation is
correct given the current specification.  Thusly, this *is* a bug and if it
should not be, then the specification should be corrected to allow this
behaviour.

Explicitly allowing usage of STD..._FILENO when the streams associated with
those _FILENOs have been closed would require updating the specification as
well.

-- 
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.