On 12/19/16 17:07, Peter Dimov wrote:
Andrey Semashev wrote:
Yes, if the only way to do that is fork+exec then that is not usable for me, not as the default implementation of the stacktrace decoding algorithm. If such functionality is provided, it should be strictly optional and disabled by default (i.e. on Windows don't start the helper process unless the user explicitly requests that in runtime). Let the decoding algorithm itself be not-signal-safe but in-process.
Why is spawning a process to do the decoding unacceptable?
I pointed out this in my review. One reason is because of security considerations. If the library executes a foreign executable with path lookup, it is possible to put a malicious executable with the parent process permissions. The parent process can be a daemon, running with elevated permissions, so this could potentially be devastating. This is more so a problem if the user of Boost.Stacktrace is not suspecting that the library executes a process under the hood. In general, as an application developer, I always want to be in control when my application forks and what other processes it executes. If that happens, I want that to happen in very few and specific places of my code. In those places I can carefully setup environment and permissions for the process to run, as well as specify the full path to the executable, to reduce the possibility of a breach.