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?
Yes this is the right thing to do here
assumes is a list of strings. Also the snapd assumption is snapd2.43, not 2.43:
assumes:
- snapd2.43
3 Likes
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?
I am not using sudo when launching the application.
@lucyllewy suggested they’re using udisks2 to elevate, in an earlier comment.
There is no client/server split.
When block-devices is not connected I get:
= AppArmor =
Time: Mar 25 16:46:32
Log: apparmor="DENIED" operation="open" profile="snap.rpi-imager.rpi-imager" name="/sys/block/" pid=149531 comm="lsblk" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
File: /sys/block/ (read)
Suggestions:
* adjust program to not access '/sys/block/'
* add 'block-devices' to 'plugs'
It fails to find the SD card slot so I can’t proceed at that point.
The application outputs:
Error executing lsblk
Error executing lsblk
Error executing lsblk
Error executing lsblk
Error executing lsblk
Error executing lsblk
Error executing lsblk
.
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?
Note that lsblk is supposed to be supported by hardware-observe and allows /sys/{block,bus,class,devices,firmware}/{,**} r,.
Can you try with just plugging udisk2 and hardware-observe, skipping block-devices?
Yes! This works. So do I need to request different interfaces?
$ snap connections rpi-imager
Interface Plug Slot Notes
block-devices rpi-imager:block-devices - -
cifs-mount rpi-imager:cifs-mount - -
desktop rpi-imager:desktop :desktop -
desktop-legacy rpi-imager:desktop-legacy :desktop-legacy -
hardware-observe rpi-imager:hardware-observe :hardware-observe manual
home rpi-imager:home :home -
mount-observe rpi-imager:mount-observe - -
network rpi-imager:network :network -
network-control rpi-imager:network-control - -
network-manager rpi-imager:network-manager - -
opengl rpi-imager:opengl :opengl -
removable-media rpi-imager:removable-media - -
udisks2 rpi-imager:udisks2 :udisks2 manual
x11 rpi-imager:x11 :x11 -
1 Like
Your original request was for udisks2 and block-devices. Let’s now vote on udisks2 and hardware-observe instead.
+1 for auto-connection of udisks2 and hardware-observe.
@reviewers - can others please (re)vote?
Good news indeed.
from me
+1 from me too for auto-connection of udisks2 and hardware-observe for rpi-imager.
3 votes for, 0 votes against auto-connect of udisks2 and hardware-observe for rpi-imager. This is now live
No worries @popey - I just installed and used rpi-imager and it was very pleasant (much nicer than dd from the command-line) - so thanks for snapping it and persisting through the interface review process 