David, Thank you for the reply and your work on memfd. It's been a fun learning experience working with this code. On Thu, 16 Apr 2015 14:01:07 +0200 David Herrmann <dh.herrmann@xxxxxxxxx> wrote: > No. This is not what sealing is about. Seals are a property of an > object, they're unrelated to the process accessing it. Sealing is not > an access-control method, but describes the state and capabilities of > a file. The comments on sealing at the top of shmem_add_seals lead me to believe that seals were in place specifically for access control purposes. > The same functionality of F_SEAL_WRITE_NONCREATOR can be achieved by > opening /proc/self/fd/<num> with O_RDONLY. Just pass that read-only FD > to your peers but retain the writable one. But note that you must > verify your peers do not have the same uid as you do, otherwise they > can just gain a writable descriptor by opening /proc/self/fd/<num> > themselves. > > Thanks > David My peers may be any uid, in the same or different pid namespace. I would really like to not have to maintain an AF_UNIX connection to receive memfd's with a write seal. It does make a lot of sense for multicasting, but I feel memfd would be more versitile if there was a concept of ownership, or directionality, so a user could shed the socket after SCM_RIGHTS message or even fork without a socket at all. I am more than willing to put in the work if someone can offer advice on how to better achieve this type of shared memory. Maybe it's already out there and I just didn't know where to look? -Michael -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>