Consider creating and making the _daemon_ user available before running any steps

Metadata

Project: rockcraft
Number: #447
Type: issue
State: open
Author: merkata
Labels: —
Created: 2023-12-13 07:54 AM UTC
Updated: 2025-08-15 03:12 PM UTC
Closed: —

Current evaluation

Feature request to create the _daemon_ user before build steps (currently created during packaging in package.py) so it is available for part steps and has a writable home dir. No maintainer response or labels after ~2.7 years; code behavior unchanged.

Suggested action: needs triage

Reason: The issue has no labels, no comments, and no maintainer response after ~2.7 years. Code inspection confirms the premise is still valid: rockcraft/services/package.py line 125 creates the _daemon_ user via SUPPORTED_GLOBAL_USERNAMES during the packaging phase, not before build steps. No related PRs or commits address this, so the issue remains technically relevant but has never been triaged.

Impact: 35 Quick Win: 19.25 Staleness: 70 Complexity: 45 Confidence: 60 Support Request: 25

Issue body

### What needs to get done I see currently the _daemon_ user is created after all steps for all parts are done and the home dir is PEBBLE_PATH (and that user does not have access to it). It would be beneficial to bootstrap that user in advance, so before all steps rather than after all the steps and make that user available. ### Why it needs to get done That would play nicely with translating Dockerfiles to rockcraft files, things like su user -c "funky bash stuff" would just work. Now you have to do the funky stuff as root and then chown with UID/GID of _daemon_. For the second part of having a non-writable home directory, I was hoping the _daemon_ user could get something that it calls home and can write to it. I'm explicitly overriding a prime step and adjusting permissions per sub-directory (I don't want to change ownership of PEBBLE_PATH, so I chown PEBBLE_PATH/.local, PEBBLE_PATH/.config etc.). In general you wouldn't want to write something in your home at runtime and refer to it I guess, though still living under PEBBLE_PATH feels weird to me.

Evaluation history

Date	Model	Scores	Action	Summary
2026-09-01 01:49 AM UTC	qwen/qwen3.8-27b	Impact: 35 Quick Win: 19.25 Staleness: 70 Complexity: 45 Confidence: 60 Support Request: 25	needs triage	Feature request to create the _daemon_ user before build steps (currently created during packaging in package.py) so it is available for part steps and has a writable home dir. No maintainer response or labels after ~2.7 years; code behavior unchanged.
2026-07-22 12:13 PM UTC	qwen/qwen3.6-35b-a3b	Staleness: 90 Complexity: 45 Confidence: 85 Support Request: 10	needs triage	Feature request to create the _daemon_ user earlier in the build process to improve Dockerfile-to-Rockcraft compatibility and resolve permission issues. Currently unlabelled and inactive for over a year.
2026-07-08 08:06 AM UTC	qwen3.6-35b-a3b-mtp-q6	Staleness: 90 Complexity: 45 Confidence: 85 Support Request: 10	needs triage	Feature request to create the daemon user earlier in the build process for better Dockerfile compatibility and permission handling. Unlabelled, no maintainer engagement, and inactive for over a year.
2026-07-05 10:38 AM UTC	qwen3.6-35b-a3b-mtp-q6	Staleness: 85 Complexity: 55 Confidence: 40 Support Request: 15	needs triage	Feature request to create the daemon user earlier in the build process instead of after all steps, improving compatibility with Dockerfile to rockcraft translations. Currently unlabelled and inactive for over a year.
2026-06-16 12:53 PM UTC	qwen3.6-35b-a3b-mtp-q6	Staleness: 85 Complexity: 40 Confidence: 65 Support Request: 10	needs triage	Suggests bootstrapping the daemon user earlier in the build with a writable home directory to enable user-specific commands during build steps. Open, zero comments, inactive for 304 days, awaiting triage.

Update history

No update history recorded yet.

Related issues

No related issues found above the similarity threshold.