Re: Why does close_stdout close stdout and stderr?

From: Bruno Haible <bruno@clisp.org>
To: bug-gnulib@gnu.org
Cc: Florian Weimer <fweimer@redhat.com>,
	Kamil Dudka <kdudka@redhat.com>, Paul Eggert <eggert@cs.ucla.edu>,
	Jeff Layton <jlayton@redhat.com>,
	Bernhard Voelker <mail@bernhard-voelker.de>,
	NeilBrown <neilb@suse.com>, Eric Blake <eblake@redhat.com>
Subject: Re: Why does close_stdout close stdout and stderr?
Date: Sat, 25 May 2019 13:24:39 +0200	[thread overview]
Message-ID: <1981329.u6ql5j3YLz@omega> (raw)
In-Reply-To: <87mujqj0tt.fsf@oldenburg2.str.redhat.com>

Florian Weimer wrote in
<https://lists.gnu.org/archive/html/bug-gnulib/2019-05/msg00087.html>:
> The relevant case is where there is no error, and we do not call _exit.
> I'm worried that the current implementation introduces a use-after-free
> bug under certain, quite reasonable circumstances.  All that is needed
> is a shared object that tries to log something to stderr from an ELF
> destructor.  I don't think that's something that can be ruled out, or
> can be assumed to happen in development environments only.

OK, now you have described the problem in an understandable way.

Let me rephrase the dilemma:

  1) POSIX guarantees that we can detect write errors [up to the file
     system layer of the kernel - I'm not worried about I/O errors on
     the actual device] through fclose(), and kernels implement this.
     Neither POSIX nor Linux guarantees that we can detect write errors
     without calling fclose().

  2) POSIX says "After the call to fclose(), any use of stream results in
     undefined behavior." [1]

So, we need to call fclose(stderr) at a moment when we know that stderr
will not be used any more.

We have
  * applications (like the coreutils programs), and
  * environments which can modify the behaviour of these applications,
    like shared objects added through LD_PRELOAD, or sanitizers [2].

The solution I would propose is to
  - By default, assume that the environment does not modify the behaviour
    of the application. That is, that the application executes its code
    and nothing more.
  - Let the environment tell the application (through an environment
    variable) that it is modifying its behaviour.

For the first case, the current 'closeout' module is perfect.

For the other case, we can introduce, next to the !SANITIZE_ADDRESS test,
tests for
  getenv ("LD_PRELOAD") != NULL
  getenv ("ASAN_OPTIONS") != NULL
  getenv ("TSAN_OPTIONS") != NULL
  getenv ("MSAN_OPTIONS") != NULL
  getenv ("LSAN_OPTIONS") != NULL
We can add more such environment variables as needed. getenv() lookups
don't make system calls; so they are cheap.

Bruno

[1] https://pubs.opengroup.org/onlinepubs/9699919799/functions/fclose.html
[2] https://github.com/google/sanitizers/wiki/SanitizerCommonFlags