[yanksyoon]

What this PR does

Writes USER and LOGNAME to the runner .env for every GARM scale set, set to the account the runner's UID resolves to. The account is resolved on the instance, not hardcoded.

Also adds the missing assertion to the GARM e2e job: it runs on a real GARM-spawned runner and now checks that the job identity matches its UID and that usermod -aG followed by sg succeeds.

Why we need it

GARM starts the runner as runner, which the runner images create as a duplicate-UID alias of ubuntu:

/etc/passwd                     first entry wins for getpwuid
  ubuntu:x:1000:1000  <- first
  runner:x:1000:1000  <- alias, same uid and gid
/etc/group
  ubuntu:x:1000:      runner:x:1000:
/home/runner -> /home/ubuntu

One process, two names, and group membership is stored per name:

  $USER, $LOGNAME   ->  "runner"
  getpwuid(1000)    ->  "ubuntu"
  sg's name lookup  ->  "ubuntu"

So a step that hands $USER to a UID-keyed tool writes one name and is checked as the other:

  sudo usermod -aG sbuild $USER        # $USER = "runner"
      -> /etc/group: sbuild:x:1234:runner

  sg sbuild -c 'mk-sbuild noble'
      -> gid 1234 not in this shell's groups (shell predates the usermod)
      -> caller name = getpwuid(1000) = "ubuntu"
      -> "ubuntu" in [runner]?  no
      -> Password:            (ubuntu is locked)
      -> Invalid password.    exit 1

This is the Setup build prerequisites failure in canonical/toolchains-ci on every GARM pool. Legacy runners pass because su - ubuntu makes both sides ubuntu.

Fix. The runner applies <runner root>/.env to its own environment before any job starts (actions/runner, src/Runner.Listener/Program.cs, LoadAndSetEnv), and steps inherit it. The charm already delivers ACTIONS_RUNNER_HOOK_JOB_STARTED, DOCKERHUB_MIRROR and the tmate variables that way.

  .env:  USER=<account the runner UID resolves to>
         LOGNAME=<same>

  $USER                    ->  same account
  getpwuid(1000)           ->  same account
  usermod -aG sbuild $USER ->  sbuild:x:1234:<same account>
  sg sbuild                ->  match, no password

Where it lands. Injected into github_linux_charmed, so it reaches every GARM scale set:

  github_linux (GARM system template)
      |
      v
  github_linux_charmed  + USER/LOGNAME  + tmate vars
      |                    |
      |                    +--> scale sets with runner options copy it
      |                         as the base for their own template
      |
      +--> scale sets without runner options reference it directly

What this does not fix

The alias remains; only $USER and $LOGNAME change. Removal of this override is tracked in #438.

• Literal runner. usermod -aG sbuild runner followed by sg sbuild still ends in Password: Invalid password.
• Name-keyed state. Membership lands on the account the UID resolves to, while GARM's account stays runner: getent group docker lists ubuntu, sudo -l -U runner does not, and name-keyed policy (limits.conf, pam_access, getpwnam("runner")) is evaluated against ubuntu.
• Anything started outside a job step. tmate/debug-ssh sessions, systemd-run, systemctl --user, cron, docker exec and container steps do not inherit .env.
• logname / getlogin(). Still empty — no login session, as today.
• Reach. Only pools built from github_linux_charmed. If the charm cannot reach GARM, the unit reports WaitingStatus before ScalesetReconciler runs: existing scale sets keep whatever template they already reference and no new ones are created, so the block is not silently dropped from live scale sets.

Test plan

