snapcraft should check file creation permissions and warn/error out instead of generating a non-functional snap

[Olivier Tilloy]

This probably qualifies as a corner case, but I came across this and I thought snapcraft could do a better job of preventing uninstallable snaps. I was handed over a snap (created with snapcraft) for testing, and it wouldn't install:

$ sudo snap install --dangerous foobar.snap
error: cannot install snap file: snap is unusable due to bad permissions; contact developer

$ journalctl -u snapd
Apr 03 14:09:28 snapd[162506]: container.go:204: in snap "foobar": "meta" should be world-readable and executable, and isn't: drwxr-x---
Apr 03 14:09:28 snapd[162506]: container.go:204: in snap "foobar": "meta/gui" should be world-readable and executable, and isn't: drwxr-x---
Apr 03 14:09:28 snapd[162506]: container.go:228: in snap "foobar": "meta/gui/foobar.desktop" should be world-readable, and isn't: -rw-r-----
Apr 03 14:09:28 snapd[162506]: container.go:228: in snap "foobar": "meta/snap.yaml" should be world-readable, and isn't: -rw-r-----

My guess is that the default file creation mask on the machine where the snap was built was 640 (and 750 for directories). The snap was successfully built, but it cannot be installed.
My suggestion is to have snapcraft either issue an explicit warning, or better yet error out when this happens, to prevent building a snap that cannot be installed.

[Sergio Schvezov (sergiusens)]

We don't do much helping with environment sanity when using --destructive-mode, if that has been the case, the this is mostly a won't fix (except for figuring out why snap --check-skeleton did not run, which would have left you with a similar error message).

If this was not done with --destructive-mode, then we need to figure out what went wrong here.

[Launchpad Janitor (janitor)]

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

[Adams Jensen (adamsjensen)]

yes i have some issue in the --destructive-mode