Re: [boost] [stacktrace] Partial review

Subject: Re: [boost] [stacktrace] Partial review
From: Antony Polukhin (antoshkka_at_[hidden])
Date: 2017-03-26 17:32:15

2017-03-25 16:29 GMT+03:00 Florian Weimer via Boost <boost_at_[hidden]>:
> * Niall Douglas via Boost:
>
>>       - What is your evaluation of the implementation?
>
> I had a cursory look at the implementation.
>
> addr2line_pipe uses fork and fdopen, which are not async-signal-safe
> with glibc.  But then, std::string is used as well, which is not
> async-signal-safe, either, so maybe that's okay.

Methods that use fork and fdopen are marked as async-signal-unsafe.

> addr2line_pipe uses execvp, which could lead to evaluation of the PATH
> variable from programs which underwent an AT_SECURE transition (e.g.,
> SUID programs), which could lead to privilege escalation issues.

I'm providing an absolute path to the executable, so there must be no
PATH evaluation. Am I missing something?

> With inlining, a single stack frame can expand to a list of source
> locations (reflecting the inlineed call stack).  The current design
> does not take that into account.

I've found no system API to get multiple locations. So the Stacktrace
API is designed to have at most 1 location.

> Success of dladdr does not mean that it has obtained useful
> information.  You really need to call addr2line in that case as well.
> Furthermore, before calling addr2line, you have to translate the
> address to an object-relative address (again with the help of dladdr).
> The current code assumes that addresses in the main object (without
> dli_sname) are not subject to ASLR, which is not true for
> position-independent executables.
>
> The libunwind unwinder does not use _Unwind_GetIPInfo, and it does not
> seem to deal with the function call/signal handler frame difference.

Hm. Looks I have to experiment a little bit more. Thanks for pointing that out.

> The documentation should perhaps say something about dlclose.  If an
> application formats the stack trace for human consumption, but this
> happens after stack unwinding, some DSOs may have been closed with
> dlclose, and it could be impossible to obtain symbol information at
> that point.

Ok. Good point.

-- 
Best regards,
Antony Polukhin