Could you please explain what you are trying to achieve? I see you are still trying to access system files but you are using an incorrect plug declaration:
Hi @weLees, this request is waiting on your response regarding a plug declaration, could you please provide some more information so we can try and proceed?
Hi @rayveldkamp ,
Sorry for long time waiting.
We’ve tried our best to reduce the use of interfaces, but still couldn’t run the full functionality of Visual LVM.
Visual LVM may need to run in Classic mode because it needs to modify system information.
I would like to ask, if we want to release software in Classic mode, what qualifications need to be provided?
@weLees the Process for reviewing classic confinement snaps details the qualifications that need to be provided for classic confinement. However, there are still a number of unanswered questions from this thread - in particular you still have not explained why you feel the snap needs write access to all of /dev - if this was granted it would enable a snap to take ownership of the device it was installed on - as such this is a very sensitive permission, but you do not seem able to explain this request.
If you want your snap to be granted such expansive permissions you need to be able to explain this to the reviewers so that can adequately assess the request.
Please can you take a closer look at this thread and answer the various questions in as much detail as possible so we can try and help you? Otherwise I don’t see how we can help if you are not able / willing to provide the requested information. Thanks.
Hi, thanks for your reply.
About the /dev,
The Visual LVM is a LVM manager, so it need to detect/access block device such as hdd/sdd/nvme to read the LVM information, some information an be get from vg config file, and some in head of PV(disk or partition).
In addition, in order to be compatible with lvm2, the related functions of lvm2 need to be called when performing operations, which makes Visual LVM must also access some sensitive objects, such as /run/proc/… , /dev/mapper/…
did you run your snap alongside snappy-debug in a second terminal yet to get interface suggestions ? normally the block-devices interface should give you all access needed to all bock devices on the system, you should not need to access all of /dev … likewise there is a dm-crypt interface that gives you rw access to /dev/mapper/control, most nodes under /proc have also already a defined interface, the snappy-debug tool should have suggested all of them to you and give you alternatives for most/many things that will not require a manual review …
For the final error it looks like your snap is wanting to execute some binary from /sbin - instead please ensure your snap ships whatever binary it needs within itself and executes that one instead, as snaps are not allowed to execute binaries from the host machine (and the particular binary may not be available / installed anyway).
For the second error - you can use the block-devices interface to get access to /dev/sdb1 etc so please make sure your snap plugs this interface as well (and manually connect the interface after installing the snap).
Finally for access to the files under /sys/devices you should use the hardware-observe interface.
To list files in /sbin you can plug the system-backup interface, since the entire host filesystem is mounted inside /var/lib/snapd/hostfs. This way your snap could read from /var/lib/snapd/hostfs/sbin.
Can you try that and let us know if there is yet another issue?
@isaac.clack - have you made any progress in resolving these errors, using the suggested interfaces? Please let us know of any results, so that we can progress this request.
Hi @isaac.clack, since you still seem to be having difficulties snapping your application, perhaps it would be more useful to create a new forum topic under the snap category where others can offer help and suggestions. Thanks.
I see another post has been created How to enumerate and access system devices(visual lvm). I am removing this request from our review queue, but please @isaac.clackfeel free to write here again and we will be happy to add it back if needed.