feat: run compilation inside sandbox containers - #213
Merged
Conversation
When GDBUI_DOCKER=true, start_gdb runs GDB inside a per-session container via docker exec instead of on the host. Binary path switches to /workspace/<name>.exe (bind-mounted output dir). Container teardown mirrors controller teardown across all paths: stop_gdb, end_session, expiry cleanup, and program-switch in start_gdb. Fails closed if the container cannot start.
When GDBUI_DOCKER is enabled, g++ now runs inside the per-session sandbox container via docker exec instead of on the host, so compile and debug are both isolated. start_container is idempotent (a second call reuses the running container instead of failing on the name conflict), and compilation fails closed if the container can't start. README gains a Sandbox Mode section.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
PR 3/3 of the Docker sandbox phase (branch contains #212's commits; PRs #211 + #212 should merge first). When
GDBUI_DOCKER=true, compilation now runs inside the per-session sandbox container viadocker exec, so compile + debug are both isolated — closing the gap whereg++still ran on the host.Changes
gdbui_server/sandbox.py—start_containeris now idempotent: a Docker name-conflict (container already running for the session) returns the existing name instead ofNone. Required because compile runs beforestart_gdb, and a seconddocker run --namewould collide and fail closed.gdbui_server/main.py—compile_code()builds the compiler command by mode: sandbox on →docker exec -i <name> g++ -g -O0 /workspace/<src> -o /workspace/<bin>; sandbox off → unchanged hostg++. Fails closed: if the container can't start while sandboxing is on, compilation is refused (400 COMPILATION_FAILED) andsubprocess.runis never reached.gdbui_server/tests/test_sandbox.py— +2 tests (idempotent start on name-conflict;Noneon otherCalledProcessError).gdbui_server/flask_test.py— +2 tests (docker-exec compile args; fail-closed when container start fails).README.md— new Sandbox Mode (Docker) section; thecall system("rm -rf /")limitation now points to it as the mitigation.Behavior
GDBUI_DOCKER=false): zero behavioral change. All existing tests pass unchanged.g++executes in the container (--read-onlyrootfs,--network none,--tmpfs /tmp). Theoutput/{session_id}/bind mount at/workspacemeans the compiled.exelands exactly where GDB (start_gdb) already looks.Test Plan
python3 -m unittest discover -s tests— 56 passing (54 existing + 2 new)python3 flask_test.py— 18 passing (16 existing + 2 new)GDBUI_DOCKER=true→ compile + debug a program, confirm g++ ran in the containerNotes
Stacked on #211 (infra) and #212 (lifecycle wiring) — review/merge those first.