Run gateway sessions as the configured sandbox user - #21
Merged
Conversation
A gateway session entered as root, because `sbx exec` without --user is root and the gateway path ignored DOCKER_SBX_SSH_USERNAME. Agent CLIs refuse to run as root, so a caller's run died at startup. Now one sbx invocation still enters as root to make and own the per-host home, then drops to DOCKER_SBX_SSH_USERNAME with `su -m`, which keeps the exported HOME. The root default is byte-identical to before. The SFTP backing shell goes through the same open(), thus it drops to the user too.
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
1 participant
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.
The gateway opened sessions with
sbx exec --interactive <name> bash -l -c <script>, which enters the sandbox as root. The provider already hasDOCKER_SBX_SSH_USERNAME(defaultroot), but only the provisioning bootstrap honored it — the gateway path ignored it, so every exec and the SFTP backing shell ran as root.That breaks agent CLIs, which refuse root: a caller's run died at startup with
--dangerously-skip-permissions cannot be used with root/sudo privileges. The template images ship a non-root user for this, and the setting names it; it just never reached the session.Change
_session_scriptgains auser. The exec still enters as root in one invocation (no second prep exec, nosbx exec --user, which could not create/chown the home under/home):chownit to the user (top level), thenexec su -m <user> -s /bin/bash -c <payload>.su -mkeeps the exported HOME, so the session home stays/home/<host-name>, now owned by the user who writes it.suruns a PAM session, so/etc/environment(the sandbox env the bootstrap writes) still reaches the session. The user and payload are shlex-quoted.SbxExecProcess.openreadsDockerSbxSettings().ssh_usernameand passes it through. The SFTP backend calls the sameopen(), so its backing shell drops to the user too — verified, and covered by a test.Verification
uv run ruff check/ruff format --check/pyright: clean;uv run pytest: 466 pass.test_process.py: the root default is byte-identical; a non-root user getschown+suwith the payload quoted inside; prepare runs beforesu; the SFTP server command drops to the user;open()honorsDOCKER_SBX_SSH_USERNAMEfrom the environment; the PTY path is unchanged.docs/deploy.md: the gateway section states sessions run asDOCKER_SBX_SSH_USERNAME(default root), and that deployments whose agents refuse root set a non-root user present in the template image.