Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
cmd,tests: fix classic confinement confusing re-execution code (#3598) #3674
Conversation
zyga
added this to the 2.27 milestone
Aug 7, 2017
mvo5
merged commit c56c2ae
into
snapcore:release/2.27
Aug 7, 2017
1 of 7 checks passed
xenial-ppc64el
autopkgtest finished (failure)
Details
artful-amd64
autopkgtest running
Details
xenial-amd64
autopkgtest running
Details
xenial-i386
autopkgtest running
Details
yakkety-amd64
autopkgtest running
Details
zesty-amd64
autopkgtest running
Details
continuous-integration/travis-ci/pr
The Travis CI build passed
Details
codecov-io
commented
Aug 7, 2017
Codecov Report
@@ Coverage Diff @@
## release/2.27 #3674 +/- ##
===============================================
Coverage ? 74.84%
===============================================
Files ? 380
Lines ? 32931
Branches ? 0
===============================================
Hits ? 24647
Misses ? 6487
Partials ? 1797
Continue to review full report at Codecov.
|
zyga
deleted the
zyga:backport/more-fixes
branch
Aug 8, 2017
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
zyga commentedAug 7, 2017
cmd,tests: fix classic confinement confusing re-execution code
When snapd inside the core snap is more recent than the snapd in the
classic distribution and the classic distribution supports snapd
re-execution then certain tools, namely snap and snapd will re-execute
the version of themselves found in the core snap.
To prevent endless loops as a part of this re-execution the variable
SNAP_DID_REEXEC is to 1 and tested in the re-execution mechanism.
Snaps using classic confinement do not get a mount namespace rooted at
the core (or designated base) snap and instead share the classic mount
namespace. As such their /usr/bin/snap is the one from the distribution
package.
When those two features are combined, a snap using classic confinement
will run with SNAP_DID_REEXEC=1 and /usr/bin/snap being the one from the
distribution. If such snap now runs a snap command, it will couple
potentially older /usr/bin/snap (e.g. from 2.25) with the profiles from
potentially newer /usr/bin/snapd (e.g. from 2.26.9). That specific
combination crosses the threshold where snap-seccomp begins to be used
and thus the old snap-confine cannot run new applications.
As a fix, unset SNAP_DID_REEXEC after observing the value 1, this will
ensure that the execution environment will not contain that flag and
each subsequent attempt to run /usr/bin/snap will re-consider
re-execution correctly.
Fixes: https://bugs.launchpad.net/snapd/+bug/1704860
Forum: https://forum.snapcraft.io/t/snapd-2-26-9-and-conjure-up-no-longer-work/
Signed-off-by: Zygmunt Krynicki zygmunt.krynicki@canonical.com