tmpfs != /dev/shm (was Re: noexec on /dev/shm)

[John Reiser]

On 12/15/2010 06:40 AM, Matthew Miller wrote:
> On Tue, Dec 14, 2010 at 10:19:38PM -0800, John Reiser wrote:
>> Also, the claim "The API for /dev/shm is shm_open()" is incorrect.
>> See the other message for the history.  When something is in the file
>> system, then by default the file system APIs (including creat, open,
>> read, write, close, execve, dlopen, ...) are legitimate uses.
>> (Originally [System V] shared memory was *not* in the file system,
>> and this caused problems.)
> 
> I think you're confusing two things here. POSIX  shared  memory objects are
> implemented on Linux using a tmpfs filesystem mounted at /dev/shm.

A file system usually supports creat, open, read, write, getdents, execve,
mmap(,,PROT_EXEC,,,), etc., and should expect those calls to be used by
any process that has access permissions.  It's quite hard and cumbersome
to manipulate and administer shared memory objects using only shm*() routines
and without file system facilities such as directories, file names, ownership,
access permissions, etc., as illustrated by the history of System V shared
memory objects.

> I don't think there's a particularly good reason to use that filesystem for
> other uses. Just mount another tmpfs elsewhere.

mount() requires CAP_SYS_ADMIN and therefore an application cannot rely
on performing mounts.  A major point of this thread is that an application
wants to rely on using a file system that is present on all boxes, can be
accessed without special permissions or capabilities, and offers very
fast performance for small numbers of small-to-medium-sized files.
/dev/shm was the best choice until systemd in Fedora 15 rawhide mounted
/dev/shm with MS_NOEXEC.  Even the preview edition of Ubuntu 11.04
omits the MS_NOEXEC.

--