I would prefer to not do that, as then the snap always has those accesses, when in some cases it won’t need those accesses if it’s not being used for device specific containers (for example it’s just doing some data computation from a network source).
That also doesn’t solve the issue with the generic globbing and would complicate accesses such as for serial ports, gpio, etc.
The generic globbing was what I was thinking of with ‘where it makes sense’; it wouldn’t in that case and we’d need to pull in duplicate rules. We also add glob rules where it does make sense, eg, serial ports. There are other options in this arena, such as interface attributes that turn on or off bits of the interface or having greengrass-support and greengrass-support-devices (or something), where the former has common accesses that are always needed and the latter has those various devices that are only sometimes needed.
I think we should discuss this in realtime with @pedronis, perhaps at the upcoming sprint?
We discussed this over hangouts and came to the conclusion that it is okay for a super-privileged interface such as greengrass-support to disable udev+device cgroup unconditionally for now, with the caveat that it will sometimes give extra permissions than was desired (for example with the serial port if someone does have a gadget out there that declares the serial port using USB attributes, then the snap will gain access to more serial ports than that specific one with the glob pattern).
Additionally, we will work with upstream snap developers to evaluate “stacking” cgroups as well as cgroups v2 to try and make this snap not be incompatible with the cgroup that snapd declares and could eventually transition away from this interface disabling the device cgroup.
