Comment 1 for bug 1910456

We on the snapd team have a plan for fixing this, by essentially making it such that any snap that plugs these interfaces, will have Delegate=true put into the generated systemd unit.

Specifically, we would like to always include Delegate=true if the snap merely declares a plug for one of these interfaces, regardless of whether the plug is connected to a slot or not. This makes the code implementation much simpler for us, because it means we don't need to modify the systemd service unit for the snap service every time the plug is connected or disconnected, which would be a lot of work codewise for us.

This has the important implication though that if a snap declares the plug for something like docker-support, but does not have docker-support connected to the slot, then it will not have the highly privileged policy that enables something like docker to create containers and confine those containers, _but_ it will still have the setting of Delegate=true which means that systemd will not clean up the control groups for child processes if the child processes were to somehow get into a different control group.

We do not think this is an issue because:
* in order to have Delegate=true in the policy, you still need to declare the plug, and today all snaps that use these interfaces are not allowed to be uploaded to the store unless they are approved/allowed to by store reviewers (this is because the interfaces are super-privileged)
* even if the snap has Delegate=true in it's systemd unit, that alone does not provide the necessary privilege in order to create containers or otherwise create new control groups and place processes into those control groups

However, we would like input on this from the security team about whether this makes sense and is not introducing a vulnerability in this way.