← Back to issue list

Restrictive umask and permissions may cause a built snap to be unusable

View original Launchpad issue

Metadata

Project
snapcraft (launchpad)
Number
#1515394
Type
issue
State
closed
Author
~brunonova
Labels
—
Created
Updated
Closed

Current evaluation

Closed by maintainer in Jan 2019 as a non-issue for the general case, since consistent build environments make a restrictive host umask irrelevant; no snapcraft code changes made.

Resolution: closed not a bug

Reason: No fix was ever committed. The issue sat open from 2015 to 2019 while mvo, kyrofa, leonbo and jdstrand debated whether snapcraft should validate packaged file permissions (jdstrand closing the review-tools bug as "Won't Fix"), and was finally closed by sergiusens with the comment that "consistent build environments make this a non issue for the general case".

Evaluated by: mr-cal-bot

No scores available.

Issue body

I use the umask 007 in my system. When I built a test package with snapcraft and installed it in a Snappy Core system, most of the files and folders of the package where not accessible by the "other" users, and thus I couldn't run the binaries (no permission). I think snappy/snapcraft should make some permissions/umask checks. Maybe snapcraft or "snappy build" should check the permissions of all packaged files and directories (like how the Debian build tools do), and either correct the permissions or warn the user about files that have strange permissions. Snapcraft could also enforce an umask of 002 or 022.

Evaluation history

Date Model Scores Action Summary
stealth/space-bunny-alpha — closed not a bug Closed by maintainer in Jan 2019 as a non-issue for the general case, since consistent build environments make a restrictive host umask irrelevant; no snapcraft code changes made.
stealth/space-bunny-alpha — closed not a bug Closed without code changes after maintainers concluded consistent build environments make restrictive host umask a non-issue for general builds.
stealth/space-bunny-alpha — closed stale Closed without a linked fix; restrictive umasks could leave packaged snap files unreadable or unexecutable by other users.
qwen/qwen3.6-35b-a3b — — Closed without resolution. The report regarding restrictive umask causing unusable snaps was abandoned due to inactivity. No permission validation or umask enforcement was implemented in snapcraft.
qwen/qwen3.6-35b-a3b — — Closed without resolution. The umask permission handling request was abandoned without snapcraft implementing automatic permission checks or umask enforcement.
qwen3.6-35b-a3b-mtp-q6 — — Closed without resolution or comments. The report regarding restrictive umask causing unusable snaps was abandoned due to inactivity. No permission checks or umask enforcement were implemented.

Update history

Date Change
created

Related work

  • Related To: canonical/snapcraft#4658 (confidence 82%)

    Later snapcraft report of the same umask/permissions leak causing a runtime PermissionError; still open, showing the concern was deferred rather than fixed.

  • Related To: canonical/snapcraft#1723 (confidence 40%)

    Unrelated-but-adjacent permission preservation workaround for source extraction; partial fix territory for permission handling but not tied to this bug.

Related issues

Issue Project State Summary Similarity
#358 Set a sane umask to create a proper snap snapcraft closed PR #358 (duplicate of merged PR #360) set a default umask during snap creation so a restrictive host umask no longer yields an invalid snap. Closed unmerged; #360 landed the fix for LP #1515394.
72%
#4658 File permissions leak through to built snap snapcraft open A restrictive host umask can preserve inaccessible source modes in built snaps, reproducing an OpenStack runtime PermissionError; the report remains untriaged and unresolved.
72%