Interfaces for Raspberry Pi imager

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:

@popey - now that udisks2 works, is block-devices still needed?

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:

  - 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.

@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)        
* 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 ( 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.

:+1: 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

Thanks very much @alexmurray and @jdstrand for all your help.

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 :smile:

Great Job @popey. I have the snap on focal! Thanks for tracking this!