Skip to content

fix(devbase): repair the gh config directory ownership after a UID remap - #26

Merged
KaiSchwarz-cnic merged 1 commit into
mainfrom
RSRMID-3096-fix-gh-dir-ownership
Oct 28, 2026
Merged

KaiSchwarz-cnic merged 1 commit into
mainfrom
RSRMID-3096-fix-gh-dir-ownership

Conversation

@KaiSchwarz-cnic

Copy link
Copy Markdown
Contributor

Jira: RSRMID-3096. Follow-up to #25, which shipped as devbase 2.1.0 with failing feature tests.

Problem

2.1.0 creates /var/lib/devbase/gh owned by the remote user at build time and relies on Docker seeding the new volume with that owner. The devcontainer CLI then adds its updateRemoteUserUID layer (the image tag ends in -features-uid). That layer remaps the remote user to the host UID and re-owns only $HOME. On any host whose UID is not 1000 (GitHub runners use 1001), the volume comes up owned by the stale UID, and gh auth login fails with "permission denied". That is worse than 2.0.2. Both jobs in #25 failed on exactly this: the "writable by the remote user" check, and the rebuild test writing hosts.yml.

Change

  • Post-create: devbase_setup_gh_config_dir (renamed from devbase_check_gh_config_dir) repairs the directory when it is not writable. It runs sudo -n chown "$(id -u):$(id -g)" and chmod 0700, then proves the result with a second write probe. If sudo is unavailable or wants a password, it reports the manual fix and returns 0. It runs on every create, so every rebuild re-checks it.
  • Comments and docs: the comment and the docs now name the UID remap as the cause. The earlier guess, "the volume already existed", was wrong.

Tests

  • Repair: a directory owned by root is repaired. Asserted on the effect: [ -O ] and a successful write.
  • Report: with a stub sudo that fails, the directory is reported and the function still returns 0.
  • End to end: the existing "writable by the remote user" check and the rebuild job from feat(devbase): persist the gh login across container rebuilds #25 run on a UID-1001 runner.

Releases as a patch (fix(devbase)), 2.1.1.

🤖 Generated with Claude Code

…remap

2.1.0 created /var/lib/devbase/gh owned by the remote user at build time and
relied on Docker seeding the new volume with that owner. The devcontainer
CLI's updateRemoteUserUID layer then remaps the remote user to the host UID
and re-owns only $HOME, so on any host whose UID is not the image's (GitHub
runners are 1001) the volume came up owned by the stale UID and gh auth
login failed with "permission denied".

Post-create now repairs it: when the directory is not writable it runs
sudo -n chown/chmod, proves the result with a second write probe, and
reports with the manual fix when sudo is unavailable. It runs on every
create, so every rebuild re-checks it. The tests assert the repair on a
root-owned directory and the report when sudo fails.

Refs: RSRMID-3096
@KaiSchwarz-cnic
KaiSchwarz-cnic merged commit 9399e98 into main Oct 28, 2026
10 checks passed
@KaiSchwarz-cnic
KaiSchwarz-cnic deleted the RSRMID-3096-fix-gh-dir-ownership branch October 28, 2026 14:12
@github-actions

Copy link
Copy Markdown
Contributor

🎉 This PR is included in version 2.1.1 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant