Messages in this thread | | | From | Linus Torvalds <> | Date | Mon, 15 May 2023 11:50:02 -0700 | Subject | Re: [PATCH] fs/coredump: open coredump file in O_WRONLY instead of O_RDWR |
| |
On Mon, May 15, 2023 at 10:55 AM Christian Brauner <brauner@kernel.org> wrote: > > So that open-coded 2 added in commit 9cb9f18b5d26 ("[PATCH] > Linux-0.99.10 (June 7, 1993)") survived for 23 years until it was > replaced by Jan in 378c6520e7d2 ("fs/coredump: prevent fsuid=0 dumps > into user-controlled directories").
Hmm.
I can *not* for the life of me remember anything that far back, and our mail archives don't go that far back either.
It's strange, because the "O_WRONLY" -> "2" change that changes to a magic raw number is right next to changing "(unsigned short) 0x10" to "KERNEL_DS", so we're getting *rid* of a magic raw number there.
Which makes me think it was intentional, but I don't know why it wouldn't have used O_RDWR instead of "2".
Back then we did *not* have O_EXCL in the core file creation flags, so I'm wondering if it was some half-arsed thing as in "do not allow core-files to overwrite non-readable files in-place".
They'd still have to be *writable*, though, so that still seems more than a bit odd.
I have this *dim* memory of us having had filesystems that required readability for over-writing existing file data (because we'd do a read-modify-write for the page cache, kind of like how you can't have write-only pages on many architectures). But while we didn't have O_EXCL, we *did* have O_TRUNC, so that should be a non-issue.
I don't see a problem with making it O_WRONLY. Like it was 30 years ago. But that unexplained "O_WRONLY" -> "2" annoys me. It does feel like there was some reason for it.
Linus
| |