Re: [PATCH] fs/coredump: open coredump file in O_WRONLY instead of O_RDWR

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, May 15, 2023 at 10:55 AM Christian Brauner <brauner@xxxxxxxxxx> 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




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux