Merge lp:~stgraber/apport/bug1445064 into lp:~apport-hackers/apport/trunk
Status: | Merged |
---|---|
Merged at revision: | 3052 |
Proposed branch: | lp:~stgraber/apport/bug1445064 |
Merge into: | lp:~apport-hackers/apport/trunk |
Diff against target: |
168 lines (+121/-4) 4 files modified
data/apport (+54/-4) lib/systemd/system/apport-forward.socket (+12/-0) lib/systemd/system/apport-forward@.service (+11/-0) test/test_apport_forward.py (+44/-0) |
To merge this branch: | bzr merge lp:~stgraber/apport/bug1445064 |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Martin Pitt (community) | Needs Information | ||
Review via email: mp+283752@code.launchpad.net |
Description of the change
This is the implementation of https:/
The original implementation of this feature was a security nightmare and had to be reverted. This new design should be safe as the host will never actually execute any code, just contact a pre-existing apport setup and forward the crash to it.
This change introduces a couple of systemd units to setup a new /run/apport.socket UNIX socket. Upon receiving a container crash, the host apport looks for that socket in the crashed process' root. If found, it attempts to connect to it, then send the command line arguments it received along with its stdin.
Systemd in the container spawns apport whenever a crash happens, apport then connects to the host through the fd it receives from systemd and receives the stdin fd as well as the argument list from the host.
It then mangles its own sys.stdin and sys.argv to match what's sent by the host, then continues execution as normal.
The code change is pretty self contained, only new external dependency is on python3-systemd.
Ok, so the code looks good to me, the only problem is that it doesn't work.
It's not entirely clear to me why it doesn't. The host does get the crash, finds the container's socket and sends the crash over to it. The container's apport kicks in, parses the argument line just fine and then fails during actual crash parsing due to the crashed process no longer existing.
I don't get why the crashed process disappears though, I thought the kernel was supposed to keep it around until the crash handler exists, however the host side of the crash handler sure is still running (in fact doesn't seem to want to die for some reason)...
So basically the two remaining issues are:
- The crashed process appears to be destroyed by the kernel before the handler exits.
- The handler seems to never exit, apparently stuck on recv() of the unix socket, despite the remote end having long exited. This may be a weirdness of systemd's socket handler, you'd think that with accept=True it'd close the socket on exit of the service, but it doesn't appear to do so.