A while back I tried to work on putting fwupd into a classic snap (Approval for fwupd classic snap). There was push back that this should be a regular snap.
The PolicyKit rules associated with any client communication with the daemon aren’t loaded. So I can’t communicate with the daemon with anything other than root.
The ESRT needs to be accessible from the snap (/sys/firmware/efi/esrt)
The client and daemon communication interface/plug isn’t automatically enabled. I had heard this might happen from the store, but I don’t know how to activate it.
A new set of confinement rules to all the interfaces fwupd uses is needed.
From my perspective, 1, 2, and 3 are the most important as they would at least be a functional ‘devmode’ snap. As it stands today devmode doesn’t work for UEFI updates due to lack of access to those directories in the snap.
The PolicyKit rules need to be copied out of the snap at install, similar to what we’ve proposed doing for gnome-shell search providers at GNOME Shell search providers in snaps
This needs a new security backend (eg, ‘polkit’) that would sit alongside apparmor, seccomp, kmod, udev, etc in interfaces/. Like @kenvandine mentioned, we would encode PolicyKit rules in the snapd interface code (in this case, for fwupd) and snapd would be responsible for writing those out to disk (eg, like it does for udev rules).
cmd/snap-confine needs to be updated to bind mount these into the snap
The fwupd interface AppArmor policy (interfaces/builtin/fwupd.go) needs to be updated to have this access.
These can be updated, likely in interfaces/builtin/fwupd.go, but maybe some accesses should be in other interfaces. This organization would happen during PR review.
I suggest the following approach:
submit a PR for the polkit backend
submit a PR to make the efi partition available to the snap
submit a PR for the needed security policy updates (eg, esrt, etc)