← Back to issue list

snapcraft 7 never drops permissions while doing builds invoked with sudo

View original Launchpad issue

Metadata

Project
snapcraft (launchpad)
Number
#1990551
Type
issue
State
closed
Author
~dilyn-corner
Labels
Created
Updated
Closed

Current evaluation

⚠️ This summary may be outdated — the issue content or evaluation prompts have changed since this evaluation was made.

Closed without resolution due to inactivity. The report identifies a snapcraft 7 regression where sudo builds retain root privileges instead of dropping them, unlike snapcraft 6. No fix or discussion occurred.

Suggested action:

No scores available.

Issue body

If snapcraft 7 has to run apt in order to update or install a {build,stage} package, it must be invoked as root. Running sudo snapcraft --destructive-mode results in {parts,prime,stage}/ directories which are all owned by root:root, regardless of the user which ran the command. I would expect that snapcraft would invoke apt using sudo (or whatever method) instead of running as root for the duration of each part's lifecycle. Running with elevated permissions when it isn't required results in bad behavior, from having files and folders owned by one user in another user's directory, all the way up to allowing potentially unfettered and dangerous access to / during builds. snapcraft 7 should drop permissions as early as possible during builds, at least when run in destructive mode. Note that this behavior does not exist on snapcraft 6; running snapcraft --destructive-mode runs in the expected way.

Evaluation history

Date Model Scores Action Summary
qwen/qwen3.6-35b-a3b Closed without resolution due to inactivity. The report identifies a snapcraft 7 regression where sudo builds retain root privileges instead of dropping them, unlike snapcraft 6. No fix or discussion occurred.
qwen/qwen3.6-35b-a3b Closed without resolution. The report regarding snapcraft 7 failing to drop sudo permissions during builds, causing root-owned directories, was closed without comment or fix.
qwen3.6-35b-a3b-mtp-q6 Closed without discussion or documented resolution. The report highlights a snapcraft 7 regression where sudo builds retain root privileges, causing root-owned files. Likely abandoned or superseded by subsequent releases.

Update history

No update history recorded yet.

Related issues

Issue Project State Summary Similarity
#1741753 Snapcraft clean fails on root-owned files snapcraft (launchpad) closed Closed without resolution. snapcraft clean failed with a PermissionError when removing root-owned files from the build directory. No fix or discussion was provided.
76%
#1973197 snapcraft 7.x not running override-build snapcraft (launchpad) closed snapcraft 7.x failing to execute override-build was closed without a fix or resolution. Zero comments were posted, indicating the report was abandoned.
76%
#1800119 snapcraft cleanbuild snapcraft (launchpad) closed Closed without resolution. The report details a PermissionError during snapcraft cleanbuild caused by restricted access to the .aptitude directory. With zero comments and no fix applied, the issue was abandoned or marked stale.
75%
#1981979 snapcraft 7.0.8+ stopped working on non debian systems snapcraft (launchpad) closed Closed without resolution or comments. The reported apt_pkg error blocking snapcraft 7.0.8+ builds on non-Debian systems remains unfixed and the issue appears abandoned.
74%
#1871109 snapcraft should check file creation permissions and warn/error out instead of generating a non-functional snap snapcraft (launchpad) closed Closed without resolution. The requested permission checks were not implemented, and the issue remains abandoned.
73%
#1627843 snapcraft should check permissions before starting an upload snapcraft (launchpad) closed Closed without resolution due to prolonged inactivity. The request to validate authentication permissions before uploading large snaps was abandoned, with no fix or implementation added to subsequent versions.
72%
#1889081 snapcraft does not detect need to re-clean part after permission bits change on file snapcraft (launchpad) open Snapcraft fails to detect permission-bit-only changes in dump part source files, requiring manual clean before re-priming. Untriaged, no maintainer activity in ~5.5 years; related Launchpad bug still open.
72%
#1503495 snapcraft for maven project included setuid binary snapcraft (launchpad) closed Closed without resolution. Snapcraft was requested to strip setuid/setgid bits from packaged binaries to comply with snap security policies.
71%
#6118 snapcraft changes permissions of some files snapcraft closed Rejected as not a snapcraft bug. Unexpected file permission changes were traced to coreutils or the core-base build process. The author closed the issue and referenced core-base PR 421 for the fix.
71%