On Tue, 14.12.10 21:11, Nicholas Miell (nmiell@xxxxxxxxx) 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. > > 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. These are good and valid points. I have now dropped noexec from the default flags for /dev/shm. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
