NOTE: Filing this as a security issue as the new snapd behavior allows anyone on the system to hold security updates of a very security sensitive daemon.
Recently we've noticed that having something like "lxc exec" running on the system will prevent refreshes of the "lxd" snap. I understand why this would be a valuable behavior for something like firefox, but this is causing some pretty serious issues for LXD leading to this being marked as a security issue (a public one though).
LXD itself understands refreshes, on refresh, our daemon is signaled and it will cancel the bulk of its connections and background tasks, then wait an additonal 5min for any long running connections like "lxc exec" to complete, then kill off the rest and restart.
This behavior both allows for security updates to be applied in a timely manner as well as for clusters to upgrade within a rasonable timeframe. LXD cluster updates must be applied to all servers prior to the cluster being functional again, so we can't have one server holding things for a prolonged period of time.
Prior to the change of behavior in snapd, everything was fine for us. A normal refresh could be delayed for up to 5min by LXD and similarly, a cluster would normally be fully refreshed within 5min.
With the new behavior, a single "lxc exec" or "lxc monitor" running on the system will prevent any refresh of LXD. We've now seen cluster being stuck for hours/days because of this.
And now for the security issue. A user who's not even part of the privileged "lxd" group, can cause a "lxc" command to run indefinitely, which then prevents the system from applying security updates to the LXD daemon. This could be used on e.g. cloud instances to immediately connect and prevent snap refreshes, then being able to attack a much older, potentially vulnerable LXD at one's convenience.
To be clear, the new behavior in general seems reasonable but there needs to be a clear way to opt-out specific snaps or specific applications within a snap. Looking at the snapd code and YAML definition, I'm not seeing a way to do so today.
Setting as "public security" given the issue was already discussed publicly on IRC.