Snapping SETUID binary

Hi people,

I’m giving a go at snapping latest QEMU in order to emulate some recent Raspis with Ubuntu server. All went fine, and I’m now able to emulate machines nicely. There are some hiccups though, that I thought I’d share with you and maybe get some help.

  1. VMs are running fine, but in order to setup advanced networking more easily, QEMU provides a binary called qemu-bridge-helper. This binary must be SETUID if regular users are to use it (QEMU Wiki). First question: is this feasible nowadays within Snap environment? The package was created using classic confinement.

  2. Was feeling kinda lucky recently, so I thought: “Well, since package is working so great, why not replacing distro QEMU with it, on libvirt?”. Well, turned out it’s easier said than done. Libvirt QEMU driver does some checking on the binaries, that breaks Snap’s qemu link to /usr/bin/snap binary scheme. Has somebody tried before? Any tips? Doable?


Ivo

you might find some ideas or inspiration in https://github.com/ogra1/qemu-virgil-snap
there is no way to keep the setuid bit though …

1 Like

Yeah, already got to it, @ogra. It was open on a FF tab all the time, thanks!

Only reason I didn’t use your package was I needed 5.1+ version, since this seems to be the only way to correctly emulate Raspi3+ using other distros apart Raspberry Pi OS.

Store overrides can be applied to allow snaps to ship setuid binaries, such as chromium for example. I would recommend starting a forum post requesting permission to do so for your snap.

I’ve seen this come up in other areas and I don’t think there is a solution to this one unfortunately

1 Like

Great, Ian! I’ll do some testing with the helper and, if it works, I might open a request - Snap isn’t published yet, since it was created to address a somewhat urgent issue at work, so I’m going the “dangerous” way.

A little off-topic:

Had this necessity at work, to run a more up-to-date QEMU; system was RHEL-based (you guessed right, CentOS) and I never really liked RPM specs (confusing, ugly, whatever). I’m somewhat familiar with Snaps, so it took 1-2 days to have the package ready and installed.

If you people only managed to include other directories than home inside strictly confined Snaps namespace, it would be so much enterprise friendly…

What specific directories do you want to be available to strictly confined snaps? We provide /mnt and /media via the removable-media interface, which is enough for many use cases

Let’s take, for instance, a dir where all documents of a certain sector is stored; that’s definitively not some user docs, so it shouldn’t be in /home - I can see users doing a cleanup of their home area and docs flying away. There’s backup, of course, but there’s wasted time (and rage, maybe :slight_smile: ). These dirs also won’t be mounted on /media, and I believe /mnt isn’t right either (it’s my understanding that it’s used to temporary mounts, and these are ever-mounted dirs). How could we use a LibreOffice Snap in this situation, for instance? As I said, bind mounting to home isn’t an option, I believe.

Well for graphical snaps, the solution is to have them use portals, which will then proxy any file the real user outside of confinement can access to the confined snap via /tmp. For other snaps however, it’s not really useful to us to consider hypotheticals, as we have been over this a few times and we need to be concrete in what directories we allow for technical reasons, so if there is a specific directory which you know is widely used by folks, then we would be happy to work on allowing that through some method, but unfortunately the implementation is just such that we can’t allow any arbitrary directory through - it has to be something we specifically know about and thus can make support commitments about.

Hmmmm… Right, you nailed it for graphical apps; I admit I was unaware of portal’s features, thought they’re only useful to solve those temporary “Open with app…” situation.

For non-graphical apps, all I can think of is some sort of setting that would list extra dirs to be mapped inside the Snaps - something like snap set system.extra-dirs ...... . I can think of many cases that would be useful to us - some scientific simulators and compilers we use here could benefit from newer versions, but we have some hundreds of autofs dirs, outside home, that would need to be mapped (or Snap should be made classic, as last resort).

That’s my point, but you’re right: there’s been much discussion about this here. I just thought that bringing real-case scenarios could somewhat show people have valid use cases for it.

Thanks!