andredias / codebox Goto Github PK

It would make that information available in the logs.

It seems possible to limit the amount of memory using rlimit_as and file size using rlimit_fsize. This way, I'm not sure if using NsJail cgroups is still necessary. If not, it would be possible to get rid of NsJail class and call execute directly.

It is also worth investigating if it will be possible to run the container using nobody as the user.

Codelab used to use this a while ago. Not sure if this could improve performance, but it is worth it a try.

Python Discord has a very similar sandbox container called snekbox which uses some very good ideas that we can also apply in codebox:

1. It is based on HTTP instead of stdin, stdout, stderr
2. It uses NsJail to create sandboxed processes. Using it, we might create a unique container to serve all jobs instead of spinning up a container for each project. Or even better, we can drop the additional container at all.

There is another similar project called Piston that is based on LXC containers that might be useful too.

• Using Flake8 and pyproject.toml with FlakeHell

/projects entry, for example, transforms an array of projects in JSON from Redis into an array of Pydantic Objects that will be transformed at the end into a JSON array by FastAPI. There must be some way to return the information closer to the way it comes from Redis.

Despite not being a big project, adding a dead-code analyzer might be useful not only to Codebox but to other projects as well.

Vulture

Although wait_until_responsive works fine, it might be interesting to use the retry decorator from Tenacity instead.

A few months ago, I wrote an article about the Perfect Python Project. There is a GitHub repository for it at https://github.com/andredias/perfect_python_project. Some of the ideas in that article weren't applied to Codelab/Codebox because these projects are older. I want to update them to use those ideas.

Add a new entry in the API to inform available languages and their versions.

SQL Fluff

Go, Rust, Javascript, SQL(ite)

See https://github.com/engineer-man/piston/tree/master/packages It contains examples of language installations.

In order to prevent security issues in malicious file paths, the source file creation should run inside a jail environment, where only /sandbox and /tmp directories are writeable. No additional security checks will be necessary.

The developer's machine is not sandboxed and should not run any testing snippets, at the risk of being damaged. So, it is important to make sure that the code execution only happens inside a container.

See https://stackoverflow.com/questions/23513045/how-to-check-if-a-process-is-running-inside-docker-container

Nsjail documentation is very scarce. It is hard to find anything even on Google. For example, I couldn't find an example about how to declare a parameter for a mounting point with a limit size. (--mount /tmp/sandbox_234:/sandbox:??:??,size=200m).

On the other hand, minijail is an official Google project and it seems to have better documentation. It is yet to see how hard would be to replace nsjail.

Current tests make calls to REST API in a running container. So, test coverage doesn't work well and gives wrong statistics. To get better results, tests must run inside the container, following the pattern to call the app directly, as used in ordinary FastAPI tests.

As codebox doesn't have external dependencies, we might use something like:

docker run --rm -it --privileged --init -e ENV=TESTING --ipc=none \
      -v $(pwd)/tests:/codebox/tests \
      --name codebox codebox pytest -svx

Related to #2, Codebox should support Rust.

Some common packages such as isort, blue, flake8 etc. should be available to Python projects or Codebox's clients to lint code or something like that.

The packages should be installed in a different virtual environment directory that will be made available later to the jail environment through a directory called /.venv. This directory should also be added to the PATH environment variable to the jail environment.

Probably, the best way to install those packages is from the Dockerfile. Also, we might use a Docker volume to keep and update those packages.

It is worth investigating whether PYTHONPATH or PYTHONUSERBASE is the best envvar to keep the new path, or if PATH is enough.

Snekbox has a similar concept. See its README.