Classic confinement request: ubports-pdk

UBports PDK is a project to ease development on the core Ubuntu Touch platform.

It’s intended use is to ease the upgrade of UBports Ubuntu Touch to 20.04,
as well as making it easier for people to contribute overall, with an integrated
development toolchain and Debian packaging tools readily available.

The PDK requires QEMU (with Virgl) as a separate Snap, pulls images from UBports CI and allows running them,
with (in the future) automatically forwarded mounts of the project directories from the host into the guest.

The reasons for classic confinement:

  • Using a QEMU that is available stand-alone in the Snap Store
  • The PDK allows building images yourself, using Debos, Docker & KVM
  • We plan to introduce automatic mounting of host directories (via 9p or SSHFS)

Link is here: https://github.com/ubports/ubports-pdk
Our QEMU is available here: https://github.com/fredldotme/qemu-ut-pdk

Hey @beidl,

It sounds a PDK should fit under our supported categories to gran classic confinement, but based on the reasons you have provided, I would like to ask some further questions, since:

If I followed your related doc properly, you could bundle qemu-virgil the same way other snaps like sosumi are already doing while keeping under strict confinement.

You could plug the mount-observe interface, although you need to see if the accesses provided by the interface are enough for your needs.

You can plug docker as well as the kvm.

So, does ubports-pdk require access to files on the system (such as the usual case of IDEs requiring access to headers/compilers) or any other requirement which are not provided by some of the supported interfaces?

Thanks for looking into it!

Regarding your questions:

  • It all boils down to using SSH as provided by the host OS. We don’t have an SSHFS service like Multipass has because that one is tightly integrated into its project and not reusable outside of the context of Multipass.
    There’s also concerns around stability of libssh-based SSHFS compared to the OpenSSH implementation, as I’ve experienced some occasional crashes of that.
    Hence we’re using OpenSSH in the host right now.
  • Would plugging docker mean us having to ship our own docker cli command?

I’d be happy to ship it using strict confinement of course. There’s no rush, any feedback is welcome.

We’re in the progress of making adjustments to allow confined policy in the Snap package.
Instead of SSHFS we’re trying to opt for virtiofsd-based mounting of directories.
With all interfaces plugged it should allow the full PDK to run in a confined environment.

There’s one issue though: it seems when trying to run sudo snap connect ubports-pdk:docker it complains about there not being a corresponding docker interface slot in snapd on Ubuntu 20.04.

Could you please help us how to proceed here?
(Also, I guess this thread could be renamed and moved to a more fitting place, now that we’re trying to fit it into a confined space)

the docker interface is provided by the docker snap, you need to install that first if you want to make use of the interface …

Hmm, that’s a tough one then. Most people in our community already use Docker, but the package manager provided one. Forcing them to migrate might cause more issues than we’re willing to deal with.

EDIT: Although, if someone wants the snap version of the PDK installed they would have to go all in and migrate everything to the Snap world. I’ll have to talk to some people what we’re willing to accept here.

Thank you for the idea, but we’ve decided to remove the “create” functionality to create images, and instead opt for an “import” command in the future to import images that have been created using our existing Debos script and recipes.

The PDK is now, after patching virtiofsd to run unprivileged and misc fixes, strictly confined!

Thank you for your input @ogra & @emitorino, if we have another request (for auto connects) we will let you know!

1 Like