Skip to content

webgui: run as the bind-mount owner so foresters need no --user flag#25

Merged
RoopsyDaisy merged 1 commit into
mainfrom
webgui-mac-perms
Jun 3, 2026
Merged

webgui: run as the bind-mount owner so foresters need no --user flag#25
RoopsyDaisy merged 1 commit into
mainfrom
webgui-mac-perms

Conversation

@RoopsyDaisy

Copy link
Copy Markdown
Owner

The webgui image ran as the baked-in non-root fvs user. On Docker Desktop (macOS/Linux) a bind-mounted host folder (-v ~/fvs-projects:/work) is presented owned by the host user, which fvs can't write -- so fvsOL's dir.create()/setwd() for a NEW project fails with "Permission denied" and the observer crashes. Reading a pre-existing project works, which is why a basic click-through missed it; creating/saving a project is the first real write to /work.

Fix: an entrypoint (docker/webgui-entrypoint.sh) starts as root and gosu-drops to the uid/gid that owns /work, so the GUI process matches the mount owner and can write -- new project files land owned by the forester on the host. Falls back to fvs when /work is unmounted/root-owned (CI smoke test, named volume). The plain documented docker run -v <host>:/work ... command now works with no --user flag.

Removed USER fvs from the webgui target (container starts as root, entrypoint drops privileges); added gosu. Engine/cluster target unchanged.

What & why

Checklist

  • CI is green (build + in-image smoke test + R test suite).
  • Docs updated to match any code/behaviour change (this repo has drifted before — keep prose true).
  • Tests added/updated for the change (tests/unit or tests/integration), or N/A.
  • No data, secrets, or chat history committed (inventory CSVs stay out — see data/README.md).

The webgui image ran as the baked-in non-root `fvs` user. On Docker Desktop
(macOS/Linux) a bind-mounted host folder (`-v ~/fvs-projects:/work`) is presented
owned by the host user, which `fvs` can't write -- so fvsOL's dir.create()/setwd()
for a NEW project fails with "Permission denied" and the observer crashes.
Reading a pre-existing project works, which is why a basic click-through missed
it; creating/saving a project is the first real write to /work.

Fix: an entrypoint (docker/webgui-entrypoint.sh) starts as root and gosu-drops to
the uid/gid that owns /work, so the GUI process matches the mount owner and can
write -- new project files land owned by the forester on the host. Falls back to
`fvs` when /work is unmounted/root-owned (CI smoke test, named volume). The plain
documented `docker run -v <host>:/work ...` command now works with no --user flag.

Removed `USER fvs` from the webgui target (container starts as root, entrypoint
drops privileges); added gosu. Engine/cluster target unchanged.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@RoopsyDaisy RoopsyDaisy merged commit 43d81ec into main Jun 3, 2026
6 checks passed
RoopsyDaisy pushed a commit that referenced this pull request Jun 3, 2026
The webgui permission bugs (#25, then its uid==0 fallback) shipped because the
smoke test never wrote into /work, so CI couldn't tell that the GUI process can't
create a project there. Add a webgui-only guard that does the same write fvsOL
does (a dir under /work) through the entrypoint-selected user. In CI /work is
root-owned and unmounted, so a non-root runtime user (the #25 fvs-on-uid-0
fallback) fails this guard; running as the mount owner (root, per #26) passes.
Cluster image skips it (no fvsOL; it runs as fvs against a separately-bound cwd).

Locks the permission class so a future entrypoint change can't silently
reintroduce it.

https://claude.ai/code/session_011C6wxKosiwHnEYvAPJfmcW
@RoopsyDaisy RoopsyDaisy deleted the webgui-mac-perms branch June 3, 2026 15:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant