many: end-to-end support for the bare base snap #3625

Merged
merged 22 commits into from Sep 4, 2017

Conversation

Projects
None yet
6 participants
Collaborator

mvo5 commented Jul 26, 2017

This branch adds the missing pieces to enable the "bare" base snap with a proper integration test.

The tests will require that the following snapcraft features get merged:
snapcore/snapcraft#1420
snapcore/snapcraft#1419

mvo5 added some commits Jul 25, 2017

Some initial comments

@@ -217,6 +217,7 @@ struct sc_mount_config {
// The struct is terminated with an entry with NULL path.
const struct sc_mount *mounts;
bool on_classic_distro;
+ bool uses_base_snap;
@zyga

zyga Jul 27, 2017

Contributor

I'd like to have code that makes this work without any flags. In essence all snaps use base snap so our approach should be more universal.

@mvo5

mvo5 Aug 31, 2017

Collaborator

The flag is currently only used to ensure /usr/lib/snapd (and later snapctl) is available for the snap. We need /usr/lib/snapd/snap-exec to actually running anything in a base so that is important. On a normal core system we do not have to make /usr/lib/snapd available, its already there.

cmd/snap-confine/mount-support.c
@@ -333,11 +334,34 @@ static void sc_bootstrap_mount_namespace(const struct sc_mount_config *config)
config->rootfs_dir, dir);
sc_must_snprintf(dst, sizeof dst, "%s%s",
scratch_dir, dir);
- sc_do_mount(src, dst, NULL, MS_BIND, NULL);
- sc_do_mount("none", dst, NULL, MS_SLAVE, NULL);
+ if (access(src, F_OK) == 0
@zyga

zyga Jul 27, 2017

Contributor

We should be extra careful with symlinks here (the base snap may contain symlinks that will "pass" the F_OK test. I'd suggest using lstat instead, which should not be much longer but will give us the predictability.

@mvo5

mvo5 Aug 31, 2017

Collaborator

I'm find with lstat(), I kept it in sync with the lines before that use access() as well.

@mvo5

mvo5 Aug 31, 2017

Collaborator

Changed now

cmd/snap-confine/mount-support.c
}
}
}
+ if (config->uses_base_snap) {
+ // snapd dir
+ const char *src = "/usr/lib/snapd";
@zyga

zyga Jul 27, 2017

Contributor

This will clash with libexecdir layout.

@mvo5

mvo5 Aug 31, 2017

Collaborator

Indeed, I changed the code now to use the libexecdir configure option. However I think this needs to be even smarter, i.e. we need to take re-exec into account as well. I added a fixme. we could of course mount dirname(sys.argv[0]) which is probably the easiest and most sensible thing to do.

cmd/snap-confine/mount-support.c
+ sc_do_mount(src, dst, NULL, MS_REC | MS_BIND, NULL);
+ sc_do_mount("none", dst, NULL, MS_REC | MS_SLAVE, NULL);
+
+ // FIXME: snapctl tool - our apparmor policy wants it in
@zyga

zyga Jul 27, 2017

Contributor

How about this: let's always use /var/lib/snapd/tools as a place where snapd keeps it tooling. Snap confine could then mount tmpfs there and create a symlink or bind mount farm from each tool (wherever it is, even from the file that is invisible in the base snap) to an empty file here.

As long as we can require /var/lib/snapd to exist in base snaps we could then run our tools reliably.

@@ -0,0 +1,4 @@
+name: test-snapd-base-bare
+version: 1.0
+type: base
@sergiusens

sergiusens Aug 1, 2017

Contributor

this new type isn't added in any snapcraft PR, only the base field, but not the base snap type

@mvo5 mvo5 referenced this pull request in snapcore/snapcraft Aug 28, 2017

Merged

add new "no-wrapper" property to apps #1420

@pedronis pedronis added the Blocked label Aug 29, 2017

mvo5 added some commits Aug 31, 2017

Collaborator

mvo5 commented Aug 31, 2017

@zyga I addressed your comments and replied. I would love to have this as an early preview for bases in 2.28. It would allow e.g. Neal to start experimenting with the fedora core snap for real.

mvo5 added some commits Aug 31, 2017

cmd/snap-confine/mount-support.c: when mounting LIBEXECDIR always mou…
…nt it to /usr/lib/snapd inside the base snap as this is what snap run expects

codecov-io commented Sep 1, 2017

Codecov Report

Merging #3625 into master will decrease coverage by 0.01%.
The diff coverage is 0%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #3625      +/-   ##
==========================================
- Coverage   75.73%   75.72%   -0.02%     
==========================================
  Files         413      413              
  Lines       35531    35549      +18     
==========================================
+ Hits        26909    26918       +9     
- Misses       6722     6728       +6     
- Partials     1900     1903       +3
Impacted Files Coverage Δ
cmd/snap/cmd_run.go 61.79% <0%> (-0.71%) ⬇️
overlord/snapstate/check_snap.go 79.18% <0%> (-1.53%) ⬇️
overlord/snapstate/snapstate.go 80.4% <0%> (-0.26%) ⬇️
cmd/snap/main.go 63.53% <0%> (ø) ⬆️
client/client.go 79.64% <0%> (ø) ⬆️
interfaces/sorting.go 100% <0%> (+1.28%) ⬆️
daemon/daemon.go 64.31% <0%> (+1.37%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4756ef1...e9da71e. Read the comment docs.

LGTM with two changes

  • drop the MS_REC flags from the extra mount call
  • let's please rename the .gitignore files to something else (e.g. .keep)
cmd/snap-confine/mount-support.c
@@ -43,14 +43,16 @@
#define MAX_BUF 1000
+#ifndef LIBEXECDIR
@zyga

zyga Sep 1, 2017

Contributor

Why set this here if it's passed from the makefile?

@mvo5

mvo5 Sep 1, 2017

Collaborator

Just paranoia, I can remove it if it bothers you.

Collaborator

mvo5 commented Sep 1, 2017

@zyga MS_REC is now removed

@mvo5 mvo5 removed the Blocked label Sep 1, 2017

zyga approved these changes Sep 1, 2017

LGTM, thank you!

A few details, and LGTM. I'd prefer to not have the dozens of .gitignore files on empty directories committed into the tree.. we should be able to easily create the content dynamically.

cmd/snap-confine/mount-support.c
@@ -43,14 +43,16 @@
#define MAX_BUF 1000
+#ifndef LIBEXECDIR
+LIBEXECDIR = "/usr/lib/snapd"
@niemeyer

niemeyer Sep 1, 2017

Contributor

Pretty sure this won't compile (I hope it won't!).

@mvo5

mvo5 Sep 1, 2017

Collaborator

Haha - you are very right, silly me!

cmd/snap-confine/mount-support.c
+ if (config->uses_base_snap) {
+ // snapd dir: we need it so that we can actually run
+ // anything because snap-exec needs to be visible the
+ // base snap
@niemeyer

niemeyer Sep 1, 2017

Contributor

Seems slightly misleading. We don't want snap-exec to ship in base snaps, right?

@mvo5

mvo5 Sep 4, 2017

Collaborator

Indeed, I reworded the comment now to make more clear what is needed.

@@ -128,6 +128,13 @@ override_dh_auto_build:
mkdir -p _build/src/$(DH_GOPKG)/cmd/snap/test-data
cp -a cmd/snap/test-data/*.gpg _build/src/$(DH_GOPKG)/cmd/snap/test-data/
dh_auto_build -- $(BUILDFLAGS) $(TAGS) $(GCCGOFLAGS)
+ # Generate static snap-exec - it somehow includes CGO so we must
+ # force a static build here. We need a static snap-exec inside
+ # the core snap because not all bases will have a libc
@niemeyer

niemeyer Sep 1, 2017

Contributor

❤️

@niemeyer

niemeyer Sep 1, 2017

Contributor

The base field is on the app snap itself, while the base type is on the underlying snap. These sound special enough to be worth having a new type for them. We want to hide them in the default listing, for example.

@@ -0,0 +1,4 @@
+name: test-snapd-base-bare
@niemeyer

niemeyer Sep 1, 2017

Contributor

Can't comment on the empty files/dirs above, so adding here:

Wouldn't it be better to create them dynamically inside the test instead of having these in the tree?

@mvo5

mvo5 Sep 4, 2017

Collaborator

Yes, thank you! I added a snapcraft.yaml that creates them now instead of manually doing it here.

mvo5 added some commits Sep 4, 2017

@mvo5 mvo5 merged commit 32eb452 into snapcore:master Sep 4, 2017

1 of 7 checks passed

artful-amd64 autopkgtest running
Details
xenial-amd64 autopkgtest running
Details
xenial-i386 autopkgtest running
Details
xenial-ppc64el autopkgtest running
Details
yakkety-amd64 autopkgtest running
Details
zesty-amd64 autopkgtest running
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment