Comment 2 for bug 1910456

The other outstanding question we have is whether the "flavor" variants as mentioned in the original description are sufficient or if there are other flavors which need to have Delegate=true generated for services declaring a plug.

Firstly, the greengrass-support interface currently has two flavors, the empty or "legacy-container" flavor, and the "no-container" flavor. The "no-container" flavor is meant as a super minimal interface which does not have the same set of privileges as the other one, really only the privileges necessary for AWS IoT Greengrass's greengrassd to start processes using runC. The question here though is whether the policy that the "no-container" flavor has is actually enough to allow moving into new control groups. I don't think it is, but here is the link to that policy: https://github.com/snapcore/snapd/blob/cc12dae3934eab08fbca39a9b661d8b1da0ba40d/interfaces/builtin/greengrass_support.go#L56-L65. I'm specifically not sure if the "rix" rule for runc executable allows runC to create containers with different control groups, because if it is, then the "no-container" flavor also needs to have the Delegate=true directive added to the generated systemd service unit.

Secondly, the kubernetes-support interface has 4 flavors, which are as follows:

1. the empty flavor, which is used AIUI for a kubernetes daemon which needs all of the flavor policies, i.e. kubelet, kubeproxy, and autobind-unix.

2. the kubelet flavor, which is used only for kubelet, and has this comment in the policy:

# allow managing pods' cgroups
/sys/fs/cgroup/*/kubepods/{,**} rw,

(from https://github.com/snapcore/snapd/blob/cc12dae3934eab08fbca39a9b661d8b1da0ba40d/interfaces/builtin/kubernetes_support.go#L125-L126) which means it needs Delegate=true.

3. the kubeproxy flavor, which from my understanding also manages control groups with similar policy as kubelet in it, and thus should have Delegate=true.

4. the autobind-unix flavor, which does not have any policy associated with managing control groups in it, and thus should _not_ have Delegate=true directive in the generated systemd service unit.

As such, it is my understanding that any kubernetes-support plug declaration, except one with the flavor: autobind-unix attribute, should get Delegate-true generated.

Thirdly, The lxd-support interface is entirely open and as such allows the LXD snap to escape confinement and is not tracked by systemd at all, so adding Delegate=true for the lxd-support interface is largely just educational and not necessary for securing LXD.

Fourthly, all variants of the docker-support interface (with either the privileged: true attribute or the privileged: false or no privileged attribute) are meant for dockerd to manage containers and thus all should get Delegate=true.

I think this is all of the interfaces that we have in snapd for managing contianers, but if someone could double-check this that would be good.