cmd,tests: fix classic confinement confusing re-execution code (#3598) #3674

Merged
merged 1 commit into from Aug 7, 2017

Conversation

Projects
None yet
3 participants
Contributor

zyga commented Aug 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

cmd,tests: fix classic confinement confusing re-execution code (#3598)
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>

@zyga zyga added this to the 2.27 milestone Aug 7, 2017

mvo5 approved these changes Aug 7, 2017

@mvo5 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 Report

❗️ No coverage uploaded for pull request base (release/2.27@7692d6a). Click here to learn what that means.
The diff coverage is 100%.

Impacted file tree graph

@@               Coverage Diff               @@
##             release/2.27    #3674   +/-   ##
===============================================
  Coverage                ?   74.84%           
===============================================
  Files                   ?      380           
  Lines                   ?    32931           
  Branches                ?        0           
===============================================
  Hits                    ?    24647           
  Misses                  ?     6487           
  Partials                ?     1797
Impacted Files Coverage Δ
cmd/cmd.go 84.78% <100%> (ø)

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 7692d6a...bf0d91f. Read the comment docs.

@zyga 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