Snap try + snap try + hooks == fun

We’ve spotted a bug. :scream:

If you snap try a snap that has a pre-refresh hook, and then snap try it again in the same directory (or a post-refresh hook and try it again again), things might break in interesting ways.

AIUI it’s not looking good because unless we start making a copy of the directory we’re trying. I’m opening this topic to track discovery.


are we sure that the bug presents itself if both iteration have the hooks? I suppose it manifests itself clearly if they don’t or if the iterations have different interface/plug requirements.

It does’t. If both snaps have given hook (I tested with pre-refresh only, but this should apply to any other hook of course), you can snap try repeatedly without issues. It breaks if you:

  1. snap try a snap without the hook.
  2. add hook to the snap
  3. snap try again in the same directory with the hook now present.

As I said yesterday the symptoms I observed with this scenario were slightly different than originally reported; in the original discovery the apparmor profiles were missing and hooks were DENIED, in the above test I’m getting:

error: cannot perform the following tasks:
- Run pre-refresh hook of "snap-hooks" snap if present (run hook "pre-refresh": cannot stat /var/lib/snapd/seccomp/bpf/snap.snap-hooks.hook.pre-refresh.bin: No such file or directory)

after a few minutes of waiting (hook timeout), and there are no denials.

I’ll create a spread test that reproduces this issue, as a base for potential fix/workaround.

I don’t see an easy path to a fix for this class of problems

Cannot we at the very least issue an error or disable hooks if we see snap try over same directory?

Disabling hooks seems potentially very confusing. Stopping people in general seems also problematic. We might warn in some form, needs more thinking. ATM it’s a known issue I would say.

Right. What I’m trying to say is - if we know there is no easy fix and plan to update documentation to warn about this, we should also print a warning to the terminal.

I’ve proposed a simple spread test that reproduces this: