Support ptracing of a live hanging application

[Evan]

At present we send SIGSEGV to hanging applications in order to get a core dump that we can then turn into a stack trace (see bug 1006398). However, we may want to support ptracing of a live application in the future. Microsoft has done interesting work around diagnosing application hangs caused by deadlocks. This seemingly requires a living process.

One potential approach is to isolate gdb so that we can safely ptrace without having to send a SIGSEGV:

[15:47:20] <@ev> hm, given https://bugs.launchpad.net/ubuntu/+source/whoopsie-daisy/+bug/1006398 it doesn't seem possible to show the full stack trace for a hang before the user presses the force closed or relaunch button (because it's at that point the progress gets a SEGV from apport)
[15:47:46] <@ev> but I guess that's okay, as what the user is concerned about here is which application is hanging, not where
[15:48:18] <@ev> plus fixing this would require ptracing the process, which we the security team believes to be a no-go in the above mentioned bug
[16:40:48] <ted> ev, It seems sane, I'm curious if we couldn't give a "special gdb" privs with apport to do the ptrace thing if we needed it.
[16:41:04] <ted> ev, Basically we could have one that started as root, but dropped everything that could make it scary.
[16:41:12] <@ev> ted: I tried that angle. See the bug report :)
[16:41:17] <ted> ev, Or, more correctly, had apport drop everything for it ;-)
[16:41:20] <@ev> you know how these security people are
[16:42:01] <ted> Naw, you didn't try hard enough :-)
[16:42:22] <ted> You could got with a "custom gdb" that knew about privs and dropped them.
[16:42:38] <ted> With an apport restriction that it can only write to a single directory.
[16:42:49] <ted> Sorry, apparmor restriction.
[16:43:18] <ted> So that way it can't do anything with a an arbitrary binary. Unless apparmor sucks, which it doesn't :-)
[16:43:54] <ted> But, I think the plan there works, we don't need ptrace for that experience yet.
[16:44:00] <@ev> hmm, will make a bug for that for version two. Sending segv is just quicker for now, and there's lots of other work to be done
[16:44:00] <ted> So fight that battle another day :-)
[16:44:04] <@ev> exactly