I would like to ask for manual review for “factory-reset-tools” snap, which provides tools for Ubuntu-preinstalled systems to create USB media for factory reset, and change GRUB boot entry to boot into reset partition or UEFI firmware setup. Some customization are available due to requests from PC OEM to change launch items (which can call different GRUB entry or a script to change the content of the reset partition).
This tool requires permissions to format a USB flash drive in order to create a reset media from the reset partition, which exists in the Ubuntu-preinstalled systems.
The request for dbus is that it uses a daemon to change the content of /boot/grub/grubenv, and we are using dbus for IPC.
This snap is intended for systems preloaded with 24.04 Classic installations.
A separate request will be filed to transfer ownership to Canonical.
based on the functionality of the snap the following requested interfaces are expected, therefore +1 from me for auto-connect of the followings to factory-reset-tools snap:
block-devices
system-files
write:
/var/lib/snapd/hostfs/boot/grub
read:
/etc/reset_partition_fsuuid
However, regarding read access to /usr/share/desktop-provision/reset.yaml , I believe it should belong to Ubuntu Desktop Provision, but since I’m not quite familiar with it, could you please briefly explain why you need this access? Thanks.
The project has just been transferred under ubuntu-desktop-provision to be managed as a monorepo. We will need a wider access for the whole /usr/share/desktop-provision/ in order to get the theming file whitelabel.yaml and the OEM logo inside it.
This package is still in development, I am not sure when we should submit for review, I was thinking to do it early to ensure the delivery is on schedule.
@medicalwei Can you please specifically detail what accesses are required for this snap? I couldn’t find a snapcraft.yaml in the ubuntu-desktop-provision repo.
whilst we wait on a final +1 from other @reviewers on the system-files interface: reset-yaml → read /usr/share/desktop-provision/reset.yaml, I recommend updating the system-files interface names to a format similar to the example in https://snapcraft.io/docs/system-files-interface
I looked at the snapcraft.yaml that you are plugging removable-media and udisks2 but they are not mentioned here. If they are expected to be manually connected by the user it is fine, but if they are expected to be auto-connected it should also be requested.
Could you please clearly list which interfaces are you requesting connection / auto-connection to so it will be easier for us to vote?
In summary, I am requesting auto-connections for the following:
hardware-observe: to run lsblk and fetch used filesystem size, in order to know the progress of creating reset media.
mount-observe: lsblk reads info that this interface allows.
dbus-system-com-canonical-oem-factory-reset-tools-client to …-service (was dbus-client and dbus-service): as an IPC between user program and dbus daemon (which is used for configuring grub and rebooting the system in superuser permission)
dbus-session-com-canonical-oem-factory-reset-tools-service: used by flutter app (just discovered I need this slot)
removable-media: to copy files into a removable media
shutdown: to reboot the system after changing one-time GRUB boot entry
udisks2: to detect/mount/unmount/format removable media
And the below are system-files connections, also needs auto-connect:
hostfs-boot-grub (write): to change the grub entry on the next boot
etc-reset-partition-fsuuid (read): a file that records the filesystem UUID of the reset partition
usr-share-desktop-provision-reset-yaml (read): contains the configurations of the factory reset reboot entries, can be empty if using default configuration.
However, I also discovered the following connection is not needed:
block-devices: seems likely not needed, will remove later
Thanks for clarifying what your snap needs, it looks much better now. Regarding dbus plug and slot, they don’t need voting and the dbus name com.canonical.oem.FactoryResetTools looks appropriate for your snap so it should fine to grant it.
Besides that, the interfaces you are requesting look reasonable to me considering the expected functionality of the snap. Thus, +1 from me for granting factory-reset-tools auto-connection to hardware-observe, mount-observe, removable-media, shutdown, udisk2 interfaces and /var/lib/snapd/hostfs/boot/grub, /etc/reset_partition_fsuuid and /usr/share/desktop-provision/reset.yaml directories via system-files interface
updating my vote as the interfaces have been updated. Given your description and the snap functionality, +1 from me for auto-connecting the following along with the system-files interfaces:
