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. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
