I own two of the supported glucometers and one of those requires access to a hid device and the other requires access to a block device corresponding to the connected device - on my computer, it was /dev/sda . I tried using the hidraw interface to get access to the first device. I found out that I cannot pre-declare the path to the hid device (as documented in https://snapcraft.io/docs/hidraw-interface) because I cannot predict the name of the hid device that will be created for the connected glucometer on each of the users’ computers. So the snap package will not be able to access the device.
So I have currently configured the snap to be a classic snap. And as per the documented process, I am requesting approval for it.
Please let me know if there are any concerns with this request or if you need any additional information from me to process this request.
as a trusted bystander (not a reviewer so I can’t vote on this) I can’t see any way with the current interfaces we have available for you to achieve strict confinement with your app yet. Therefore I encourage the reviewers to approve this with a view to getting it converted to strict confinement after appropriate interface improvements are made to snapd.
To that end, @guruprasad, it might be useful to post details of how your app interfaces with the glucometers in a launchpad bug at https://bugs.launchpad.net/snapd with a request for interface improvements or additions to support your usecase so that you can switch to strict confinement in the distant future.
@kyrofa, can you please indicate which unsupported use case you’re referring to on the list? It will help the author to understand why, rather than a nebulous “it’s not supported” message. This is something that should be done in all cases, not just this thread.
In general, classic confinement is intended for software that by design isn’t useful without classic. This includes specific categories of software: compilers, IDEs, and more outlined in the link above. Difficulty getting one’s software working under strict confinement, or otherwise wanting to use classic as a “bridge” to strict, is in my experience not really the intended use-case for classic confinement.
Hi @guruprasad apologize for the delay, and thanks @kyrofa for your feedback, its very nice to “read” you around :).
As @kyrofa mentioned, we have a process to grant classic and the snaps that are granted such confinement should belong to one of the supported categories. In this case, I believe we still need more information to proceed.
@emitorino, @pfsmorigo, sorry for the very late response. I have been very busy with my personal life and haven’t had the time to check and get back to you on this. I hope to do this in the coming week.
And with the classic confinement mode turned off and all these interfaces configured, the snap is unable to access the hidraw device corresponding to my FreeStyle Libre glucometer.
Like I mentioned in my initial post in this discussion,
I am unable to access a /dev/hidrawX device from the snap unless it is running in the classic confinement mode.
Below are the log lines from the snappy-debug tool corresponding to this issue.
= Seccomp =
Time: Dec 2 17:37:14
Log: auid=1000 uid=0 gid=0 ses=4 subj=snap.glucometerutils.glucometer pid=794673 comm="python" exe="/snap/glucometerutils/x2/usr/bin/python3.8" sig=0 arch=c000003e 41(socket) compat=0 ip=0x7fc05bd237ab code=0x50000
Syscall: socket
Suggestions:
* add account-control (if using NETLINK_AUDIT)
* add audio-playback (if using NETLINK_KOBJECT_UEVENT)
* add bluetooth-control (if using AF_{ALG,BLUETOOTH})
* add firewall-control (if using NETLINK_{FIREWALL,IP6_FW,NETFILTER,NF_LOG,ROUTE})
* add hardware-observe (if using NETLINK_{GENERIC,KOBJECT_UEVENT})
* add netlink-audit (if using NETLINK_AUDIT)
* add netlink-connector (if using NETLINK_CONNECTOR)
* add network (if using AF_INET{,6}, AF_CONN, NETLINK_ROUTE)
* add network-bind (if using AF_INET{,6}, NETLINK_ROUTE)
* add network-control (if using AF_{APPLETALK,BRIDGE,INET,INET6,IPX,PACKET,PPPOX,SNA}, NETLINK_{DNRTMSG,FIB_LOOKUP,GENERIC,INET_DIAG,ISCSI,KOBJECT_UEVENT,RDMA,ROUTE,XFRM})
* add network-observe (if using SOCK_RAW, AF_INET{,6}), NETLINK_{GENERIC,INET_DIAG,KOBJECT_UEVENT,ROUTE})
* add raw-usb (if using NETLINK_KOBJECT_UEVENT)
* add time-control (if using NETLINK_AUDIT)
* add unity7 (if using NETLINK_KOBJECT_UEVENT)
* add x11 (if using NETLINK_KOBJECT_UEVENT)
The other glucometer that I have is accessible via the /dev/sda device and with strict confinement I get a permission denied error. The logs in snappy-debug corresponding to this error are:
Various glucometers supported by the glucometerutils tool are accessed via various device file types and names and I do not know if there is a proper way to allow accessing all of those.
So that is why I thought that the classic confinement mode is necessary for this snap application, but I might be wrong because of having misunderstood something here.
@guruprasad I understand the frustration in trying to get your snap working under strict confinement, however for a snap to be granted the ability to use classic confinement, it must meet the requirements for classic confinement and fit into one of the supported categories for classic confinement as listed at Process for reviewing classic confinement snaps - can you please take a look at that page and update this thread with these details? If however the snap does not meet these requirements / fit within one of the supported categories then currently it is not possible to be granted classic confinement.
Unfortunately it is not possible for all applications to fit within the snap confinement model, however I hope that perhaps we can still work with you to help get your snap working under strict confinement (although it is hard without access to the particular hardware device). Also I am surprised by the snappy-debug output - that seems to indicate that the interface is not connected - can you check to make sure you have manually connected the various interfaces (as most do not auto-connect by default).
@alexmurray, @0xnishit, thank you or the response. I haven’t had the time to go check the details for the things that you have asked me to check. I expect to be able to do it in the next week or so and will post an update here once I have all the requested details.
@guruprasad, since we’ve not heard back from you, we are removing this request from our review queue. When you have more time to respond, simply do so here and we can add the request back to the queue. Thanks.