snapcraft should check file creation permissions and warn/error out instead of generating a non-functional snap
Metadata
Current evaluation
Snapcraft now validates the snap skeleton and fails before producing an unusable artifact; merged in canonical/snapcraft#3743 (7c927032d).
Resolution: closed resolved
Reason: PR #3743 added `snap pack --check-skeleton` and converted validation failures into Snapcraft errors. Commit 7c927032d was merged as 74d92c7b0, directly addressing unreadable metadata files.
Evaluated by: mr-cal-bot
No scores available.
Issue body
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.
Evaluation history
| Date | Model | Scores | Action | Summary |
|---|---|---|---|---|
| stealth/space-bunny-alpha | — | closed resolved | Snapcraft now validates the snap skeleton and fails before producing an unusable artifact; merged in canonical/snapcraft#3743 (7c927032d). | |
| stealth/space-bunny-alpha | — | closed stale | Closed as expired after 60 days without activity; no permission-validation fix was implemented, and later skeleton-check PRs did not resolve the destructive-mode case. | |
| stealth/space-bunny-alpha | — | closed stale | Permission validation was not implemented; the issue expired after 60 days of inactivity. A later skeleton-check PR merged, but did not resolve this report. | |
| stealth/space-bunny-alpha | — | closed stale | Abandoned without implementation; no PR or commit added the proposed permission validation (Launchpad #1871109). | |
| qwen/qwen3.6-35b-a3b | — | — | Closed without implementation. The request to add file permission validation to snapcraft to prevent generating non-functional snaps from restrictive umask settings was abandoned. No code changes were made. | |
| qwen/qwen3.6-35b-a3b | — | — | Closed without resolution. The requested permission checks were not implemented, and the issue remains abandoned. | |
| qwen/qwen3.6-35b-a3b | — | — | Closed without a fix or implementation. The issue appears abandoned or deferred due to zero comments and prolonged inactivity, leaving the requested permission validation unaddressed. | |
| qwen3.6-35b-a3b-mtp-q6 | — | — | Closed without resolution due to inactivity. Restrictive build-time umasks produce invalid snaps, prompting a recommendation for snapcraft to validate permissions and fail early. No fix was implemented. |
Update history
| Date | Change |
|---|---|
| created |
Related work
-
Likely Fixed By:
canonical/snapcraft#3743
(confidence 98%)
The merged PR added the skeleton validation requested by the issue.
Related issues
| Issue | Project | State | Summary | Similarity |
|---|---|---|---|---|
| #1950465 snapcraft does not seem to call `snap pack --check-skeleton` to validate that snap has correct things | snapcraft (launchpad) | closed | Snapcraft now runs snap pack --check-skeleton during packing, catching invalid plug and slot names before installation. Implemented by merged PR #3743 (commit 7c927032d). | |
| #1604326 snapcraft init doesn't fail if there is a .snapcraft.yaml file | snapcraft (launchpad) | closed | Fixed by merged snapcraft#669 (commit 2cd727259): snapcraft init now detects an existing .snapcraft.yaml and fails instead of creating snapcraft.yaml. | |
| #1627843 snapcraft should check permissions before starting an upload | snapcraft (launchpad) | closed | Authentication refreshing was fixed in Snapcraft 2.18 via LP #1621171; a maintainer later confirmed the upload-permission problem was already resolved. | |
| #1790004 Snapcraft should warn if it produces a snap that the store will reject | snapcraft (launchpad) | open | Requests local warnings for Snap Store rejection conditions. The reported permission failure is concrete, but mode validation is absent from current linters and broader local store-check work remains open. | |
| #21 snapcraft throws FileExistsError: with very simple Python snap | snapcraft | closed | Replaced the FileExistsError with local-source validation in 0e575ce53; corrected local-source handling merged via PR #377 (8b4a18d9b). |