https://bugs.exim.org/show_bug.cgi?id=2334
--- Comment #40 from Tim Stack <timothyshanest...@gmail.com> --- > 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. -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
