From: Jann Horn <jannh@google.com>
To: "Mickaël Salaün" <mic@digikod.net>
Cc: Al Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>,
Kees Cook <keescook@chromium.org>,
Paul Moore <paul@paul-moore.com>,
Serge Hallyn <serge@hallyn.com>,
Andy Lutomirski <luto@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
Christian Heimes <christian@python.org>,
Dmitry Vyukov <dvyukov@google.com>,
Elliott Hughes <enh@google.com>,
Fan Wu <wufan@linux.microsoft.com>,
Florian Weimer <fweimer@redhat.com>, Jeff Xu <jeffxu@google.com>,
Jonathan Corbet <corbet@lwn.net>,
Jordan R Abrahams <ajordanr@google.com>,
Lakshmi Ramasubramanian <nramas@linux.microsoft.com>,
Luca Boccassi <bluca@debian.org>,
Matt Bobrowski <mattbobrowski@google.com>,
Miklos Szeredi <mszeredi@redhat.com>,
Mimi Zohar <zohar@linux.ibm.com>,
Nicolas Bouchinet <nicolas.bouchinet@oss.cyber.gouv.fr>,
Robert Waite <rowait@microsoft.com>,
Roberto Sassu <roberto.sassu@huawei.com>,
Scott Shell <scottsh@microsoft.com>,
Steve Dower <steve.dower@python.org>,
Steve Grubb <sgrubb@redhat.com>,
kernel-hardening@lists.openwall.com, linux-api@vger.kernel.org,
linux-fsdevel@vger.kernel.org, linux-integrity@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org,
Andy Lutomirski <luto@amacapital.net>,
Jeff Xu <jeffxu@chromium.org>
Subject: Re: [RFC PATCH v1 1/2] fs: Add O_DENY_WRITE
Date: Fri, 22 Aug 2025 21:45:32 +0200 [thread overview]
Message-ID: <CAG48ez1XjUdcFztc_pF2qcoLi7xvfpJ224Ypc=FoGi-Px-qyZw@mail.gmail.com> (raw)
In-Reply-To: <20250822170800.2116980-2-mic@digikod.net>
On Fri, Aug 22, 2025 at 7:08 PM Mickaël Salaün <mic@digikod.net> wrote:
> Add a new O_DENY_WRITE flag usable at open time and on opened file (e.g.
> passed file descriptors). This changes the state of the opened file by
> making it read-only until it is closed. The main use case is for script
> interpreters to get the guarantee that script' content cannot be altered
> while being read and interpreted. This is useful for generic distros
> that may not have a write-xor-execute policy. See commit a5874fde3c08
> ("exec: Add a new AT_EXECVE_CHECK flag to execveat(2)")
>
> Both execve(2) and the IOCTL to enable fsverity can already set this
> property on files with deny_write_access(). This new O_DENY_WRITE make
The kernel actually tried to get rid of this behavior on execve() in
commit 2a010c41285345da60cece35575b4e0af7e7bf44.; but sadly that had
to be reverted in commit 3b832035387ff508fdcf0fba66701afc78f79e3d
because it broke userspace assumptions.
> it widely available. This is similar to what other OSs may provide
> e.g., opening a file with only FILE_SHARE_READ on Windows.
We used to have the analogous mmap() flag MAP_DENYWRITE, and that was
removed for security reasons; as
https://man7.org/linux/man-pages/man2/mmap.2.html says:
| MAP_DENYWRITE
| This flag is ignored. (Long ago—Linux 2.0 and earlier—it
| signaled that attempts to write to the underlying file
| should fail with ETXTBSY. But this was a source of denial-
| of-service attacks.)"
It seems to me that the same issue applies to your patch - it would
allow unprivileged processes to essentially lock files such that other
processes can't write to them anymore. This might allow unprivileged
users to prevent root from updating config files or stuff like that if
they're updated in-place.
next prev parent reply other threads:[~2025-08-22 19:46 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-22 17:07 [RFC PATCH v1 0/2] Add O_DENY_WRITE (complement AT_EXECVE_CHECK) Mickaël Salaün
2025-08-22 17:07 ` [RFC PATCH v1 1/2] fs: Add O_DENY_WRITE Mickaël Salaün
2025-08-22 19:45 ` Jann Horn [this message]
2025-08-24 11:03 ` Mickaël Salaün
2025-08-24 18:04 ` Andy Lutomirski
2025-08-25 9:31 ` Mickaël Salaün
2025-08-25 9:39 ` Florian Weimer
2025-08-26 12:35 ` Mickaël Salaün
2025-08-25 16:43 ` Andy Lutomirski
2025-08-25 18:10 ` Jeff Xu
2025-08-25 17:57 ` Jeff Xu
2025-08-26 12:39 ` Mickaël Salaün
2025-08-26 20:29 ` Jeff Xu
2025-08-27 8:19 ` Mickaël Salaün
2025-08-28 20:17 ` Jeff Xu
2025-08-27 10:18 ` Aleksa Sarai
2025-08-27 10:29 ` Aleksa Sarai
2025-08-22 17:08 ` [RFC PATCH v1 2/2] selftests/exec: Add O_DENY_WRITE tests Mickaël Salaün
2025-08-26 9:07 ` [RFC PATCH v1 0/2] Add O_DENY_WRITE (complement AT_EXECVE_CHECK) Christian Brauner
2025-08-26 11:23 ` Mickaël Salaün
2025-08-26 12:30 ` Theodore Ts'o
2025-08-26 17:47 ` Mickaël Salaün
2025-08-26 20:50 ` Theodore Ts'o
2025-08-27 8:19 ` Mickaël Salaün
2025-08-27 17:35 ` Andy Lutomirski
2025-08-27 19:07 ` Mickaël Salaün
2025-08-27 20:35 ` Andy Lutomirski
2025-08-28 0:14 ` Aleksa Sarai
2025-08-28 0:32 ` Andy Lutomirski
2025-08-28 0:52 ` Aleksa Sarai
2025-08-28 21:01 ` Serge E. Hallyn
2025-09-01 11:05 ` Jann Horn
2025-09-01 13:18 ` Serge E. Hallyn
2025-09-01 16:01 ` Andy Lutomirski
2025-09-01 9:24 ` Roberto Sassu
2025-09-01 16:25 ` Andy Lutomirski
2025-09-01 17:01 ` Roberto Sassu
2025-09-02 8:57 ` Roberto Sassu
-- strict thread matches above, loose matches on Subject: below --
2025-08-25 21:56 [RFC PATCH v1 1/2] fs: Add O_DENY_WRITE Andy Lutomirski
2025-08-25 23:06 ` Jeff Xu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAG48ez1XjUdcFztc_pF2qcoLi7xvfpJ224Ypc=FoGi-Px-qyZw@mail.gmail.com' \
--to=jannh@google.com \
--cc=ajordanr@google.com \
--cc=arnd@arndb.de \
--cc=bluca@debian.org \
--cc=brauner@kernel.org \
--cc=christian@python.org \
--cc=corbet@lwn.net \
--cc=dvyukov@google.com \
--cc=enh@google.com \
--cc=fweimer@redhat.com \
--cc=jeffxu@chromium.org \
--cc=jeffxu@google.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=luto@kernel.org \
--cc=mattbobrowski@google.com \
--cc=mic@digikod.net \
--cc=mszeredi@redhat.com \
--cc=nicolas.bouchinet@oss.cyber.gouv.fr \
--cc=nramas@linux.microsoft.com \
--cc=paul@paul-moore.com \
--cc=roberto.sassu@huawei.com \
--cc=rowait@microsoft.com \
--cc=scottsh@microsoft.com \
--cc=serge@hallyn.com \
--cc=sgrubb@redhat.com \
--cc=steve.dower@python.org \
--cc=viro@zeniv.linux.org.uk \
--cc=wufan@linux.microsoft.com \
--cc=zohar@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).