Spread snap classic confinement

snap
,
1

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?

2

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.

3

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.

4

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 127.0.0.1:59377: 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?

Thanks.

5

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.

6

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

7

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…)

8

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

9

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

10

Hey,

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.

Thanks.

4 Likes
11

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

12

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
13

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