On Thu, May 12, 2022 at 02:56:22PM +0200, Miklos Szeredi wrote: > On Thu, 12 May 2022 at 14:41, Simon Ser <contact@xxxxxxxxxxx> wrote: > > > > On Thursday, May 12th, 2022 at 12:37, Simon Ser <contact@xxxxxxxxxxx> wrote: > > > > > what would be a good way to share a FD to another > > > process without allowing it to write to the underlying file? > > > > (I'm reminded that memfd + seals exist for this purpose. Still, I'd be > > interested to know whether that O_RDONLY/O_RDWR behavior is intended, > > because it's pretty surprising. The motivation for using O_RDONLY over > > memfd seals is that it isn't Linux-specific.) > > Yes, this is intended. The /proc/$PID/fd/$FD file represents the > inode pointed to by $FD. So the open flags for $FD are irrelevant > when operating on the proc fd file. Fwiw, the original openat2() patchset contained upgrade masks which we decided to split it out into a separate patchset. The idea is that struct open_how would be extended with an upgrade mask field which allows the opener to specify with which permissions a file descriptor is allowed to be re-opened. This has quite a lot of use-cases, especially in container runtimes. So one could open an fd and restrict it from being re-opened with O_WRONLY. For container runtimes this is a huge security win and for userspace in general it would provide a backwards compatible way of e.g., making O_PATH fds non-upgradable. The plan is to resend the extension at some point in the not too distant future. Christian
