$ snapcraft push nvme-z_0.1.0_amd64.snap
Issues while processing snap:
- human review required due to 'allow-installation' constraint (bool) declaration-snap-v2_plugs_installation (nvme-z, block-devices)
I would like to request auto-connect for plugs,
name: nvme-z
description: NVMe device information and monitoring tool
Could you be a bit more specific about why each of the requested interfaces is needed by your application? It feels that hardware-observe should be enough for a NVMe device information and monitoring tool. Could you please also share the denials you find when running the application only with hardware-observe connected?
Use of most of the requested interfaces might still be reasonable for nvme-z if their need is properly justified, but I think use of block-devices is not in this case. If we find that there is any required permission that is currently only granted by block-devices we should probably consider to add these permissions to something like hardware-observe instead.
Moreover, block-devices is a super privileged interface that effectively grants device ownership. As such, it is reserved for a very limited set of snaps. Requirements to opt for it includes:
the application itself is a mature, well-known application
the snap’s (vetted) publisher is a mature, well-known entity
I searched for nvme-z references and/or code repositories but could not found anything. Could you point us to the right sources?
And you do not get this when running nvme smart-log /dev/nvme0n1 outside of the snap ?
I surely do since a normal user is not allowed to access that device directly unless they are in the disk group (which normal users are not) or you do use sudo with the command …
Note that snap interfaces do not touch or override any existing system permissions for users, the general ones still apply inside a snap as they would do outside of it …
As I said before, hardware-observe looks reasonable to me for a NVMe device information and monitoring tool. Thus, I #voteFor (+1) granting nvme-z auto-connection to hardware-observe interface
The tools you list all carry out readonly operations on devices to give you info, nvme also allows write operations and setting values, so without patching the tool to allow limiting it to do only read operations it will not be suitable for any -observe interface which by definition of the interface naming only allows reading of things on the system … (by default -observe in a slot/plug name means reading only while -control usually points to an interface that can manipulate things)
not without patching the nvme utility itself as i said above … the interface declaration does not limit what a tool can do so the tool would have to care for that itself (i.e. if there was an additional nvme-ro binary that has all write operations patched out it could be added) if you would add the nvme binary as is you would have to have a very excessive interface definition to make sure it can only read (and would end up with errors for users expecting it to fully work causing extra developer discussions for everyone using it, such cases would better be covered by dedicated nvme-observe and nvme-control interfaces someone would have to create)
PS: I’m not in the reviewers team, you will have to wait for a second reviewer to get to this post in their queue and approve it…