-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Set up sandbox environment inside codejail image #103
base: main
Are you sure you want to change the base?
Conversation
- Install Python 3.8 from deadsnakes for sandbox Python - Install depencies for use inside sandbox - Install sudo for entering sandbox - Document relationship to codejail's docs Also, some cleanup: - Rename args `GITHUB_REPO` to `APP_REPO` and `VERSION` to `APP_VERSION` to help distinguish from sandbox args - Similarly, rename `PYVER` to `APP_PY_VER` for clarity
Also move SAND_DEPS a bit later in the file since it doesn't actually relate to codejail's sandboxing structure. (It's just a temporary file used only during image building.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changes look great. Thanks. Minor comments.
# - This Dockerfile is for the codejail-service, a wrapper around the codejail | ||
# *library*. When used in isolation, "codejail" usually refers to the library. | ||
# - "Sandbox" refers to the secured execution environment for user-submitted | ||
# code, not to the sandbox deployment environments used for debugging. This |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
# code, not to the sandbox deployment environments used for debugging. This | |
# code, not to the sandbox deployment environments used for debugging. This |
# Some of this structure can be changed, and some cannot. Any changes that are | ||
# possible will also need to be coordinated with changes to the apparmor profile | ||
# as well as to the `CODE_JAIL` Django settings. Accordingly, it's best to just | ||
# *avoid* making making changes to this part. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
# *avoid* making making changes to this part. | |
# *avoid* making changes to this part. |
# possible will also need to be coordinated with changes to the apparmor profile | ||
# as well as to the `CODE_JAIL` Django settings. Accordingly, it's best to just |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You didn't like the idea of providing links/descriptions of where these things live? Is there a doc that notes how all these things hang together and also provides a way to navigate to all the related parts?
ARG SAND_VENV=/sandbox/venv | ||
# Sandbox user account | ||
# The OS account that will run code executions, described just as "the sandbox |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is "OS account" different than a "user account"? Why does "user account" seem more recognizable to me? Is "OS user account" a different thing, or a better term that adds what you want, but retains "user"?
Note: Later you have a comment that includes "...switch to app user..." it would be great if the term "user" could appear in the initial comment for consistency.
Also, some cleanup:
GITHUB_REPO
toAPP_REPO
andVERSION
toAPP_VERSION
to help distinguish from sandbox argsPYVER
toAPP_PY_VER
for clarity