From the PR:
‘In 15.04 and Touch we would have per version profiles for applications and that was deemed too confusing. Specifically, “for series 16 there should be only ever be one profile on disk and it should be for the current application”. Adding different directories to fix this bug goes against that design constraint and we won’t know which profile is loaded at the time the application started.’
As mentioned elsewhere, this is not a bug in snapd 25, it is a bug exposed in 25 and the bug is the combination that snap-confine is now re-exec’d with the wrong policy and that snapd dropped the systemd bits long ago to make snaps start after snapd. Adding versioned directories (and only bpf cache or only snap-confine not die()ing) only papers over the real problem that the wrong policy is on disk and being used.
What we really need is to honor the implications of the initial design requirement and work towards whatever is on disk is correct for this snapd/snap-confine version. Otherwise we have latent bugs where the system is not deterministic and old policy is being used when it shouldn’t. Today, the issue is that the syntax is different, but this could just as easily affect syntactically parseable policy that is wrong for either apparmor or seccomp (eg, the network-manager interface needs a certain combination of rules that make it fail to run when reverting but the policy isn’t regenerated yet). The syntax directories approach doesn’t address that at all.
If we can address the non-determinism of security policy generation, we don’t need syntax-directories. I suggest backing out the mknod rules for now and then work on determinism next, then add the mknod rules back. Example timeline (all steps and things to do still TBD):
- 25 dot release has mknod rules reverted, that is pushed everywhere 25 is now. 25 is promoted to stable such that 24 -> 25 -> 24 has no issues
- 26 release introduces determinism (eg, add back the ‘after snapd’ systemd bits at a minimum). This allows 25 -> 26 -> 25 to have no issues. 26 might also introduce changes to snap-confine to make it not die() and/or use bpf cache but the determinism is the key requirement
- 27 (or later) release adds back the mknod rules so 26 -> 27 -> 26 has no issues
The above doesn’t handle the lesser used 25 -> 27 -> 25 scenario but as mentioned, this is nothing new. If people are worried about this scenario, we could be conservative and not reintroduce mknod until snapd 28 or later (ie, 2 or more releases of snapd after policy determinism is introduced).
