Bug 4656 - FILE* operations are not robust enough with signals
Summary: FILE* operations are not robust enough with signals
Status: NEW
Alias: None
Product: glibc
Classification: Unclassified
Component: stdio (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-06-18 10:05 IST by Pierre Habouzit
Modified: 2014-07-04 16:21 IST (History)
2 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:
fweimer: security-


Attachments
proposed fix (371 bytes, patch)
2007-06-18 10:07 IST, Pierre Habouzit
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Pierre Habouzit 2007-06-18 10:05:10 IST
when reprograming signals (using e.g. sigaction) and disabling SA_RESTART, so 
that write isn't restarted on EINTR, fputs/fwrite/... may end up losing their 
local buffer.

attached is a patch fixing the problem.
Comment 1 Pierre Habouzit 2007-06-18 10:07:19 IST
Created attachment 1894 [details]
proposed fix
Comment 2 Nix 2007-09-22 19:40:43 IST
This patch turns out to be a seriously bad idea, because no other libcs 
preserve the stdio buffer state on error. At least bash, zsh, and rpc.mountd in 
all released versions of nfs-utils are known to fail with this patch applied, 
with rpc.mountd failing in such a way that NFS service appears to entirely fail 
because no fhs can be validated. (Also several of glibc's own tests fail.)

Ideally you'd think it would be better: it's avoiding data loss. But a lot of 
programs are *expecting* data loss in this situation, and avoiding it makes 
them misbehave...
Comment 3 Pierre Habouzit 2007-09-22 19:57:15 IST
Subject: Re:  FILE* operations are not robust enough with signals

On Sat, Sep 22, 2007 at 11:40:58PM +0000, nix at esperi dot org dot uk wrote:
> 
> ------- Additional Comments From nix at esperi dot org dot uk  2007-09-22 19:40 -------
> This patch turns out to be a seriously bad idea, because no other libcs 
> preserve the stdio buffer state on error. At least bash, zsh, and rpc.mountd in 
> all released versions of nfs-utils are known to fail with this patch applied, 
> with rpc.mountd failing in such a way that NFS service appears to entirely fail 
> because no fhs can be validated. (Also several of glibc's own tests fail.)
> 
> Ideally you'd think it would be better: it's avoiding data loss. But a lot of 
> programs are *expecting* data loss in this situation, and avoiding it makes 
> them misbehave...

  Have you any evidence of that ? Because it definitely does not makes
sense to me. Debian has the patch, and we didn't saw any of those
problem show up yet.