• tox -e unit: 449 passed
• tox -e lint, tox -e static, tox -e fmt: clean
• Rendered the snippet with and without a debug-ssh connection and checked it with bash -n
• Dry-ran the new e2e steps on a noble host against both account layouts: the identity assertion exits 1 with USER=runner (today's layout, before the fix) and 0 with USER=ubuntu; the usermod -aG + sg step passes; the layout report prints 2 passwd entry/entries for the alias layout and 1 once runner has its own UID
• E2E (promotion pipeline, not a merge gate): garm_e2e_test_run.yaml now asserts, on a real GARM-spawned runner, that $USER and LOGNAME equal the UID-resolved account and that usermod -aG <group> "$USER" then sg <group> succeeds — the pattern from the original report. Before this PR that job printed whoami but asserted nothing, so the disagreeing value sat in the logs unnoticed.

New unit coverage: no account name is baked into the template, the lookup is emitted, both assignments go through the format string, an empty lookup is guarded, the tmate block keeps its quoted heredoc, the block lands before the base set -e, and exactly one USER assignment is written.

Review focus

• The account pair uses printf while the tmate block keeps a quoted heredoc: the account value must expand on the instance, relation-provided values must not.
• id -u runner is used instead of id -u, because cloud-init runs the template as root.
• On an image where runner has its own UID the resolved value is runner, so the override becomes a no-op rather than targeting the wrong account.

Potential breaking changes

USER/LOGNAME change from runner to ubuntu in job steps on the current images. Both names share uid 1000 and gid 1000, so this is name-only for chown, sudo -u and usermod; commands that record the name (group files, logs) now record the one id -un already returned.

Checklist

• Changes comply with the project's coding standards and guidelines (see CONTRIBUTING.md and STYLE.md)
• CONTRIBUTING.md has been updated upon changes to the contribution/development process — not applicable
• Technical author has been assigned to review the PR in case of documentation changes — not applicable, changelog only
• I updated docs/changelog.md with user-relevant changes
• I used AI to assist with preparing this PR
• I added or updated tests as needed (unit and integration)
• Integration test modules: not applicable
• Grafana dashboard: not applicable
• Terraform: not applicable
• Rockcraft: not applicable
• AGENTS.md: not applicable, no charm or repo-structure change
• .copilot-collections.yaml / .github/instructions/: not applicable

[yanksyoon]

We need to further discuss what the long term solution to this underlying paradigm of two users would be (ubuntu user and runner user).

[cbartz]

Makes sense as a stopgap: on the current images it only aligns $USER/$LOGNAME with what whoami/id -un already report, and it matches the legacy runners' ubuntu environment. Two things I'd like before merge, plus a few nits.

To address before merge

• Resolve the account at runtime instead of hardcoding ubuntu. The override is applied to every scale set, but it is only correct on images where runner is a duplicate-UID alias of ubuntu. On an image where runner has its own UID, USER=ubuntu would be wrong and usermod -aG <group> $USER would modify the wrong account. Resolving on the instance, e.g. getent passwd "$(id -u runner)" | cut -d: -f1 with an unquoted heredoc, is a no-op on non-aliased images, correct on the current ones, and drops the cross-repo RUNNER_UID_USER constant.

• Open a tracking issue for removing this override and link it from the code. This is a workaround for the duplicate-UID layout of the runner images, and the long-term fix is still to be decided at the design meeting. An issue gives that discussion a home and gives this override a planned removal. Without one, a charm-wide change to $USER tends to stay forever. Referencing it from the build_runner_env_snippet docstring (and the changelog entry) tells the next reader when it can go.

Nits

• PR description, "What this does not fix": a CharmedTemplateError doesn't make scale sets fall back to the base template. _reconcile raises before ScalesetReconciler runs, the unit goes to WaitingStatus, and existing scale sets keep whatever template they already reference.
• The PR body doesn't follow .github/pull_request_template.md ("What this PR does" / "Why we need it" / checklist). The existing content maps onto it easily, and the checklist (changelog, tests, AI assistance) is worth ticking.
• See the inline comments.

AI-generated message.

[cbartz]

Approving: all points from my earlier review are addressed. The account is now looked up on the instance, so the override does nothing on images where runner has its own UID; removal is tracked in #438; and the .env writers are merged into one. I checked GARM's github_linux template: it runs chown -R on the runner directory and chown on .env itself after install, so creating .env as root first doesn't affect ownership.

Recommendation before merging: please dispatch the GARM e2e run (garm_e2e_test_run.yaml) on this branch. So far the fix has been tested with unit tests and a dry run on a noble host. The new identity and usermod -aG + sg checks are the only way to confirm that the runner applies the .env override to job steps on a real GARM-spawned runner, including in agent mode.

AI-generated message.