Spread snap classic confinement

Hey guys,

I tried to launch spread tests for certain project using the spread snap but there is a problem with qemu backend. Seems that virtualized environments are not accesible due to confinement. I’ve tested confining snap as classic and that works perfectly. I wonder if we should release it as classic. In that case, paths to search for images maybe shouldn’t be hardcoded to $HOME/.spread but checking if we are in a snap and search for it at $SNAP_USER_DATA/.spread instead. I don’t know if makes sense also having the option of an env var to search for the images. Thoughts?

Hey Roberto,

Sorry for taking a while to get to this message. It went unperceived earlier.

Yes, having spread as classic is a good idea, at least until we can more easily run qemu from within a strict snap. I’ll work on that.

Hey Gustavo,

I’ve just read your reply.
Sorry I didn’t propose my tested code before. I don’t want you to redo things I’ve done before. I got the first version of the snap now present in the store, and I changed confinement to classic. That along with hardcoded paths to find the image for Qemu is what is included in this PR https://github.com/snapcore/spread/pull/30
Maybe that’s not covering all the backend virtualized cases, but it is a start.

I saw it was added to the repo a strict confined version of the snap. However, when testing using a kvm/qemu backend I saw it is not possible as there is no access to it. Initially it was complaining about the need of having kvm available for the snap. I added kvm-qemu as stage package and then I saw this output when launching spread tests in a project:

Cannot connect to qemu:ubuntu-core-16: dial tcp getsockopt: connection refused

Using snappy-debug, this was the complain reported:

sudo snappy-debug.security scanlog spread

kernel.printk_ratelimit = 0
= AppArmor =
Time: Sep 22 17:54:27
Log: apparmor="DENIED" operation="open" profile="snap.spread.spread" name="/dev/kvm" pid=4859 comm="qemu-system-x86" requested_mask="wr" denied_mask="wr" fsuid=1000 ouid=0
File: /dev/kvm (write)

I cannot find any snapd builtin interface providing acces to /dev/kvm Is there any one planned for future to support this?


We have builtin interface(kvm) to support this. Adding a kvm plug in the spread snapcraft.yaml file could remedy this situation.
But it didn’t land it in 2.27.6 yet. I am not sure when it’s going to happen.
Probably, @mvo knows something about it.

Oh, I was outdated from upstream. Yes I see it now. Thanks @gary-wzl, I’ll give it a go

When trying using current trunk content I get this error:

snap install spread_2017.09.21_amd64.snap --dangerous
error: cannot perform the following tasks:
- Setup snap "spread" (unset) security profiles (cannot setup seccomp for snap "spread": error: cannot parse line: cannot parse token "u:root" (line "chown - u:root g:root"))
- Setup snap "spread" (unset) security profiles (error: cannot parse line: cannot parse token "u:root" (line "chown - u:root g:root"))

and snapd reports lines like:

 helpers.go:152: cannot regenerate seccomp profile for snap "core": error: cannot parse line: cannot parse token "u:root" (line "chown - u:root g:root")

That error is shown not only related to core but for some other installed snaps also (snapweb, udisks2, etc…)

I’m not sure how you are building this from trunk, but you need also build the snap-seccomp binary (it lives in /usr/lib/snapd).

Exactly. Overriding /usr/lib/snapd/snap-seccomp with the one built from sources did the trick. Thanks for your help.


I finally completed qemu-kvm backend support in current strict confined spread snap. @mvo, @zyga-snapd or @niemeyer, please take a look at it here when you find some time.
There is one limitation: The project to test must be in a path accessible by spread snap in order to work. I’ve tested simply by copying that project to its $SNAP_USER_DATA, but maybe content interface can also be used (I’ve not tested). Or maybe you can think on another better and more confortable solution.



I think the home interface is a natural candidate but spread is already using it.

Note that there are users/customers that validate their core images using spread (even here in the forum), we might end up needing two spread packages or a qemu interface that spread could use…

Edit: oops, missed the above post about that interface…

1 Like

ah, true. Anything into home is accessible. Tested ok.