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.
Please can I request autoconnection of udisks2 and block-devices for the imager snap. Snapcraft source at https://github.com/popey/imager-snap and upstream source at https://github.com/raspberrypi/imagewriter
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.
why is there only one heart to click on !!!
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!
@popey if imager needs access to block-devices how does it escalate privileges to write to these? Does it use policykit or is there some privileged backend which runs as root?
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.
Error executing lsblk
Error executing lsblk
Error executing lsblk
This appears to originate here
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.
I believe thatās using policykit.
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
Syscall: umount2
Suggestion:
* add one of 'cifs-mount, network-control' to 'plugs'
So doing some more debugging.
Ok, now Iām baffled. I have udisks2 and others connected, butā¦
= AppArmor =
Time: Mar 6 14:22:34
Log: apparmor="DENIED" operation="dbus_method_call" bus="system" path="/org/freedesktop/UDisks2/Manager" interface="org.freedesktop.DBus.Introspectable" member="Introspect" mask="send" name="org.freedesktop.UDisks2" pid=736410 label="snap.rpi-imager.rpi-imager" peer_pid=2805 peer_label="unconfined"
DBus access
Suggestion:
* try adding 'udisks2' to 'plugs'
= AppArmor =
Time: Mar 6 14:22:34
Log: apparmor="DENIED" operation="dbus_method_call" bus="system" path="/org/freedesktop/UDisks2/block_devices/mmcblk0" interface="org.freedesktop.DBus.Introspectable" member="Introspect" mask="send" name="org.freedesktop.UDisks2" pid=736410 label="snap.rpi-imager.rpi-imager" peer_pid=2805 peer_label="unconfined"
DBus access
Suggestion:
* try adding 'udisks2' to 'plugs'
$ snap connections rpi-imager
Interface Plug Slot Notes
block-devices rpi-imager:block-devices :block-devices manual
cifs-mount rpi-imager:cifs-mount :cifs-mount manual
desktop rpi-imager:desktop :desktop -
desktop-legacy rpi-imager:desktop-legacy :desktop-legacy -
home rpi-imager:home :home -
mount-observe rpi-imager:mount-observe - -
network rpi-imager:network :network -
network-control rpi-imager:network-control :network-control manual
network-manager rpi-imager:network-manager - -
opengl rpi-imager:opengl :opengl -
raw-usb rpi-imager:raw-usb - -
removable-media rpi-imager:removable-media - -
udisks2 rpi-imager:udisks2 :udisks2 manual
x11 rpi-imager:x11 :x11 -
Iām getting plug blindness. What am I missing? 
Hereās the script Iām using for testingā¦
#!/bin/bash
set -eu
sudo snap remove rpi-imager
#snapcraft --use-lxd
#snapcraft remote-build --launchpad-user popey --launchpad-accept-public-upload
snapcraft
sudo snap install rpi-imager_*amd64.snap --dangerous
#sudo snap connect rpi-imager:mount-observe
#sudo snap connect rpi-imager:removable-media
sudo snap connect rpi-imager:udisks2
sudo snap connect rpi-imager:block-devices
sudo snap connect rpi-imager:cifs-mount
#sudo snap connect rpi-imager:network-control
snap run rpi-imager
Using the source at https://github.com/popey/imager-snap
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.
With the udisks2 interface connected, if you add this to /var/lib/snapd/apparmor/profiles/snap.rpi-imager.rpi-imager:
dbus (send)
bus=system
path=/org/freedesktop/UDisks2/**
interface=org.freedesktop.DBus.Introspectable
peer=(label=unconfined),
and you reload the policy with sudo apparmor_policy -r /var/lib/snapd/apparmor/profiles/snap.rpi-imager.rpi-imager do the application work correctly?
I suspect that the application is falling back to umount/etc itself since udisks2 isnāt working correctly. If we can fix udisks2, my hope is that your application will not need the extra accesses.
I assume you mean sudo apparmor_parser and yes, that works!
Thank you.
Thanks for confirming. Iāve now submitted a PR for 2.44 that will hopefully make it in: https://github.com/snapcore/snapd/pull/8263
It still fails without block-devices. Failing to run lsblk
beyond using lsblk it will also need to directly write to the device node at some point in the process to actually write the image to disk (like dd and friends do)
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.
They get:
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?