On 2022-05-13, Christian Brauner <brauner@xxxxxxxxxx> wrote: > 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. I am currently working on reviving this patchset. The main issue at the moment is that the semantics for how we should deal with directories is a little difficult to define (we want to ignore modes for directories because of *at(2) semantics but there's no fmode_t bits at the moment representing that the flip is a directory), but I'm working on it. This is going to be included along with the O_EMPTYPATH feature (since making this safe is IMHO a pre-requisite for O_EMPTYPATH). -- Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH <https://www.cyphar.com/>
Attachment:
signature.asc
Description: PGP signature
