Skip to content
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

Use LMS as codejail service for CMS #33538

Open
1 of 17 tasks
timmc-edx opened this issue Oct 18, 2023 · 0 comments
Open
1 of 17 tasks

Use LMS as codejail service for CMS #33538

timmc-edx opened this issue Oct 18, 2023 · 0 comments
Assignees

Comments

@timmc-edx
Copy link
Contributor

timmc-edx commented Oct 18, 2023

A/C:

As a step towards moving codejail to its own service and containerizing edxapp, we could move to an intermediate approach where the LMS runs codejail executions on behalf of CMS. This would provide the following benefits:

  • CMS could be containerized independently of LMS (no need to do both at the same time).
  • We would exercise the remote-codejail pathway and have an opportunity to discover and implement needed improvements before fully building out a separate codejail service.

This would entail adding a new view in LMS and configuring CMS to call it, as well as adding some authorization code.

Implementation details:

  • "Send this to a remote codejail" is already implemented in xmodule/capa/safe_exec/remote_exec.py
  • Ideally, we should keep the request/response format and the path the same so that we don't need to add yet another remote-codejail code path or use an intermediary (API Gateway?) to adjust the request.
  • The new view needs to require authorization, particularly since execution parameters like unsafely are in play. We can adjust remote_exec.py to add a token on behalf of the cms service user.
  • Regardless of authorization, LMS should ignore the unsafely request parameter unless a new Django setting (maybe CODEJAIL_SERVICE_ALLOW_UNSAFE) is set to True. To my knowledge, 2U does not allow unsandboxed codejail execution. Any deployer who wants to allow this will need to explicitly opt in to this dangerous setting.
@rgraber rgraber moved this to Prioritized in Arch-BOM Oct 19, 2023
@jmbowman jmbowman moved this from Prioritized to Groomed in Arch-BOM Oct 27, 2023
@timmc-edx timmc-edx moved this from Groomed to On-Call in Arch-BOM Nov 20, 2023
@timmc-edx timmc-edx moved this from On-Call to In Progress in Arch-BOM Nov 20, 2023
@timmc-edx timmc-edx self-assigned this Nov 20, 2023
@timmc-edx timmc-edx moved this from In Progress to Groomed in Arch-BOM Nov 29, 2023
@timmc-edx timmc-edx removed their assignment Nov 30, 2023
@timmc-edx timmc-edx moved this from Groomed to In Progress in Arch-BOM Dec 20, 2023
@timmc-edx timmc-edx self-assigned this Dec 20, 2023
timmc-edx added a commit that referenced this issue Jan 9, 2024
This supports having an authenticated codejail service in general, but in
particular is to support the temporary use of the LMS as a codejail
service for the CMS: #33538

The new settings are all optional, and if not provided, the current
behavior does not change.
timmc-edx added a commit to edx/edx-arch-experiments that referenced this issue Jan 11, 2024
@robrap robrap moved this from In Progress to Groomed in Arch-BOM Feb 2, 2024
@jristau1984 jristau1984 moved this from Groomed to Backlog in Arch-BOM Jul 9, 2024
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

No branches or pull requests

1 participant