Greg Troxel <g...@lexort.com> skribis: > My second approach is using the rc tarball in pkgsrc. I had to patch > out the verify call. pkgsrc already works around PaX issues mostly, via > paxctl on things that do jit, after build and before use, and by > > --- libguile/loader.c.orig 2018-01-08 16:21:04.790894906 +0000 > +++ libguile/loader.c > @@ -484,7 +484,7 @@ map_file_contents (int fd, size_t len, i > char *data; > > #ifdef HAVE_SYS_MMAN_H > - data = mmap (NULL, len, PROT_READ, MAP_PRIVATE, fd, 0); > + data = mmap (NULL, len, PROT_READ | PROT_WRITE, MAP_PRIVATE, fd, 0); > if (data == MAP_FAILED) > SCM_SYSERROR; > *is_read_only = 1; > > because (something like, am fuzzy) mprotect (at least ours) can only > reduce not add permissions. I still don't understand why this isn't a > more widespread issue.
My understanding is that the expectation of being able to later mprotect that mapping to make it writable is a valid one per POSIX. Quoth <https://pubs.opengroup.org/onlinepubs/9699919799/functions/mprotect.html>: If PROT_WRITE is specified, the application shall ensure that it has opened the mapped objects in the specified address range with write permission, unless MAP_PRIVATE was specified in the original mapping, regardless of whether the file descriptors used to map the objects have since been closed. Here the original file descriptors are O_RDONLY, but the mapping is MAP_PRIVATE. I’m not sure how to best address that. Thoughts? Ludo’.
