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 11:01:56

On 12/19/16 18:58, Andrey Semashev wrote:
> 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

...it is possible to *run* a malicious executable...

> 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.
>