We're running into problems with the LXD snap where our seccomp confinement is @unrestricted but this still gets expanded to an empty BPF seccomp policy.
The issue we run into is that liblxc will not setup stacked policies, effectively making it impossible to generate per-container policies for containers. This was made evident lately as we noticed that ArchLinux containers fail to work in LXD under snapd as we can't apply our custom seccomp policy.
This also currently prevents the use of CRIU as part of the LXD snap as CRIU cannot dump and restore a seccomp BPF program when it's itself running under one (even if that program allows everything).
I think the right course of action here is that if the seccomp profile ends up being @unrestricted, this should be implemented by not doing any seccomp setup, rather than setting up a dummy, empty policy.
stgraber: the change to what @unrestricted means was done a while ago, along with the introduction to snap-seccomp
stgraber: before the seccomp profile was parsed each time
stgraber: now the profile is parsed and compiled only when the policy is prepared
stgraber: because the compiled policy is a BPF program we didn't have a way to say "don't load anything" without introducing some form of header or other special semantics in interpreting the file content
stgraber: mvo implemented a permissive policy as a workaround
stgraber: if this breaks LXD we can definitely change this
stgraber: e.g. by encoding a little header or by interpreting truncated file as unconfined
stgraber: (or perhaps a file containing just the string @unconfined, not to be confused with a truncated file due to another bug)