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
Syscall: umount2
Suggestion:
* 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.
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.
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?
To be clear, udisks2 has polkit integration so on classic it is what will prompt for access for mounting/umounting/etc.
@popey - I agree with @alexmurray that block-devices grants device ownership to the snap since it grants raw access to devices. Is your snap intended to not run under sudo? If sudo must be used for this snap to function, then +1 to auto-connect block-devices provided services aren’t added to the snap to bypass this restriction.
If sudo isn’t required:
how is the snap elevating permissions to provide the access? Are there root-running daemons running to provide the non-root frontend access?
if there is a client/server split, what access controls is the server performing to make sure a connecting client doesn’t have instant root? (keep in mind, if it is listening on a socket, any non-root, unconfined processes would be able to use the socket)
what are security policy denials you see when block-devices isn’t connected?
Looking at the upstream source code, lsblk appears to be used to get the list of block devices on the system and udisks2 is used to open the device on behalf of the user (https://github.com/raspberrypi/rpi-imager/blob/qml/downloadthread.cpp#L184) if it can’t be opened directly - so it might be interesting to see if upstream would be interested in using udisks2 to enumerate the block devices as well as a fallback for lsblk failing - then block-devices would not be required…
@jdstrand - thoughts on adding read/write attributes on the block-devices interface so that we can grant just read-only access - this would allow cases like this to use it and not have to grant such privileged access?
- naming things is hard).
