> Op 27-03-2026 07:26 CET schreef Aleksa Sarai <[email protected]>: > > > On 2026-03-26, Jori Koolstra <[email protected]> wrote: > > To get an operable version of an O_PATH file descriptor, it is possible > > to use openat(fd, ".", O_DIRECTORY) for directories, but other files > > currently require going through open("/proc/<pid>/fd/<nr>"), which > > depends on a functioning procfs. > > > > This patch adds the OPENAT2_EMPTY_PATH flag to openat2(2). If passed, > > LOOKUP_EMPTY is set at path resolve time. > > > > Note: This implies that you cannot rely anymore on disabling procfs from > > being mounted (e.g. inside a container without procfs mounted and with > > CAP_SYS_ADMIN dropped) to prevent O_PATH fds from being re-opened > > read-write. > > Actually, this flag doesn't need to be openat2(2) only -- all existing > kernels will reject a pathname of "" with ENOENT. This means that > O_EMPTYPATH being set acting as a no-op is fine for older kernels (no > program will get an unexpected result from O_EMPTYPATH). > > In my view, adding it to openat(2) is preferable because it means that > systemd et al. can use it (they currently block openat2(2) with > seccomp). This is what I did in the original openat2(2) patchset[1].
I changed this in response to feedback from Christian [1]. He did mention that if someone really wants to add it to openat(), we should wait for their reasons :) But if systemd could use it, I think it is worth considering. I am not sure why Christian was against it in the first place. Maybe to save flag space for things that really really need to be also in openat(). [1]: https://lore.kernel.org/linux-fsdevel/20260224-karotten-wegnimmt-79410ef99aeb@brauner/. Thanks, Jori.
