Re: tmpfs != /dev/shm (was Re: noexec on /dev/shm)
On Wed, 15.12.10 08:44, John Reiser (jreiser(a)bitwagon.com) wrote:
> 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.
The appropriate place for this is /tmp. /dev/shm always has been an
implementation detail of shm_open(), and accessing it directly makes
only sense for admins and low-level system tools that are used to manage
shared memory areas. But it is not a generic place to dump arbitrary
stuff.
The FHS does not offer file systems for all thinkable uses. However,
most distributions have subsequently updated its semantics, and
depending on your application you might find a more suitable place to
place your files. For example, /var/run sounds like it is something you
might want to use (if your code is privileged at least), and on more
recent distros (including F15) it is actually a tmpfs. Its purpose is
that it is used for small files, sockets, fifos that are used for
communication between processes and life-cycle management. Newer
versions of the XDG basedir spec also specify $XDG_RUNTIME_DIR which
offers similar semantics for unprivileged code and whose lifetime is
strictly bound to the user being logged in. This is first properly
implemented in systemd, and hence will be available properly in F15,
too. It too is tmpfs (since it is actually located beneath /var/run).
So, in summary: there are places which might be more appropriate for
your small files, but /dev/shm is not a good place for it, and never has
been.
Lennart
--
Lennart Poettering - Red Hat, Inc.