Messages in this thread | ![/](/images/icornerl.gif) | | Date | Tue, 16 Aug 2011 14:50:52 -0500 | Subject | Re: [PATCH] mmap: add sysctl for controlling ~VM_MAYEXEC taint | From | Will Drewry <> |
| |
On Tue, Aug 16, 2011 at 2:50 PM, Will Drewry <wad@chromium.org> wrote: > On Tue, Aug 16, 2011 at 2:40 PM, Mel Gorman <mel@csn.ul.ie> wrote: >> On Tue, Aug 16, 2011 at 10:07:46AM -0700, Roland McGrath wrote: >>> On Tue, Aug 16, 2011 at 2:33 AM, Mel Gorman <mel@csn.ul.ie> wrote: >>> > Is using shm_open()+mmap instead of open()+mmap() to open a file on >>> > /dev/shm really that difficult? >>> > >>> > int shm_open(const char *name, int oflag, mode_t mode); >>> > int open(const char *pathname, int flags, mode_t mode); >>> >>> I cannot figure out the rationale behind this question at all. >>> Both of these library functions result in the same system call. >>> >> >> They might result in the same system call but one of them creates >> the file under /dev/shm which should not have the same permissions >> problem. The library really appears to want to create a shared >> executable object, using shm_open does not appear that unreasonable >> to me. > > If /dev/shm is mounted noexec, the resulting file will have VM_MAYEXEC
Err VMA from mmaping the file from shm_open().
> stripped. I don't believe it is capable of doing anything special > that will cause the mmap code path to find a different containing > mountpoint. If it could, then that would certainly be preferable, but > it would also make this VM_MAYEXEC calculation less effective in the > default case. > > thanks! > >>> > An ordinary user is not going to know that a segfault from an >>> > application can be fixed with this sysctl. This looks like something >>> > that should be fixed in the library so that it can work on kernels >>> > that do not have the sysctl. >>> >>> I think the expectation is that the administrator or system builder >>> who decides to set the (non-default) noexec mount option will also >>> set the sysctl at the same time. >>> >> >> Which then needs to be copied in each distro wanting to do the same >> thing and is not backwards compatible where as using shm_open is. >> >> -- >> Mel Gorman >> SUSE Labs >> > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| ![\](/images/icornerr.gif) |