存在部分程序直接在 uoj-web 容器中编译

[yzy-1]

UOJ-System/web/app/libs/uoj-data-lib.php

Lines 90 to 94 in be41da9

	if (isset($config['need_include_header']) && $config['need_include_header']) {
	exec("$cmd_prefix --add-readable-raw=$include_path/ /usr/bin/g++ -o $name {$config['src']} -I$include_path -lm -O2 -DONLINE_JUDGE");
	} else {
	exec("$cmd_prefix /usr/bin/g++ -o $name {$config['src']} -lm -O2 -DONLINE_JUDGE");
	}

根据此处的代码，题目的 std.cpp val.cpp chk.cpp 以及 interactor.cpp 均是在 uoj-web 而非 uoj-judger 容器中编译的，且编译直接采用 exec 执行，没有包装任何沙盒，想具体提出几个问题：

• 这样设计的用意何在？
• 如何解决 uoj-web 和 uoj-judger 的 glibc 版本不一致或者编译器导致编译出来程序跑不了的情况？
• 是否会存在安全性问题？比如有人上传恶意程序（编译时间非常长或者编译内存占用多、生成的可执行文件大）的程序传上去当 chk 引起整个 uoj-web 宕机．

[renbaoshuo]

以前整个 UOJ 都是跑在同一个容器里的，所以 web 端编译了以后 main_judger 可以直接用，都是在一个环境下面的。这个容器的拆分是我最近才做的，可能还需要一些后续的改进。

目前我个人的看法是为了保证不同评测机之间的一致性，各个评测机的主机配置应该是相近的，不会出现不同架构混用的情况。此外 Docker 的引入也保证了各个评测机之间系统和软件环境的一致性。我回头再思考一下这里该怎么处理会更好。

至于安全性问题，我们相信具有传题权限的管理人员是不会去进行恶意破坏的。如果有人恶意破坏的话，只能说明是管理员选拔过程中的问题。UOJ 甚至还支持 custom_judger，编译和运行的时候都不受限制，全程都可以自定义，这个怎么防？所以最好的办法我觉得还是从源头上控制权限。

[yzy-1]

感觉这么设计还是有点不太合适，编译选项是写死的，想换一个语言或者改一下 -std 标准都做不到．

[renbaoshuo]

https://github.com/renbaoshuo/S2OJ/blob/86b9b47dd8570cbc9862a1f67e43da122279b6bf/web/app/models/UOJProblemDataSynchronizer.php#L407

社区版没有这个功能，我自己同步的官网版代码倒是可以指定语言版本。

其实早就打算把我们这边基于社区版和官网版做的改动来同步一下，但是一直没有时间去搞。