Dne 17.9.2010 12:19, Jan Kratochvil napsal(a):
On Thu, 16 Sep 2010 20:08:42 +0200, Karel Klic wrote:
> now I need to finish the btparser work.)
Do you use some machine-parseable GDB backtraces - as suggested by Tom?
No, I don't. The current backtrace parser works fine, and it has an
advantage of common format and possibility to parse already existing
backtraces.
I'll reply.
> Sending coredump to a server might not be acceptable for some
users
> because of security reasons, so we should consider supporting
> minidumps (google-breakpad, see
>
http://code.google.com/p/google-breakpad/wiki/GettingStartedWithBreakpad).
Minidumps do not solve the security issue at all, cleartext passwords are
regularly stored in autovariables while being processed.
IIUC minidump does not send any non-stack memory. This means you will lose
any parameters/variables passed by reference / being a reference. You will
lose also any pretty-printed parameters/variables.
#include<string>
__attribute__((noinline)) void f (std::string s)
{ asm volatile (""); }
int main () { f ("a"); }
-O2 -g (f14):
(gdb) bt
#0 f (s="a") at 1.C:3
#1 0x000000000040066f in main () at 1.C:4
But with minidump you will not see "a" there.
(gdb) p/r s
$1 = {static npos = 18446744073709551615, _M_dataplus =
{<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> =
{<No data fields>},<No data fields>},
_M_p = 0x601028 "a"}}
(gdb) info proc mappings
Start Addr End Addr Size Offset objfile
0x601000 0x622000 0x21000 0 [heap]
- 0x601028 - that "a" - is really in this segment.
As the formerly tested MS Visual Studio 2010 beta (IIRC, some version like
that) has very poor / missing debug info for optimized code I understand
Minidump may be sufficient for the data it can display.
Thanks. So we should stick with coredumps in the design as there is no
security advantage in minidumps.
There seems to be no point in producing crippled backtraces from
coredumps completely without non-stack memory and function parameters
removed from the stack memory.
The rest of the mail was based on this incorrect principle so I
cannot comment
it more.
If you trust the retrace server provider, there should be no security
problem. It's a weakness of the retrace server idea, that you must trust
the provider, but that might be acceptable in many environments.
So this seems to be a potential blocker, which must be decided before
anything else. Any idea how to resolve this?
A prepared proposal should be then submitted for a review by Roland McGrath.
Ok.
> 1.1) It's a CGI script written in Python. Python is well suited for
> the CGI scripting and HTTP protocol handling,
Such script should be persistent accross requests. Most of the packages and
backtrace info are repeating so a shared cache should be a major concern IMO.
Such feature is generally provided AFAIK by FastCGI, mod_perl, there probably
exists also some such interface for Python.
Python has WSGI and mod_python (never tried it).
I hoped to avoid anything above CGI for the sake of simplicity. It
should be easy to extend the CGI script to use some interface that keeps
it running across requests, and then improve that by adding some caching
etc. I would prefer to think about that later, because there might be
larger problems (e.g. the coredump security issue :-))
Thanks,
Jan
Thank you for the info.
Karel