https://bugs.exim.org/show_bug.cgi?id=2334
--- Comment #41 from Rich Siegel <sie...@barebones.com> --- (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. -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
