noexec on /dev/shm

[John Reiser]

On 12/14/2010 09:37 PM, Lennart Poettering wrote:
> On Sun, 12.12.10 19:49, John Reiser (jreiser at bitwagon.com) wrote:
> 
>> The project is a database system that creates and dlopen()s
>> plugins on-the-fly, for better performance on ["long-running"] queries.
>> We like the speed of creat+write+close+open+read+mmap on /dev/shm.
>> If /dev/shm and /tmp both become off limits, then what is
>> the recommended replacement location?
> 
> The API for /dev/shm is shm_open(). Unless you are using that API you
> shouldn't really touch /dev/shm.
> 
> What's wrong with /tmp for your use cases?

As I wrote another place under this topic (at
http://lists.fedoraproject.org/pipermail/devel/2010-December/147159.html
which crossed in the posting mail), some applications prefer to avoid /tmp
for such purposes because /tmp often is too slow: a real harddrive (needs
capacity larger than RAM) with a heavy-weight file system (to provide
full-featured ACLs, etc.) which often suffers contention.

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.)

--