Re: [boost] [Stacktrace] review, please stop discussing non-Stacktrace issues

Subject: Re: [boost] [Stacktrace] review, please stop discussing non-Stacktrace issues
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2016-12-19 10:58:41

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.