Yes this is the right thing to do here
assumes is a list of strings. Also the snapd assumption is
assumes: - snapd2.43
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.
@daniel 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
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 -
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.
+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
Great Job @popey. I have the snap on focal! Thanks for tracking this!