[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <acdc68a3067c437fbde184eab29924c0@AcuMS.aculab.com>
Date: Sun, 4 Feb 2024 19:39:22 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Pedro Falcato' <pedro.falcato@...il.com>, Jeff Xu <jeffxu@...omium.org>
CC: Theo de Raadt <deraadt@...nbsd.org>, Jeff Xu <jeffxu@...gle.com>, "Linus
Torvalds" <torvalds@...ux-foundation.org>, "Liam R. Howlett"
<Liam.Howlett@...cle.com>, Jonathan Corbet <corbet@....net>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"keescook@...omium.org" <keescook@...omium.org>, "jannh@...gle.com"
<jannh@...gle.com>, "sroettger@...gle.com" <sroettger@...gle.com>,
"willy@...radead.org" <willy@...radead.org>, "gregkh@...uxfoundation.org"
<gregkh@...uxfoundation.org>, "usama.anjum@...labora.com"
<usama.anjum@...labora.com>, "rdunlap@...radead.org" <rdunlap@...radead.org>,
"jorgelo@...omium.org" <jorgelo@...omium.org>, "groeck@...omium.org"
<groeck@...omium.org>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>, "linux-kselftest@...r.kernel.org"
<linux-kselftest@...r.kernel.org>, "linux-mm@...ck.org" <linux-mm@...ck.org>,
"dave.hansen@...el.com" <dave.hansen@...el.com>,
"linux-hardening@...r.kernel.org" <linux-hardening@...r.kernel.org>
Subject: RE: [PATCH v8 0/4] Introduce mseal
...
> IMO, UNIX API design has historically mostly been "play stupid games,
> win stupid prizes", which is e.g: why things like close(STDOUT_FILENO)
> work. If you close stdout (and don't dup/reopen something to stdout)
> and printf(), things will break, and you get to keep both pieces.
That is pretty much why libraries must never use printf().
(Try telling that to people at work!)
In the days when processes could only have 20 files open
it was a much bigger problem.
You couldn't afford to not use 0, 1 and 2.
A certain daemon ended up using fd 1 as a pipe to another daemon.
Someone accidentally used printf() instead of fprintf() for a trace.
When the 10k stdio buffer filled the text got written to the pipe.
The expected fixed size message had a 32bit 'trailer' size.
Although no defined messages supported trailers the second daemon
synchronously discarded the trailer - with the expected side effect.
Wasn't my bug, and someone else found it, but I'd read the broken
code a few times without seeing the fubar.
Trouble is it all worked for quite a long time...
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists