----- "John Reiser" <jreiser(a)bitwagon.com> wrote:
On 12/14/2010 07:28 PM, Lennart Poettering wrote:
> In order to make things secure we minimize what is allowd on the
various
> API file systems we mount. That includes that we set noexec and
similar
> options for the file systems involved. The interface how to access
> /dev/shm is called shm_open(), and given that this is how it is
there is
> very little reason to allow people to execute binaries from them.
Of
> course, this is a very recent change, and at this point while we
assume
> that this will not break any valid use of this directory, we cannot
be
> sure about this, so we'd be very interested to learn why exactly
you
> want the noexec to be dropped. What is your application that needs
that?
> If there is a point in dropping the noexec, we'll definitely be
willing
> to do so, but if the only reason would be "I always misused /dev/shm
as
> a scratch space", then we won't be very convinced. The API fom
/dev/shm
> is shm_open(), and if you place other stuff in there, then you are
> misusing it and actually creating all kinds of namespacing problems
> (since /dev/shm is actually an all-user shared namespace), and we
aren't
> particularly keen to support such misuses by default.
The claim "The API for /dev/shm is shm_open()" is incorrect.
Very early in the history of shm [late 1970's at the Columbus, Ohio,
USA
branch of Bell Telephone Laboratories], then shm_open, shmget, etc.,
were
the only means of access; the objects had names that were 32-bit
binary
integers. In fact, when shm became more widely used then there were
denial-of-service attacks based on the premise that enumerating
objects
in shm required 2**32 exhaustive search via shmget. As soon as
/dev/shm
was integrated into the filesystem, then creat, open, read, write,
close,
lseek, execve, etc. (any filesystem API) became additional access
paths.
This integration began appearing by about the mid 1980's, around 25
years
ago, and since then applications have been using /dev/shm via
ordinary
files system APIs in addition to shmget etc.
Why? Because *fast* operations on small numbers of
small-to-medium-sized
files can be a big advantage for performance. /tmp often is much
slower
because /tmp often is a harddrive: the need for space in /tmp often
exceeds
the size of physical RAM. Also, mounting /tmp as tmpfs can meet
resistance
because tmpfs does not support all features that applications expect.
A ramdisk might be used, except that early ramdisks allowed at most a
few megabytes (comparable to the capacity of a floppy disk), which is not
large enough to support typical simultaneous usage. Applications
also cannot rely on ramdisks because superuser privileges usually are
required to access a ramdisk. In many cases ramdisks have been
replaced
by: /dev/shm !!
You are conflating shm_open and shmget which are two completely separate things,
I'm not sure you actually know what you are talking about, AFAIK /dev/shm is a Linux
only thing,
that provides an interface for Posix SHM to glibc from the kernel, nothing more. Its even
mentioned in the man page for shm_open.
It sounds like what you really want is to configure your systems with a RAM disk somewhere
that you can exec from.
Dave.