This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] abort: Only flush file-based stdio streams before termination
On 08/21/2017 04:20 AM, Florian Weimer wrote:
> On 08/21/2017 09:23 AM, Andreas Schwab wrote:
>> On Aug 17 2017, Florian Weimer <firstname.lastname@example.org> wrote:
>>> In your opinion, should we remove the flushing altogether?
>> Yes. abort must be thread-safe, and there is no way to do flushing
>> without locking.
> In the current implementation, yes.
> Carlos, do you still think we must continue to flush on abort?
> I'm concerned that the current is state (the abort mechanism can be
> abused for code execution) is desired by no one, and a squabble over the
> ideal behavior of a from-scratch stdio prevents us from applying
> incremental improvements to the code we have today.
Conceptually I am OK with removing *all* flushing on abort.
It is the *partial* flushing for which I have stronger opinions about
what should and should not get flushed.
For the removal of all flushing I would like to think through all of
the consequences including answering:
(a) How do authors get back the previous behaviour in the event they
need it during a transition period?
(a.1) Can we offer a tunable for a few releases to allow authors
to put back the flush (ignored for secure processes)?
(b) How do we explain to application authors that we will no longer
support any flushing during abort, and that what is left in the
buffers is unrecoverable? Is it purely an argument about security
and the complexity of attack vectors?
(c) Do we provide better documentation for application authors who
are looking for something more robust against crashes? Give
examples for how to setup a FILE* that is always as close to
flushed as possible (setvbuf to no buffer).
I want to mitigate any potential problems this will cause our users.