从零开始写OJ---评测姬原理

之前我们分析了OJ的组成：WEB、数据库、评测机，今天我先来分析一下评测姬要怎么实现。

首先还是分析一下评测姬的评测流程：首先，从数据库(或者其它的什么地方)拿到用户提交的代码，把代码进行编译，限制资源执行编译出来的二进制文件，对比输出和标准答案，最后返回评测结果。

这个流程图在学长的基础上，修改了OLE的判断错误，修改了RE的判断顺序，大致就是我要做的评测姬的流程了。

我的评测姬大体上还是使用Lo-runner这个的思路。使用Linux下C语言的struct rlimit与setlimit函数来做时间与内存资源的软硬限制，父进程vfork子进程并使用struct rusage和wait4函数来获取资源的使用情况。

但是原作者的评测系统还是有一些小小的问题，比如说只有CPU时间限制而没有实际运行时间限制(虽然写了，但是注释掉了)，在我的测试中，如果提交一个sleep(1000)，那么就会卡住评测1000S，再比如，没有对编译阶段做任何限制，如果提交#include </dev/random>就会一直卡在编译阶段，或者提交main[-1u]={1};就会编译很久，产生16G的文件。还有一些提交的代码会产生巨量的编译错误信息。原作者对于这些都没有防护，但其实现在有许多OJ平台也没有进行防护，比如某某OJ被这些提交多次卡评测。

其实防护的方式也很简单，我现在在自己学校的OJ的评测姬做了降权运行、限制编译资源、设置实际运行时间限制等的更新。即使不做这些，也有其它的不需要改评测机的解决办法，比如每隔一段时间结束掉评测机然后再重启之类的，虽然可能会误伤正常提交，但是把握好间隔时间，或者做一些额外的判断什么的，起码不会说像某OJ一样评测被卡好几天。

这里列出了一些OJ可能遭到的提交攻击，虽然据我的观察，这位同学是把知乎上的两个问题Online Judge 是如何解决判题端安全性问题的？和怎样做一个 Online Judge（在线评测系统）？底下的答案整合了一下……这位同学发布这篇文章后没几天，果然有人(本校同学，得到许可)用里面提到的方法来攻击本校OJ。幸好我看到这两个问题的时间比较早，提前几个月把这两个问题下提到的攻击方式做了一些防范。

这里只是大致的介绍了一下我的评测姬的原理和一部分安全防范措施，其实我的代码还没写完…之后再写一篇博客来详细的介绍评测姬的安全策略和具体解决方案吧。