On Tue, Aug 26, 2025 at 11:07:03AM +0200, Christian Brauner wrote: > On Fri, Aug 22, 2025 at 07:07:58PM +0200, Mickaël Salaün wrote: > > Hi, > > > > Script interpreters can check if a file would be allowed to be executed > > by the kernel using the new AT_EXECVE_CHECK flag. This approach works > > well on systems with write-xor-execute policies, where scripts cannot > > be modified by malicious processes. However, this protection may not be > > available on more generic distributions. > > > > The key difference between `./script.sh` and `sh script.sh` (when using > > AT_EXECVE_CHECK) is that execve(2) prevents the script from being opened > > for writing while it's being executed. To achieve parity, the kernel > > should provide a mechanism for script interpreters to deny write access > > during script interpretation. While interpreters can copy script content > > into a buffer, a race condition remains possible after AT_EXECVE_CHECK. > > > > This patch series introduces a new O_DENY_WRITE flag for use with > > open*(2) and fcntl(2). Both interfaces are necessary since script > > interpreters may receive either a file path or file descriptor. For > > backward compatibility, open(2) with O_DENY_WRITE will not fail on > > unsupported systems, while users requiring explicit support guarantees > > can use openat2(2). > > We've said no to abusing the O_* flag space for that AT_EXECVE_* stuff > before and you've been told by Linus as well that this is a nogo. Oh, please, don't mix up everything. First, this is an RFC, and as I explained, the goal is to start a discussion with something concrete. Second, doing a one-time check on a file and providing guarantees for the whole lifetime of an opened file requires different approaches, hence this O_ *proposal*. > > Nothing has changed in that regard and I'm not interested in stuffing > the VFS APIs full of special-purpose behavior to work around the fact > that this is work that needs to be done in userspace. Change the apps, > stop pushing more and more cruft into the VFS that has no business > there. It would be interesting to know how to patch user space to get the same guarantees... Do you think I would propose a kernel patch otherwise? > > That's before we get into all the issues that are introduced by this > mechanism that magically makes arbitrary files unwritable. It's not just > a DoS it's likely to cause breakage in userspace as well. I removed the > deny-write from execve because it already breaks various use-cases or > leads to spurious failures in e.g., go. We're not spreading this disease > as a first-class VFS API. Jann explained it very well, and the deny-write for execve is still there, but let's keep it civil. I already agreed that this is not a good approach, but we could get interesting proposals.
