Re: [PATCH v3 resend 1/2] mm: Add an F_SEAL_FUTURE_WRITE seal to memfd

On Fri, Nov 09, 2018 at 03:14:02PM -0800, Andy Lutomirski wrote:

quoted

quoted

quoted

quoted

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.

That doesn't work, unfortunately. The ashmem API we're replacing with
memfd requires file descriptor continuity. I also looked into opening
a new FD and dup2(2)ing atop the old one, but this approach doesn't
work in the case that the old FD has already leaked to some other
context (e.g., another dup, SCM_RIGHTS). See
https://developer.android.com/ndk/reference/group/memory. We can't
break ASharedMemory_setProt.

Hmm.  If we fix the general reopen bug, a way to drop write access from
an existing struct file would do what Android needs, right?  I don’t
know if there are general VFS issues with that.

I don't think there is a way to fix this in /proc/pid/fd. At the proc
level, the /proc/pid/fd/N files are just soft symlinks that follow through to
the actual file. The open is actually done on that inode/file. I think
changing it the way being discussed here means changing the way symlinks work
in Linux.

I think the right way to fix this is at the memfd inode level. I am working
on a follow up patch on top of this patch, and will send that out in a few
days (along with the man page updates).

thanks!

 - Joel