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.
shm_open() takes the standard mode flags, and mmap() with PROT_EXEC on a
+x fd returned by shm_open() is a legitimate operation that is required
by POSIX.
This is a perfectly reasonable thing to do on a SELinux-enabled system
which requires e.g. a JIT to write generated code to the writable
mapping and execute that code from the executable mapping of the same
shared memory object.