Raspberry Pi Imager is a desktop application designed to make it easy for users to create SD cards for Pi-like devices. I have made a snap, which requires udisks2 and block-devices in order to operate. Without them it can neither enumerate devices, nor unmount and write to them.
Given that the purpose of this application is to make image writing easy and accessible to an audience who may not be familiar with Ubuntu and Linux, I am on granting access to udisks2 and block-devices. Raspberry Pi Image also include guard rails to ensure that only removable storage devices are presented as writable targets.
As an aside I wonder if the name imager is a bit generic and whether a name like rpi-imager or similar would be more appropriate?
Anyway, +1 for udisks2 auto-connect, and +1 for use of block-devices but -1 for auto-connect of block-devices - whilst I appreciate this is required for the snap to function, this is a privileged interface and is too powerful to grant auto-connect of IMO - plus the snap could try and detect whether this was available and raise a dialog to the user to prompt manual connection of this interface in the case that it is not connected.
I’m fine changing the name. Raising a dialog to punch the user and ask them to open a terminal to run a command to enable a feature is getting ugly fast. It goes against the point of this app, to make it easy to write SD cards. Makes me sad and cringe every time I have to implement it, frankly.
Agreed. If we’re not going to get snapd supporting an easy “yes, let this app do this thing” similar to iOS and Android permission dialogs at point of requirement then we need to be much more liberal in giving permissions to apps until such time as granting permissions is easy. This is not good UX for new or novice users!
I have moved the snap to be rpi-imager built from the same git repo as before, as suggested. (they seemed to change the name of the app about an hour after I made mine, and at least once prior to that - naming things is hard).
Ok, without udisks2 and block-devices, when selecting an SD card, I get this in a loop and the application fails to find an SD card.
If I connect block-devices the application operates the same, up until selecting an SD card. Now it’s found, but fails to write. So I added the udisks2 interface. At the point of writing, it asks for the “sudo” password. Not sure how it does that.
Edit: I’ve just looked at their source. They are doing all interaction with the devices through the udisks dbus api, so it is actually udisks that requests the password to authorise access to the raw device (outside confinement) when told by imager to do things to the device.
Weirdly, this worked yesterday, but I can’t get it working today. Perhaps I connected something yesterday during my debugging which I haven’t connected today. Now it fails after the policykit prompt to access /dev/mmcblk0, which I suspect is when it’s trying to unmount the card. As this appears in the security log.
= Seccomp =
Time: Mar 6 14:13:28
Log: auid=1000 uid=1000 gid=1000 ses=3 pid=719483 comm="DownloadExtract" exe="/snap/imager/x1/bin/rpi-imager" sig=0 arch=c000003e 166(umount2) compat=0 ip=0x7f65aad768c7 code=0x50000
* add one of 'cifs-mount, network-control' to 'plugs'
Slightly less baffled now. i think it’s all down to not being able to unmount the SD card. It works sometimes, because sometimes the SD card happens to not be mounted, which works fine. The moment the SD card is already mounted, that’s what causes the above failure. So we need to perhaps tweak one of the existing interfaces to allow unmounting.
To be clear. I see no way to make this snap work without an interface which allows unmounting.
There’s a further issue here. A user on Solus alerted me to a problem with another snap (sosumi) where I use snapctl is-connected (interface) to prompt the user to connect a disconnected interface before continuing.
error: error running snapctl: Unknown command `is-connected'. Please specify one command of: get, restart, services, set, start or stop
Which is likely because they’re on 2.39.3 as Solus is outdated.
So do we also need to add an assumes: 2.43 to the snapcraft.yaml as an extra guard, to prevent people installing the snap when on <2.43? If so, this will be needed on all snaps which use snapctl is-connected?