Bypassing ptrace restrictions for errors from hanging applications

[Evan]

As part of the error reporting features in 12.10, we're adding the ability to generate reports from hanging applications. This requires that we can gdb attach and backtrace to an arbitrary PID running as the same user, which requires working around the restrictions set by the ptrace scope:

https://wiki.ubuntu.com/Security/Features#ptrace

A new plugin for compiz will be written to notify a new dbus service on the system bus that it should write a gdb backtrace for the pid (provided by the _NET_WM_PID xprop. This service will only accept connections from the compiz process. It will only accept the request if the PID was running with a valid session cookie (unless this is overkill?).

How does that sound?

[Marc Deslauriers (mdeslaur)]

I don't think you want a root-run process to run gdb on arbitrary binaries, as I'm not sure how safe running gdb with elevated privileges on arbitrary binaries is.

Also, once the process has been traced, it needs to be protected so the user can't obtain the results, so a rogue process isn't able to bypass the ptrace restrictions by getting the system to do it for him.

I'm not quite sure how to handle this for the moment.

[Steve Langasek (vorlon)]

Does the ability for a process to name its own debugger help any here? It wouldn't do for all applications, but perhaps the standard toolkits could be patched to support it. From the wiki page:

  In the case of automatic crash handlers, a crashing process can specficially
  allow an existing crash handler process to attach on a process-by-process
  basis using prctl(PR_SET_PTRACER, debugger_pid, 0, 0, 0).

[Marc Deslauriers (mdeslaur)]

Yes, that would be a better way of handling it. Apps using standard toolkits could authorize being debugged by the WM, and that would be done under the user's context instead of using a privileged process.

I assume the goal is to trace the application while it's looping for a few seconds before killing it? Will these result in something that is actually useful for the crash database? If not, just having compiz kill it should trigger apport in the normal way.

[Evan (ev)]

The application may come back. I think sending SEGV to it, while solving this problem by pushing it through the traditionally crash handler, is ultimately overkill.

I'm happy to hear arguments that we really should be killing these hanging processes though.

[Marc Deslauriers (mdeslaur)]

Isn't that what compiz does already? If you click X on a hung application a few times, the WM usually pops up a dialog and kills the app, no?

[Evan (ev)]

Yes, compiz sends -KILL to the process.

After talking with Matthew about this some more, I think you're right, Marc. We should implement this as follows for the first iteration:

- The application hangs for X seconds.
- Compiz launches apport with the pid as an argument.
- A dialog pops up explaining the application has hung: https://wiki.ubuntu.com/ErrorTracker#app-hang
- The user presses either the Force Close or Relaunch button.
- The process gets a -SEGV from apport, which then waits for the core dump through the regular core pipe mechanism. It does this while continuing to run so that it can remember that the specified pid is a hang not a regular SEGV.

This means that we cannot do something fancy like Wait Chain Traversal:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms681622(v=vs.85).aspx

But we can always re-evaluate our approach if we find we need a living, ptrace-able process at the point of generating the report file.

[Evan (ev)]

Marking as Wont Fix, since we're implementing this by sending a SIGSEGV.