Re: RFC: named anonymous vmas

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: RFC: named anonymous vmas

Christoph Hellwig
Btw, FreeBSD has an extension to shm_open to create unnamed but fd
passable segments.  From their man page:

    As a FreeBSD extension, the constant SHM_ANON may be used for the path
    argument to shm_open().  In this case, an anonymous, unnamed shared
    memory object is created.  Since the object has no name, it cannot be
    removed via a subsequent call to shm_unlink().  Instead, the shared
    memory object will be garbage collected when the last reference to the
    shared memory object is removed.  The shared memory object may be shared
    with other processes by sharing the file descriptor via fork(2) or
    sendmsg(2).  Attempting to open an anonymous shared memory object with
    O_RDONLY will fail with EINVAL. All other flags are ignored.

To me this sounds like the best way to expose this functionality to the
user.  Implementing it is another question as shm_open sits in libc,
we could either take it and shm_unlink to the kernel, or use O_TMPFILE
on tmpfs as the backend.
Reply | Threaded
Open this post in threaded view
|

Re: RFC: named anonymous vmas

Rich Felker
On Thu, Aug 01, 2013 at 01:29:51AM -0700, Christoph Hellwig wrote:

> Btw, FreeBSD has an extension to shm_open to create unnamed but fd
> passable segments.  From their man page:
>
>     As a FreeBSD extension, the constant SHM_ANON may be used for the path
>     argument to shm_open().  In this case, an anonymous, unnamed shared
>     memory object is created.  Since the object has no name, it cannot be
>     removed via a subsequent call to shm_unlink().  Instead, the shared
>     memory object will be garbage collected when the last reference to the
>     shared memory object is removed.  The shared memory object may be shared
>     with other processes by sharing the file descriptor via fork(2) or
>     sendmsg(2).  Attempting to open an anonymous shared memory object with
>     O_RDONLY will fail with EINVAL. All other flags are ignored.
>
> To me this sounds like the best way to expose this functionality to the
> user.  Implementing it is another question as shm_open sits in libc,
> we could either take it and shm_unlink to the kernel, or use O_TMPFILE
> on tmpfs as the backend.

I'm not sure what the purpose is. shm_open with a long random filename
and O_EXCL|O_CREAT, followed immediately by shm_unlink, is just as
good except in the case where you have a malicious user killing the
process in between these two operations.

Rich
Reply | Threaded
Open this post in threaded view
|

Re: RFC: named anonymous vmas

Christoph Hellwig
On Thu, Aug 01, 2013 at 04:36:08AM -0400, Rich Felker wrote:
> I'm not sure what the purpose is. shm_open with a long random filename
> and O_EXCL|O_CREAT, followed immediately by shm_unlink, is just as
> good except in the case where you have a malicious user killing the
> process in between these two operations.

The Android people already have an shm API doesn't leave traces in the
filesystem, and I at least conceptually agree that having an API that
doesn't introduce posisble other access is a good idea.  This is the
same reason why the O_TMPFILE API was added in this releases.

Reply | Threaded
Open this post in threaded view
|

Re: RFC: named anonymous vmas

KOSAKI Motohiro-2
In reply to this post by Rich Felker
On Thu, Aug 1, 2013 at 4:36 AM, Rich Felker <[hidden email]> wrote:

> On Thu, Aug 01, 2013 at 01:29:51AM -0700, Christoph Hellwig wrote:
>> Btw, FreeBSD has an extension to shm_open to create unnamed but fd
>> passable segments.  From their man page:
>>
>>     As a FreeBSD extension, the constant SHM_ANON may be used for the path
>>     argument to shm_open().  In this case, an anonymous, unnamed shared
>>     memory object is created.  Since the object has no name, it cannot be
>>     removed via a subsequent call to shm_unlink().  Instead, the shared
>>     memory object will be garbage collected when the last reference to the
>>     shared memory object is removed.  The shared memory object may be shared
>>     with other processes by sharing the file descriptor via fork(2) or
>>     sendmsg(2).  Attempting to open an anonymous shared memory object with
>>     O_RDONLY will fail with EINVAL. All other flags are ignored.
>>
>> To me this sounds like the best way to expose this functionality to the
>> user.  Implementing it is another question as shm_open sits in libc,
>> we could either take it and shm_unlink to the kernel, or use O_TMPFILE
>> on tmpfs as the backend.
>
> I'm not sure what the purpose is. shm_open with a long random filename
> and O_EXCL|O_CREAT, followed immediately by shm_unlink, is just as
> good except in the case where you have a malicious user killing the
> process in between these two operations.

Practically, filename length is restricted by NAME_MAX(255bytes). Several
people don't think it is enough long length. The point is, race free API.