Activity log for bug #1704860

Date Who What changed Old value New value Message
2017-07-17 20:07:21 Adam Stokes bug added bug
2017-07-17 20:07:32 Adam Stokes tags conjure
2017-07-17 20:21:01 Michael Vogt summary classic confinement reexec classic confinement reexec and using the snap command *inside* the snap
2017-07-17 20:21:49 Michael Vogt description Doing a snap install conjure-up --classic on a fresh 16.04.02 system with snapd 2.25 installed. Causes snapd to update itself to 2.26.9 and breaking classic snap installs in the process. This is the forum post related to this bug: https://forum.snapcraft.io/t/snapd-2-26-9-and-conjure-up-no-longer-work/1348 And the related PR https://github.com/snapcore/snapd/pull/3598 This was the last post from zyga during the writing of this bug: ``` So I think this is going on: zyga@fyke:~/go/src/github.com/snapcore/snapd/client$ snap --version snap 2.26.9 snapd 2.26.9 series 16 ubuntu 16.04 kernel 4.8.0-58-generic Now let's run a shell of a snap with classic confinement: zyga@fyke:~/go/src/github.com/snapcore/snapd/client$ snap run --shell conjure-up.lxd zyga@fyke:~/go/src/github.com/snapcore/snapd/client$ snap --version snap 2.25 snapd 2.26.9 series 16 ubuntu 16.04 kernel 4.8.0-58-generic What just happened? We are still in the main mount namespace so /usr/bin/snap is the distro version. We have however set SNAP_DID_REEXEC=1 and SNAP_REEXEC= so subsequent invocations of snap will just run from the distro package and never attempt to re-exec into the core snap. This means that classic confinement snaps will use the wrong snap, the wrong snap-confine and won't understand snap-seccomp. Reply Bookmark Share Flag Reply ``` Doing a snap install conjure-up --classic on a fresh 16.04.02 system with snapd 2.25 installed. Causes snapd to update itself to 2.26.9 and breaking classic snap installs that use the "snap" command inside their classic confinement in the process. This is the forum post related to this bug: https://forum.snapcraft.io/t/snapd-2-26-9-and-conjure-up-no-longer-work/1348 And the related PR https://github.com/snapcore/snapd/pull/3598 This was the last post from zyga during the writing of this bug: ``` So I think this is going on: zyga@fyke:~/go/src/github.com/snapcore/snapd/client$ snap --version snap 2.26.9 snapd 2.26.9 series 16 ubuntu 16.04 kernel 4.8.0-58-generic Now let's run a shell of a snap with classic confinement: zyga@fyke:~/go/src/github.com/snapcore/snapd/client$ snap run --shell conjure-up.lxd zyga@fyke:~/go/src/github.com/snapcore/snapd/client$ snap --version snap 2.25 snapd 2.26.9 series 16 ubuntu 16.04 kernel 4.8.0-58-generic What just happened? We are still in the main mount namespace so /usr/bin/snap is the distro version. We have however set SNAP_DID_REEXEC=1 and SNAP_REEXEC= so subsequent invocations of snap will just run from the distro package and never attempt to re-exec into the core snap. This means that classic confinement snaps will use the wrong snap, the wrong snap-confine and won't understand snap-seccomp. Reply  Bookmark Share Flag Reply ```
2017-07-17 21:20:16 Zygmunt Krynicki snapd: status New In Progress
2017-07-17 21:20:21 Zygmunt Krynicki snapd: importance Undecided Critical
2017-07-17 21:20:23 Zygmunt Krynicki snapd: assignee Zygmunt Krynicki (zyga)
2017-07-17 23:26:25 Felipe Alfaro Solana bug added subscriber Felipe Alfaro Solana
2017-07-18 08:49:44 Elevate Platform Ltd bug added subscriber Elevate Platform Ltd
2017-07-18 16:14:23 AtomicFall bug added subscriber AtomicFall
2017-07-25 07:14:17 Yoshi Kadokawa bug added subscriber Yoshi Kadokawa
2017-08-03 21:16:12 Dave Kettmann bug added subscriber Dave Kettmann
2017-08-09 18:15:43 Zygmunt Krynicki snapd: status In Progress Fix Released