Comment 8 for bug 1732518

As for the forwarding issue, there is a check now in place to prevent such things from happening in the future, that's the argument check in the receiver.

For the case where as user is running the pre-security upload version of apport in a container and this post-security upload version on the host, then the container will indeed receive one more argument than it needs but I don't think there's much we can do about this.

In this case, the host would send "<pid> <signal> <ulimit> <dump mode>" to the container.
The container would then set its sys.argv to match, effectively putting the dump mode as the global pid.

This is obviously not going to work well and will result in apport crashing in the container.
As far as I can tell this isn't exploitable and will get resolved as soon as the container is upgraded. The check I put in place will prevent this from happening again and once we get named arguments, the problem will go away for good while retaining backward compatibility.