Messages in this thread | | | Date | Fri, 9 Nov 2018 17:49:13 -0800 | From | Joel Fernandes <> | Subject | Re: [PATCH v3 resend 1/2] mm: Add an F_SEAL_FUTURE_WRITE seal to memfd |
| |
On Fri, Nov 09, 2018 at 08:02:14PM +0000, Michael Tirado wrote: [...] > > > That aside: I wonder whether a better API would be something that > > > allows you to create a new readonly file descriptor, instead of > > > fiddling with the writability of an existing fd. > > > > Every now and then I try to write a patch to prevent using proc to reopen > > a file with greater permission than the original open. > > > > I like your idea to have a clean way to reopen a a memfd with reduced > > permissions. But I would make it a syscall instead and maybe make it only > > work for memfd at first. And the proc issue would need to be fixed, too. > > IMO the best solution would handle the issue at memfd creation time by > removing the race condition.
I agree, this is another idea I'm exploring. We could add a new .open callback to shmem_file_operations and check for seals there.
thanks,
- Joel
| |