Re: [PATCH] mm/shmem.c: Add new seal to memfd: F_SEAL_WRITE_NONCREATOR

[Michael Tirado <mtirado418@gmail.com>]

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@gmail.com> 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@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>