https://bugs.exim.org/show_bug.cgi?id=2334
--- Comment #40 from Tim Stack <timothyshanestack@???> ---
> 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 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).
> 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.
> 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.
> Finally: you can build PCRE without JIT support. This would be less
> than ideal, but would solve your problem too.
lnav is used for scanning large log files. Turning off JIT is not feasible due
to the performance impact.
> 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.
--
You are receiving this mail because:
You are on the CC list for the bug.
