|Summary:||Allow control of automatic stdio buffering using env variables|
|Product:||glibc||Reporter:||Pádraig Brady <P>|
|Component:||libc||Assignee:||Ulrich Drepper <drepper.fsp>|
|Severity:||enhancement||CC:||glibc-bugs, ppluzhnikov, zack+srcbugz|
Description Pádraig Brady 2006-03-14 13:00:40 UTC
Comment 1 Ulrich Drepper 2006-04-02 17:42:06 UTC
Hell, no. Programs expect a certain buffer mode and perhaps would work unexpectedly if this changes. By setting a mode to unbuffered, for instance, you can easily DoS a system. I can think about enough other reasons why this is a terrible idea. Programs explicitly must request a buffering scheme so that it matches the way the program uses the stream.
Comment 2 Zack Weinberg 2018-05-21 17:51:40 UTC
According to https://blog.plover.com/Unix/stdio-buffering-2.html , this feature was in fact added to NetBSD (see also https://mail-index.netbsd.org/tech-userlevel/2015/07/14/msg009247.html et seq) and has not caused problems there. I think we should reconsider. Yes, a program (or an entire process tree) could be forced to suffer much greater I/O overhead using this feature, but I don't think it rises to the level of "denial of service", there are other ways for a determined Mallory to get the same effect, and there are obvious positive use cases for e.g. manually overriding the output of a long-running program to be line-buffered even if it's going to a pipe.
Comment 3 Paul Pluzhnikov 2018-05-24 00:09:16 UTC
I agree that this is a debugging facility (not unlike MALLOC_CHECK_), that can be very handy at times.