On Fri, Nov 09, 2018 at 03:14:02PM -0800, Andy Lutomirski 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. > >>> > >>> 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
