https://bugs.exim.org/show_bug.cgi?id=2334
--- Comment #41 from Rich Siegel <siegel@???> ---
(In reply to Tim Stack from comment #40)
> > I can inquire, but I strongly suspect that macOS security engineering
> > would consider fork()ing a process in which MAP_JIT has been used to
> > be a security risk.
>
> What are you thinking of that would make this a security risk?
I have no idea. :-) It's what *they* think that could constitute a risk that
matters.
> > I don't know your project or requirements, but as a general advisory
> > fork(2) is very much not recommended on macOS,
>
> My project (http://lnav.org) is written for posix and runs just fine on
> linux, freebsd, and macOS (including Mojave with pcre 8.42).
I believe you! But that doesn't invalidate my above statement. :-) That being
said, since you have cross-platform considerations, it doesn't really matter
what the recommended best practices are.
> > in favor of using posix_spawn(2) or NSTask (if you are targeting
> > macOS/iOS) or an XPC service (ditto). (This isn't a "you're doing
> > it wrong", this is a "I'm trying to think of ways you can get
> > around this issue.")
>
> I rely on the behavior of fork() to access data structures built up in the
> parent process. Spawning a blank new process doesn't really work without a
> non-trivial rearchitecting.
Understood. In that case, it sounds like your best bet is to write up a new
PCRE bug requesting that PCRE's use of MAP_JIT (through sljit) be controllable
at runtime, to support your use case (and others like it which may arise).
> > Alternatively, if it *is* your code, then doing the pcre[2]_compile()
> > in the child process *after* the fork might work as-is, if that's a
> > feasible change for you to make.
>
> I want to say that I tried this and it didn't work because the memory
> allocator data structures were in the section of memory that was mmap'd with
> MAP_JIT. So, most pcre operations would just crash right away.
That is indeed unfortunate.
> > In a larger sense, if use cases like these keep arising, it may be that
> > the only feasible solution in PCRE[2] is to provide an option flag to
> > pcre[2]_compile() to let the client unilaterally suppress PCRE's use of
> > MAP_JIT, because I don't think that it'll ever be possible to always make
> > the right decision at run time. (The default behavior should be what it
> > is today: let PCRE make the decision at runtime based on the OS version
> > and environment.)
>
> I would say MAP_JIT should only be turned on if explicitly requested. Like
> I said, things seem to work just fine with earlier versions of pcre. If an
> app is sandboxed and uses PCRE, I would think it would not be onerous to
> configure pcre to use MAP_JIT.
Whether MAP_JIT is usable on a given platform/OS/application has nothing to do
with app sandboxing, so that alone is unfortunately not a suitable determinant.
(I did some early experiments that examined the code signing entitlements of
the caller. It worked, but got messy fast and dragged in lots of
platform-specific code which didn't seem suitable to include in sljit.)
As you can probably tell from the previous history of this bug, the issue is
not remotely cut-and-dried.
Because the decision to use MAP_JIT must be made at runtime, it seems
appropriate for the client code developer to indicate (in their own code or at
runtime, depending on their needs) either:
* "yes it's OK for PCRE to use MAP_JIT or not based on runtime conditions"
(which I think is a reasonable default) or
* "no, I'm going to be calling fork(2) so please don't ever use MAP_JIT" (which
handles cases like yours).
I think that any solution which requires custom configuration of a PCRE library
build would be a nonstarter.
Whether the PCRE/sljit implementors think that's the best path forward is for
them to say. :-)
--
You are receiving this mail because:
You are on the CC list for the bug.
