Re: [PATCH] abort: Only flush file-based stdio streams before termination

[Carlos O'Donell <carlos at redhat dot com>]

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 <fweimer@redhat.com> 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.

-- 
Cheers,
Carlos.