noexec on /dev/shm

[Fernando Lopez-Lezcano]

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?

[sorry to be late for this thread, I understand the original message 
should be treated as a bug of systemd not reapplying stuff from fstab 
after it was done with its own internal needs]

I would like to bring to the attention of the list another current usage 
of the tmpfs mounted on /dev/shm in Fedora packages:

Jack (the Jack Audio Connection Kit, jackaudio.org) has been using the 
file api (apologies if my wording is not absolutely correct in unix 
terms) on the tmpfs filesystem that is mounted on /dev/shm for a very 
long time (10 years?). "/tmp" is not useful to Jack because Jack's 
internal communication pipes can't be stored in any disk based journaled 
filesystem as the latencies involved in accessing them cause glitches in 
the audio streams handled by Jack.

I raise this issue because "The API for /dev/shm is shm_open()" 
statement above means to me that in the future there will be no file api 
access to a ram mounted filesystem in Fedora (I understand that this is 
my own conclusion, but I can't see any other given the wording of the 
statement above). Before someone implements that idea, please consider 
the needs of a filesystem in ram for such uses as those mentioned in 
this thread (and that is supported by the Fedora distribution by 
default). Just in case...

-- Fernando