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 
Allowing a snap to auto connect both block devices and network at the same time makes snap itself useless. Lets give every permission to everything yay! so we can go back to way of things we tried to run away at the first place. You get a permission you get a permission everyone gets a permission until permission itself loses its all meaning.
In no circumstances an app should be able to access both file system and the network at the same time if it has to it should only access to its own jailed one. If I have to keep check and prune the connections every time i try an app snap becomes non user friendly. Please donât go on that road i wonât to be able to try every app without fear that is why i use snap.
Hi
i am getting the below error when trying to write the Ubuntu to sd card using rpi-imager,
Pi_imager is not able to open the SDCARD and clicking continue , the SD card is getting unmounted by default
any help?
and here is the response on rpi-imager on the terminal
QObject::setParent: Cannot set parent, new parent is in a different thread
Available disk space for caching: 27 GB
mountutils: Reading /proc/mounts
mountutils: Closing /proc/mounts
Drive: â/org/freedesktop/UDisks2/drives/SR128_0xfa259ec1â
Device: â/org/freedesktop/UDisks2/block_devices/mmcblk0â belongs to same drive