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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk