Put compilation actions into Sandbox

[natsukagami]

Is your feature request related to a problem? Please describe.
See here for why.
Basically you don't want to have people #include "/etc/shadow" or something similar.

Describe the solution you'd like
Run compile commands in a sandbox. Most changes are just going to be within https://github.com/natsukagami/kjudge/blob/391b164e07c5e2fcbe17aa0a77bbc9f519ea1627/worker/compile.go#L134:L165.
Check https://github.com/natsukagami/kjudge/blob/391b164e07c5e2fcbe17aa0a77bbc9f519ea1627/worker/run.go#L116:L127 for an example of how to use the sandboxes.
We might need to mount some additional stuff, see https://github.com/cms-dev/cms/blob/4aa39c18a87f20ff0cd3e9efe023b9b4e19ddc4c/cms/grading/steps/compilation.py#L98.

[minhnhatnoe]

Just thought about this today. A couple of other reasons includes to limit memory usage of compilers and to limit the size of executable files. See below for additional details regarding these problems.

Excessive compiler memory usage

While it's rare to see compilers using much more memory than thay should, with the development of features similar C++'s constexpr, there is a risk of this happening. Notable examples are computing dynamic programming arrays at compile-time, or the popular "constexpr sieve of Eratosthenes". While I do realize that most compilers actually do put a limit on the number of operations allowed, many compilers have been seen to use ridiculous amounts of memory, allocating as much memory as they could, for very simple constexpr functions.

Huge executable file size

Obviously, the executable size should be checked by the judging system after compilation. However, I believe it is possible for contestants to write code that generates a binary large enough to destabilize the judging system. Moreover, this behavior is not very uncommon for a regular contestant's code. A notable example would be defining a POD class in C++ (a class with no default constructor) with default values for attributes, then immediately creating an array of the aforementioned class. GCC has been observed to attempt to record the entire array in the executable.

Also, I think it would be logical to actually impose limits on compilation time, probably logging a warning at 20s (the limit specified in compile.go) and terminating at 30s.

[natsukagami]

Yep, currently we do have a simple timeout for compilation tasks, but the compilation itself is not sandboxed. It's good to have those implemented sooner.

[natsukagami]

@minhducsun2002 If you are working on this please assign yourself :D

[minhducsun2002]

:ICANT: (literally)