Skip to content

Conversation

@timmc-edx
Copy link
Contributor

@timmc-edx timmc-edx commented May 9, 2025

Codejail currently makes a decision at module load time of whether it should run all code safely or unsafely, and defaults to unsafely. This causes several problems:

  • Any misconfiguration of codejail (such as a missing Django setting or middleware) results in the application becoming immediately and entirely vulnerable to anyone who can submit code.
  • Codejail's behavior changes depending on when the codejail.safe_exec module is loaded during application initialization. This causes unstable behavior and is confusing for developers.

This change switches the ALWAYS_BE_UNSAFE check to occur only at the time that safe_exec is actually called, rather than at module load time.

The check for whether codejail is configured for Python is also moved to call time, but no longer automatically switches codejail to unsafe mode. Instead, it raises an exception to notify the user of their error.

This addresses #16

@timmc-edx timmc-edx force-pushed the timmc/safe_by_default branch 4 times, most recently from 57aebd3 to 0621d9c Compare May 9, 2025 21:32
@timmc-edx timmc-edx marked this pull request as ready for review May 9, 2025 21:33
@timmc-edx timmc-edx changed the title feat!: Require an explicit opt in to unsafety; defer decision to call time fix: Require an explicit opt in to unsafety; defer decision to call time May 9, 2025
@timmc-edx timmc-edx force-pushed the timmc/safe_by_default branch from 0621d9c to 48d59e9 Compare May 9, 2025 21:35
@timmc-edx timmc-edx requested a review from MoisesGSalas May 14, 2025 13:04
Copy link
Contributor

@MoisesGSalas MoisesGSalas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @timmc-edx, sorry for being away for so long.

I all looks fine and I tested the RuntimeError on the edunext codejailservice and it worked. Would you mind rebasing on top of the current master?

# over the computer immediately and entirely.
#
# The only purpose of this setting is for local debugging.
ALWAYS_BE_UNSAFE = False
Copy link
Contributor

@MoisesGSalas MoisesGSalas Jun 12, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is there a code path that sets this to True somewhere?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not an existing one, no. This would be in case some application that was integrating codejail needed to enable unsafe mode.

@timmc-edx timmc-edx force-pushed the timmc/safe_by_default branch from 51540bc to 68918ef Compare June 12, 2025 21:32
Codejail currently makes a decision at module load time of whether it
should run all code safely or unsafely, and defaults to unsafely. This
causes several problems:

- Any misconfiguration of codejail (such as a missing Django setting or
  middleware) results in the application becoming immediately and entirely
  vulnerable to anyone who can submit code.
- Codejail's behavior changes depending on when the `codejail.safe_exec`
  module is loaded during application initialization. This causes unstable
  behavior and is confusing for developers.

This change switches the `ALWAYS_BE_UNSAFE` check to occur only at the time
that `safe_exec` is actually called, rather than at module load time.

The check for whether codejail is configured for Python is also moved to
call time, but no longer automatically switches codejail to unsafe mode.
Instead, it raises an exception to notify the user of their error.
@timmc-edx timmc-edx force-pushed the timmc/safe_by_default branch from 68918ef to 1f97afa Compare June 12, 2025 21:33
@timmc-edx timmc-edx merged commit d6421dc into master Jun 13, 2025
7 checks passed
@timmc-edx timmc-edx deleted the timmc/safe_by_default branch June 13, 2025 11:06
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.

4 participants