3.judger核心设计
评测系统最重要部分就是评测核心了(judger)。核心judger负责了编译、执行、检查三大部分，也就是评测系统的灵魂所在，因此judger设计的好坏，直接影响到整个评测系统的整体水准。judger的设计要考虑到几个方面，首先是对安全性要求很高。别忘了，这是一个在线评测系统，任何人都可以提交任何代码，并在服务器上执行，这意味着给骇客们提供了方便之门。骇客们（注意，不是黑客）总是希望得到一个Shell，并在上面执行想要的命令。而评测系统直接允许了源码的提交，如果我是骇客的话简直乐坏了。当然，只有傻瓜才会对用户提交的代码直接编译、运行，就像编译自己的程序一样，限制是必不可少的。
不当的方法
一个愚蠢的方案是直接对代码进行扫描，然后过滤掉某些字符串，如"system"。当然这个过滤列表可能长得匪夷所思，就像某墙，然而绕过它却是很容易的，例如以下代码：
#include <stdlib.h>
#define dosomething sys##tem
int main()
{
dosomething("shutdown");
return 0;
}怎么办呢？有人会继续想到，我可以用g++的-E命令，将预处理以后的代码输入到一个文件中，然后再检查关键字。这样的话上面的方法就不行了，不过更厉害的骇客还有办法。什么办法呢？直接按地址调用函数，代码如下：
#include <stdlib.h>
int main()
{
int (*func)(char *);
func = (int (*)(char*))134513676;
func("ls");
return 0;
}上述代码中的数值就是 system函数的绝对地址，在不同的环境中不一样，不过获取这个数值并不困难的。由此可见，依靠过滤源代码的方式几乎是行不通的安全性解决方案。如果不依赖检查源代码，就要监控程序的“行为”，这就需要比较复杂的调试器技术了。在Linux下，有一个ptrace函数，可以在程序运行时监测程序的行为，捕获接收到的信号。
解决方案
vakuum的执行器executor，就是用的ptrace的原理。主程序为两个进程，子进程用来执行用户程序，父进程用来监视子进程。子进程每进行系统调用的时候，运行就被中断，由父进程检查子进程的行为是否合法，如果不合法就杀掉子进程。对于open调用，还要检查用户打开的文件是否被允许。有了这个程序，监控程序的用户时间和内存也就不难了，用户时间的监测需要在每个系统调用后检查，对于内存，在任何一个与内存分配相关的系统调用后检查一下/proc/{pid}/statm即可。
如此还有一个问题容易被忽略，就是如果用户程序中长时间不进行系统调用，只是在做一些运算的时候，如何让程序暂停下来判断是否超时呢？设置CPU_Limit为时间限制显然是不行的，因为在监控下的用户程序可能会运行时间更久。不知道大家在用Cena的时候是否发现过一个现象，例如某个程序本来运行0.8秒，设为1秒时限以后显示超时，设为2秒时间反而显示成了0.8秒。这是怎么回事呢？很可能就是设定了不合适的CPU_Limit。稳妥的方法是设置为时间限制的若干倍，但是到底是几倍不好估计，而且很多时候还会浪费时间。思考问题的根源还在于长时间没有被暂停，我的解决方法是给父进程设置一个alarm，每秒向子进程发送一个信号，设置子进程接收到信号以后也会暂停，并检查时间是否超时。这样的话，超时的程序最多会在不超过时限1秒的情况下被终止。
在这种严密的监控下，很难找到突破的方法，至少我至今还没有想到如何攻破executor的监控。其代价就是降低执行效率了，不过由于我监视的是用户时间，用户程序不会被误判超时，尽管感觉实际执行时间多了不少。如果你有什么攻破监控想法，欢迎与我联系做安全性测试。
潜在的缺陷
虽然我并不了解，但是我还是担心，如果用户程序中有汇编代码嵌入，是否可以获得底层的权限。如果真的可以，我还没有想到应对的方法。