Comment 1 for bug 1726372

So I'm only going to cover the container piece and only for 16.04 and later as for everything else we should just do as good a job as we can to turn this off, but unfortunately due to what the kernel would provide in older kernels, I'm not sure that we can always determine that.

So the issue we have here is when a process has 3 PIDs:
 - ns0 pid (host machine)
 - ns1 pid (container where apport runs)
 - ns2 pid (some nested PIDNS which does not have a matching MNTNS + apport instance)

In such case, the kernel tells the host apport process about the ns0 and ns2 pids. Apport rightfully detects that the process is coming from a container, locates the apport socket and sends what it knows of the process across.

Apport in the container will then dump the wrong process as it wasn't provided the pid for the right level of pidns.

This also highlight another general issue with the way apport handles this today. We assume that ns0 pid != ns2 pid means we got a crash from a container. But it would actually be possible to create a clash there too, this may be very tricky to hit, but you could in theory have a process in a pid namespace have the same ns0 and ns2 pid as pids are only unique within their pidns.