Re: GNU Guile 3.0.9rc1 available for testing!

[Ludovic Courtès]

Greg Troxel <gdt@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’.