cannot change profile for the next exec call: No such file or directory

[hackel]

I am unable to run any snaps. I installed hello and when I run `snap run hello` I get:

"cannot change profile for the next exec call: No such file or directory"

The same message appears with any snap that I run.

I'm using Ubuntu 17.04, so I don't believe it's the same issue as #1662899, but could be related.

[Zygmunt Krynicki (zyga)]

This was fixed in master and has been merged into the snapd 2.25 release.

If you switch to the beta channel you can confirm that it is fixed for you.

Try this command: snap refresh core --beta

Having said that, can you tell me more about your environment. This
issue should never occur if you are using the Ubuntu kernel with
apparmor enabled. Are you using a different kernel or have you
explicitly disabled apparmor on boot?

On Fri, Apr 28, 2017 at 7:39 PM, hackel <email address hidden> wrote:
> Public bug reported:
>
> I am unable to run any snaps. I installed hello and when I run `snap
> run hello` I get:
>
> "cannot change profile for the next exec call: No such file or
> directory"
>
> The same message appears with any snap that I run.
>
> I'm using Ubuntu 17.04, so I don't believe it's the same issue as
> #1662899, but could be related.
>
> ** Affects: snappy
> Importance: Undecided
> Status: New
>
> ** Description changed:
>
> I am unable to run any snaps. I installed hello and when I run `snap
> run hello` I get:
>
> "cannot change profile for the next exec call: No such file or
> directory"
>
> - The same message appears with any spap that I run.
> + The same message appears with any snap that I run.
>
> I'm using Ubuntu 17.04, so I don't believe it's the same issue as
> #1662899, but could be related.
>
> --
> You received this bug notification because you are a member of Snappy
> Developers, which is subscribed to Snappy.
> Matching subscriptions: xxx-bugs-on-snapd
> https://bugs.launchpad.net/bugs/1687079
>
> Title:
> cannot change profile for the next exec call: No such file or
> directory
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/snappy/+bug/1687079/+subscriptions

[Luis (luis+ph3l1v)]

Confirmed fixed on snapd 2.25.

I was getting a slightly different error message when running the hello-world snap:

"cannot change profile for the next exec call: Invalid argument"

After running snap refresh core --beta the issue is now fixed.

Environment:

Ubuntu 16.04.2
Armbian 5.27.170507
Linux 4.11.0-sun8i
Orange Pi Zero

[Mikhail Novosyolov (mikhailnov)]

I am using Kubuntu 16.04 and I am getting the same error with

$ snap --version
snap 2.26.3
snapd 2.26.3
series 16
ubuntu 16.04
kernel 4.11.1-xanmod3 (http://xanmod.org)

$ env BAMF_DESKTOP_FILE_HINT=/var/lib/snapd/desktop/applications/krita_krita.desktop /snap/bin/krita

[John Lenton (chipaca)]

Mikhail, could you reboot into a supported Ubuntu kernel, and try again?

[ryeterrell (ryeterrell)]

I am still seeing this on 2.25 under lxd. Also noteworthy is that it appears to be intermittent - roughly half the time, the service comes up with no problem.

Here's the journalctl logs from the etcd snap: http://paste.ubuntu.com/24625861/

$ snap version
snap 2.25
snapd 2.25
series 16
ubuntu 16.04
kernel 4.4.0-78-generic

Confirmation that the snap is not using classic confinement from /var/lib/snapd/seccomp/profiles/snap.etcd.etcd: http://paste.ubuntu.com/24634459/

[ryeterrell (ryeterrell)]

This looks like it may be a race condition occurring around container startup. If I force the systemd service to restart indefinitely, it will come up eventually (where eventually is actually pretty quick).

[Laurent Bonnaud (laurent-bonnaud)]

On my system the problem was caused by files in /var/lib/snapd/apparmor/profiles/ not being generated.

Part of the snaps installed on my system had a corresponding file in /var/lib/snapd/apparmor/profiles/ and those snaps did work.

Other snaps did not have a file in /var/lib/snapd/apparmor/profiles/ and did not work.

To fix this I:
1. ran "snap refresh core --beta"
2. rebooted my system on an Ubuntu kernel (it usually runs a mainline kernel)

Now all snaps have a corresponding file in /var/lib/snapd/apparmor/profiles/ and all snaps do run.

For now I do not know which one of 1. or 2. fixed the problem.

[Zygmunt Krynicki (zyga)]

The mainline kernel doesn't have the required apparmor patches so you end up in a situation where snapd doesn't generate a profile (because that profile would not load into the kernel anyway) but snap-confine expects them to exist. We don't support running on Ubuntu userspace without the Ubuntu kernel yet.

[Oliver Grawert (ogra)]

a more descriptive error message (or even a test if the kernel is capable when snapd attempts the first generation) would be helpful though ...

[Zygmunt Krynicki (zyga)]

I'm marking this as incomplete. Please provide the details of the system you are running on (via "snap version"). Please note that running the vanilla Ubuntu package (the snapd deb) on a system without the Ubuntu kernel is not supported today. If you are on a derivative distribution that reuses Ubuntu packages but uses a different kernel then please provide this information so that we can support that appropriately.

[Jamie Strandboge (jdstrand)]

"The mainline kernel doesn't have the required apparmor patches so you end up in a situation where snapd doesn't generate a profile (because that profile would not load into the kernel anyway)"

Note, this isn't true. The parser is smart enough to 'dumb-down' the policy for the kernel if the kernel doesn't support everything. Of course, you end up with incomplete confinement.

One idea of what could do instead is here: https://forum.snapcraft.io/t/snapd-vs-upstream-kernel-vs-apparmor/1704/8. Ie, do runtime detection, if the kernel has full apparmor support generate normal policy, else generate wide-open policy and log that we are using forced devmode (perhaps listing why it was triggered and what is missing). This will allow a system to boot with different kernels and have the snaps still work, downgrading/upgrading confinement as needed.

Alternately: do runtime detection, always generate profiles like normal, but log that the kernel doesn't support full mediation (perhaps list what is missing).

While the second method is attractive in a lot of ways since you at least get some confinement, but we will *definitely* (ie, this isn't theoretical) have snaps that need additional rules for partial confinement that we wouldn't want in full strict confinement (this could be handled by conditionals in the interfaces though (eg, in AppArmorConnectedPlug() for the interface, if PartialConfinement { add rule }).

I suggest the first for now-- we can always do the second if needed.

[Launchpad Janitor (janitor)]

[Expired for Snappy because there has been no activity for 60 days.]

[Alan Pope 🍺🐧🐱 🦄 (popey)]

I am getting this with snapcraft, but don't know if it's snapd or snapcraft at fault. Filed bug 1760514