Snapd is now doing a little sanity check on install

snapd
#1

As of snapd 2.3, trying to install a snap that will obviously not work as expected will now fail, with a message asking the user contact the snap developer.

The check involves looking at the permissions of key files and directories inside the snap: the root of the snap, everything under meta/, and any apps in the snap are checked.

We’re doing this because developers have found that in some situations a snap will fail to work without giving any hints as to why, and it was usually a missing read or execute bit on files or folders in the snap (stripped by accident at some point in CI).

the error message can be one of

snap is unusable due to missing files; contact developer

or

snap is unusable due to bad permissions; contact developer

as appropriate; the system log will have details about what exactly was broken, e.g.

in snap "some-broken-snap": "meta/hooks/what" should be executable, and isn't: -rw-rw-r--

HTH.

2 Likes
The snapd roadmap
#2

I’ve looped over all stable, strictly confined, application snaps on amd64. This sanity check failed for:

  1. packageproxy (meta/gui/icon.png is 0600; developer contacted: “thanks, will fix that”)
  2. visualsfm-mardy (meta/gui/.VisualSFM.desktop.swp is 0600; developer contacted: no response yet)

I also looped over all stable, classic application snaps on amd64; all of them passed this sanity check.

1 Like
#3

As of this morning, on master, snap pack will also do this sanity check:

~/.../lib/snaps/test-snapd-validate-container-failures$ snap pack
2018/01/23 13:16:42.468506 container.go:222: in snap "test-snapd-validate-container-failures": "bin/bar" should be executable, and isn't: -rw-rw-r--
2018/01/23 13:16:42.469247 container.go:222: in snap "test-snapd-validate-container-failures": "meta/hooks/what" should be executable, and isn't: -rw-rw-r--
2018/01/23 13:16:42.469310 container.go:242: in snap "test-snapd-validate-container-failures": path "bin/stahp" does not exist
error: cannot pack ".": snap is unusable due to missing files
#4

Hi. I contacted the VisualSFM developer, who kindly replied that he did not know what was wrong but might still be active enough to do something about it if someone could tell what needs to be changed. Can someone clarify what steps need to be taken?

#5

Sure! I haven’t checked if it’s still the case, but at the time of writing the problem was that there was a leftover .swp file in meta/gui, as if the snap had been built while an editor was on a file in that directory. I suspect the correct fix is to remove that file.

#6

Thanks for that, I’ll pass it on if you got nothing else. I got an error while trying to install the snap: “snap is unusable due to bad permissions; contact developer”.

#7

When you get that message, you can also see more detailed information in journalctl -u snapd (these are meant for the developer though, so they might be rather verbose).

#8

Ok, I got three lines:

  1. api.go:986: Installing snap “visualsfm-mardy” revision unset
  2. container.go:228: in snap “visualsfm-mardy”: “meta/gui/.VisualSFM.desktop.swp” should be world-readable, and isn’t: -rw-------
  3. handlers.go:306: Reported install problem for “visualsfm-mardy” as 43d9d2f8-2580-11e8-bb09-fa163e54c21f OOPSID

(and I have no idea what could be done about them)

#9

The author of the snap needs to delete the .VisualSFM.desktop.swp file from their source code, probably at snap/gui/.VisualSFM.desktop.swp, and rebuild the package. Until they do that the snap will not be installable.

#10

I think this should be paired with a sanity check in snapcraft that the user running the snapcraft command has umask 0022. My umask is 0077 and therefore I just snapcrafted a package successfully, that was then rejected by snap install:

"meta" should be world-readable and executable, and isn't: drwx------
"meta/snap.yaml" should be world-readable, and isn't: -rw-------

It was not immediately obvious to me what I did wrong. Better to prevent such things at snapcraft-ing time.

Core22 doesn't work with Qt5