本科毕设OJ评测机设计：基于cgroups与seccomp的轻量级沙箱实现-育师

1. 为什么本科毕设选OJ评测机，而不是直接搭个网站？

“OJ”这个词在计算机专业学生嘴里出现的频率，大概和“毕设”“答辩”“查重”一样高频。但真正动手做过的人会发现，绝大多数同学一上来就扎进前端页面、用户登录、题目管理这些看得见摸得着的模块，结果做到一半卡在“代码提交后怎么知道对错”这个环节——不是测不出来，是测得不准、测得慢、测得不安全，甚至测着测着把服务器搞崩了。

我带过几届毕业设计，看过不下四十份OJ类毕设报告。其中超过七成的“评测失败”案例，根源不在数据库设计或界面交互，而在于评测机（Judge Server）这一环被严重低估。它不是后台一个简单的“跑一下代码”的脚本，而是整个系统最硬的骨头：既要隔离恶意代码，又要精确控制资源，还要在毫秒级响应中完成编译、执行、比对、计时、判分整套流程。很多同学用Python的subprocess.run()随便起个进程就开干，结果交上去的Demo在本地能跑，在实验室服务器上跑三分钟没反应，一查日志发现内存爆到8GB——这根本不是功能问题，是架构认知偏差。

评测机的本质，是一个受控沙箱环境下的自动化程序行为分析器。它要回答四个不可妥协的问题：

这段代码会不会无限循环？（时间维度的强制终止）
它最多能吃掉多少内存？（空间维度的硬性截断）
它能不能读写除标准输入输出外的任何文件？（文件系统维度的权限封锁）
它有没有调用危险系统调用，比如fork()开几千个子进程？（内核接口维度的系统调用过滤）

这些不是靠“加个try-except”或者“设置timeout参数”就能解决的。它们对应的是Linux内核的cgroups、seccomp-bpf、namespaces三大机制，是生产级容器技术的底层基石。本科毕设不需要你从零实现Docker，但必须理解这些机制如何被裁剪、组合、降级使用，才能让一个200行的评测核心模块真正扛住并发提交、代码注入、资源耗尽等真实压力。

所以，这篇不是教你怎么写个“能跑通Hello World”的评测脚本，而是带你拆解一个可交付、可演示、可写进毕设论文‘系统设计’章节的轻量级评测机。它不追求支撑万人并发，但必须满足：单机稳定处理50+并发提交；C/C++/Java/Python四语言支持；超时/超内存/编译错误/答案错误/运行时错误五类判题结果准确返回；全程无root权限运行；所有配置可写进config.yaml一键切换。这才是本科毕设该有的技术纵深感——不炫技，但每一步都踩在操作系统原理的实地上。

2. 评测机不是“执行代码”，而是构建可控的执行边界

很多同学第一次写评测逻辑，直觉就是：“我把用户代码保存成a.cpp，然后g++ a.cpp -o a && ./a < in.txt > out.txt，再比对out.txt和ans.txt”。这个思路本身没错，但漏掉了最关键的中间层：执行环境的定义权。你命令行里敲的./a，默认运行在你的用户账户下，拥有当前shell的所有权限——它可以读取/etc/shadow，可以rm -rf /tmp/*，可以fork()出5000个进程把CPU占满。这不是评测，这是邀请黑客来你的服务器上自由发挥。

真正的评测机，必须主动放弃“默认环境”，转而显式声明并强制实施一套最小权限契约。这个契约由三个层级构成，缺一不可：

2.1 进程级隔离：cgroups v1 的硬核资源围栏

Linux cgroups（Control Groups）是内核提供的资源分组管理机制。对本科毕设而言，v1版本足够用且更易理解。我们不需操作复杂的cgroup v2的hierarchy，只需聚焦cpu,memory,pids这三个子系统：

cpu子系统：通过cpu.cfs_quota_us和cpu.cfs_period_us控制CPU时间配额。例如设quota=100000, period=100000，即该进程组每100ms最多用100ms CPU时间——本质是100%利用率上限。若题目时限是1秒，这里就设quota=1000000，确保超时判定有冗余空间。
memory子系统：通过memory.limit_in_bytes硬性限制内存上限。注意不是memory.soft_limit_in_bytes（软限制，仅触发警告），必须是硬限制。设为128MB（134217728字节）是C/C++题目的安全起点，Java需提高到512MB以上（因JVM自身开销）。
pids子系统（Linux 4.5+）：通过pids.max限制进程/线程总数。设为50是合理值——正常程序不会创建50个线程，但while(1) fork();这种攻击会被立即掐断。

实操中，我们用cgcreate和cgexec命令链完成隔离。例如创建名为judge001的cgroup：

sudo cgcreate -g cpu,memory,pids:/judge001 sudo cgset -r cpu.cfs_quota_us=1000000 -r cpu.cfs_period_us=100000 /judge001 sudo cgset -r memory.limit_in_bytes=134217728 /judge001 sudo cgset -r pids.max=50 /judge001

之后所有评测进程都通过cgexec -g cpu,memory,pids:judge001 your_command启动。这步看似简单，却是整个评测安全的基石——没有它，后续所有防护都是纸糊的。

提示：cgcreate需要sudo权限，但评测机主进程不应以root运行。解决方案是提前用root创建好所有cgroup目录，并将/sys/fs/cgroup/cpu/judge*/等路径的组权限设为judgeuser:judgegroup，让评测进程以普通用户judgeuser身份操作。这是生产环境的标准做法，毕设中写进“权限设计”章节非常加分。

2.2 系统调用过滤：seccomp-bpf 的精准手术刀

cgroups管住了资源，但管不住“行为”。一个恶意程序仍可调用open("/etc/passwd", O_RDONLY)读取密码文件，或调用socket()发起网络连接。这时就需要seccomp（secure computing mode）——Linux内核提供的系统调用过滤机制。

seccomp有三种模式，本科毕设适用的是seccomp-bpf：用BPF（Berkeley Packet Filter）字节码编写规则，内核在每次系统调用前执行该字节码，决定是放行、拒绝还是杀掉进程。我们不需要手写BPF汇编，可用libseccomp库或更轻量的seccomp-tools生成规则。

核心原则是：白名单制，只放行评测必需的系统调用。对C/C++程序，必需调用约20个，包括：

文件I/O：read,write,openat,close,lseek
进程控制：exit_group,brk,mmap,mprotect,munmap
时间：clock_gettime,gettimeofday
其他：getpid,getppid,getuid,getgid,uname

而必须禁止的高危调用包括：

open,openat（除非限定路径前缀，如只允许/proc/self/fd/）
socket,connect,bind,listen,accept
fork,clone,vfork,execve（防止逃逸）
ptrace,kill（防止调试或攻击其他进程）

一个典型的安全配置是：允许openat，但要求其第二个参数flags必须包含O_RDONLY且第三个参数mode为0，同时路径字符串必须以/proc/self/fd/开头（确保只能打开标准流）。这需要BPF规则做多条件判断，但libseccomp的高级API（如scmp_filter_ctx）已封装好。

注意：Java和Python解释器本身会调用大量系统调用（如mmap申请堆内存、futex做线程同步）。直接对java或python3进程加严苛seccomp会直接崩溃。正确做法是：对编译型语言（C/C++）的可执行文件加严格规则；对解释型语言，只对解释器进程加基础规则（允许read/write/openat/exit等），并将用户代码作为数据传入，信任解释器自身的沙箱能力（如Java SecurityManager，虽已废弃但原理可借鉴）。

2.3 文件系统视图：chroot 与 bind mount 的轻量替代方案

chroot曾是传统沙箱首选，但现代Linux中它已不安全（可通过mknod+mount逃逸）。本科毕设应采用更可靠的mount --bind方案：将一个干净的空目录（如/var/judge/sandbox/001）作为根目录，然后只挂载评测必需的路径：

/proc→ 只读绑定，供/proc/self/status等获取进程信息
/dev/null,/dev/zero,/dev/tty→ 必需设备节点
/tmp→ 绑定到独立临时目录，避免污染主机
用户代码、输入文件、输出文件 → 绑定到sandbox内指定路径（如/in,/out,/code）

关键点在于：所有绑定都使用--bind --ro（只读）或--bind --rprivate（私有挂载，防止传播）。例如：

# 创建干净sandbox目录 mkdir -p /var/judge/sandbox/001/{code,in,out,tmp} # 只读挂载proc sudo mount --bind --ro /proc /var/judge/sandbox/001/proc # 挂载tmp为独立目录 sudo mount --bind /var/judge/tmp/001 /var/judge/sandbox/001/tmp # 挂载用户文件（只读代码，读写输出） sudo mount --bind /var/judge/submissions/123/code.c /var/judge/sandbox/001/code.c sudo mount --bind /var/judge/testcases/1001/in.txt /var/judge/sandbox/001/in sudo mount --bind /var/judge/sandbox/001/out /var/judge/sandbox/001/out

最后用unshare --user --pid --mount --fork --root=/var/judge/sandbox/001 chroot / sh -c "your_command"进入隔离环境。unshare创建新的命名空间，chroot切换根目录，双重保险。

这三层机制（cgroups + seccomp + namespace）共同构成了评测机的“铁三角”。它们不是可选项，而是必选项。毕设答辩时，老师问“如何保证用户代码不破坏服务器”，你能清晰说出这三层各自的作用和协同逻辑，远比展示一个花哨的前端界面更有说服力。

3. 语言支持不是“装几个编译器”，而是设计统一的评测流水线

支持C/C++/Java/Python四种语言，绝不是在服务器上apt install gcc openjdk-11-jdk python3就完事。每种语言的“评测路径”差异巨大，必须抽象出一条标准化的流水线，让不同语言的处理逻辑能插入同一框架。这条流水线的核心是五个阶段：准备（Prepare）→ 编译（Compile）→ 执行（Execute）→ 判定（Judge）→ 清理（Cleanup）。每个阶段接收标准化输入（代码路径、输入文件、时限、内存限），输出标准化结果（状态码、执行时间、内存峰值、输出内容）。

3.1 C/C++：最“干净”也最易翻车的语言

C/C++的优势是编译后为原生二进制，无运行时依赖。但劣势同样明显：编译错误信息杂乱、链接选项易出错、静态链接需额外处理。

编译阶段：必须使用-static静态链接（gcc -static -o a a.c），避免动态库缺失。同时添加-Wall -Wextra -O2开启警告和优化，但禁用-fPIE -pie（位置无关可执行文件），因其可能干扰seccomp规则。
执行阶段：直接运行二进制。关键参数是ulimit -t $TIME_LIMIT -v $MEMORY_LIMIT，但注意ulimit只是shell层面的软限制，必须配合cgroups硬限制才可靠。
判题难点：Segmentation Fault（SIGSEGV）和Floating Point Exception（SIGFPE）需捕获为“运行时错误”，而非“答案错误”。这要求评测进程用waitpid()获取子进程退出状态，解析WIFSIGNALED(status)和WTERMSIG(status)。

一个易忽略的坑：C++标准库（如std::string）在低内存下可能抛出std::bad_alloc，这属于运行时错误，但程序会正常退出（exit code 0），而非信号终止。因此判题不能只看信号，必须结合/proc/[pid]/status中的VmPeak（峰值内存）和/proc/[pid]/stat中的utime+stime（用户+系统CPU时间）进行综合判定。

3.2 Java：JVM是把双刃剑

Java的评测核心在于控制JVM自身开销。java -Xmx128m Main只限制了堆内存，但JVM元空间（Metaspace）、线程栈、直接内存（Direct Buffer）均不受控，极易超限。

编译阶段：javac -encoding UTF-8 Main.java，编码必须显式指定，否则中文注释会导致编译失败。
执行阶段：必须使用-XX:+UseSerialGC（串行垃圾回收器）避免多线程GC干扰计时；-Xss256k限制线程栈大小；-XX:MaxDirectMemorySize=16m限制直接内存；最关键的是-XX:+ExitOnOutOfMemoryError，确保OOM时JVM立即退出，而非抛异常后继续运行。
判题陷阱：Java程序System.exit(0)是合法退出，但System.exit(1)会被判为“运行时错误”。然而，某些OJ要求System.exit(1)表示“答案错误”，这就需要评测机解析System.exit()的参数并映射为对应判题结果。毕设中建议统一约定：System.exit(0)为AC，非0为WA，由JVM自身异常（如NullPointerException）导致的退出为RE。

3.3 Python：解释器即沙箱，但需加固

Python解释器天然具备一定沙箱能力（如无法直接调用fork），但os.system(),subprocess.Popen()仍可执行任意命令，必须通过seccomp严格限制。

执行阶段：直接python3 main.py < in.txt > out.txt。无需编译，但需注意Python版本兼容性（如print("hello", end="")在2.x和3.x行为不同），毕设中固定为python3.8。
加固要点：seccomp规则必须禁止execve，并限制openat路径。同时，可在执行前向Python注入一段预加载脚本，重写os.system等危险函数：
```
import os os.system = lambda *args: __import__('sys').exit(114) # 自定义错误码
```
这种“运行时加固”比纯内核级防护更灵活，适合毕设快速验证。
性能考量：Python启动慢，频繁fork新进程开销大。优化方案是用multiprocessing.Pool预启一个Python进程池，评测任务以RPC方式分发，但本科毕设不必实现，了解即可。

3.4 流水线统一接口：用JSON定义一切

为让四种语言无缝接入，定义一个task.json描述评测任务：

{ "language": "cpp", "code_path": "/var/judge/submissions/123/main.cpp", "input_path": "/var/judge/testcases/1001/in.txt", "output_path": "/var/judge/testcases/1001/out.txt", "time_limit_ms": 1000, "memory_limit_kb": 131072, "stack_limit_kb": 8192, "case_id": 1001 }

评测机主程序读取此文件，根据language字段选择对应处理器（CppHandler,JavaHandler等），所有处理器实现同一接口：

class JudgeHandler: def prepare(self, task: dict) -> bool: ... def compile(self, task: dict) -> (bool, str): ... # (success, message) def execute(self, task: dict) -> dict: # 返回{status, time_ms, mem_kb, output} def judge(self, task: dict, result: dict) -> str: # 返回"AC"/"WA"/"TLE"/"MLE"/"RE" def cleanup(self, task: dict) -> None: ...

这种面向接口的设计，让新增语言（如Go、Rust）只需实现一个新Handler类，主框架完全不用改。毕设论文的“系统架构图”中，画出这个统一接口，比罗列一堆技术名词更有架构感。

4. 判题结果不是“对错”，而是五维状态空间的精确映射

很多同学认为判题就是if output == expected: print("AC") else: print("WA")。这在理想世界成立，但现实中的评测结果是一个五维状态空间：时间（Time）、内存（Memory）、信号（Signal）、退出码（Exit Code）、输出内容（Output）。任何一个维度越界，都对应不同错误类型，且优先级有严格顺序。

4.1 五类结果的判定逻辑与优先级树

判题结果不是线性判断，而是树状决策。最高优先级永远是资源超限，因为它是系统安全的红线：

是否超时？ (TLE) ├─ 是 → 判定为"TLE"，结束 └─ 否 → 是否超内存？ (MLE) ├─ 是 → 判定为"MLE"，结束 └─ 否 → 进程是否异常终止？ (RE) ├─ 是 → 根据信号类型判定： │ ├─ SIGSEGV/SIGBUS → "RE" │ ├─ SIGFPE → "RE" │ ├─ SIGKILL (被cgroups杀死) → "MLE" 或 "TLE" (需回溯原因) │ └─ 其他 → "RE" └─ 否 → 进程是否正常退出？ ├─ 否 → "RE" (未捕获的异常退出) └─ 是 → 退出码是否为0？ ├─ 否 → "RE" (如Java的System.exit(1)) └─ 是 → 输出内容是否匹配？ ├─ 是 → "AC" └─ 否 → "WA"

这个树必须严格实现。常见错误是：先比对输出，发现不匹配就判"WA"，却忽略了该进程其实用了1200ms（超时）或占了150MB内存（超限）。这会导致“假WA”，在答辩时被老师指出就是硬伤。

4.2 输出比对：不只是字符串相等

“答案错误”（WA）的判定，远比str1 == str2复杂。必须处理以下场景：

空白符敏感性：OJ题目常要求“行末不能有多余空格”，但用户输出可能有。比对前需对两文件做rstrip()（去除行尾空白）和splitlines()（按行分割），再逐行比较。
浮点数精度：当答案是浮点数时，绝对误差（abs(a-b) < 1e-6）或相对误差（abs(a-b)/max(abs(a),abs(b)) < 1e-6）需可配置。毕设中可固定为绝对误差1e-6。
特殊格式：如“输出任意一种方案”，则需编写校验器（checker）程序，而非简单比对。例如图论题输出路径，校验器需验证路径是否连通、长度是否正确。本科毕设可暂不实现checker，但论文中要说明“预留checker接口，支持未来扩展”。
多解接受：某些题目允许多个正确答案（如排序算法输出任意一种有序序列）。此时需提供标准答案生成器（generator），对用户输出调用同一生成器验证。毕设中可用Python脚本模拟，体现设计前瞻性。

4.3 状态采集：从/proc文件系统挖取黄金数据

所有判题维度的数据，都来自Linux的/proc/[pid]/虚拟文件系统。这是评测机最核心的“传感器”：

执行时间：/proc/[pid]/stat的第14、15字段（utime,stime），单位为clock tick（通常100Hz），需换算为毫秒：(utime + stime) * 1000 / sysconf(_SC_CLK_TCK)。
峰值内存：/proc/[pid]/status的VmPeak:行，单位为KB。注意不是VmRSS（当前驻留集），而是VmPeak（历史峰值），这才是内存限制的依据。
进程状态：/proc/[pid]/stat的第3字段（state），R为运行，S为睡眠，Z为僵尸。若进程已退出，waitpid()返回的状态码才是最终依据。
打开文件数：/proc/[pid]/fd/目录下的文件数，可防ulimit -n耗尽。

这些数据必须在进程退出后立即读取，因为/proc/[pid]/在进程消亡后即消失。评测机需在waitpid()返回后，用os.readlink(f"/proc/{pid}/exe")确认进程身份，再读取对应/proc/[pid]/路径。这是保障数据准确性的唯一方式。

实操心得：初版评测机我曾用ps命令查内存，结果发现ps的采样有延迟，导致TLE误判为WA。后来全部切到/proc实时读取，误判率归零。这个细节值得写进毕设的“测试与优化”章节。

5. 毕设落地：从单机脚本到可演示系统的工程化包装

一个能写进毕设论文的评测机，不能只是一个judge.py脚本。它必须具备可安装、可配置、可监控、可演示的工程属性。以下是本科毕设级别最务实的包装方案：

5.1 目录结构与配置驱动

摒弃硬编码，用config.yaml统一管理所有可变参数：

# config.yaml judge: sandbox_root: "/var/judge/sandbox" tmp_root: "/var/judge/tmp" submissions_root: "/var/judge/submissions" testcases_root: "/var/judge/testcases" log_level: "INFO" max_concurrent: 10 # 最大并发评测数 languages: cpp: compiler: "g++" compile_flags: ["-static", "-O2", "-Wall", "-Wextra"] exec_timeout_ms: 2000 java: jdk_home: "/usr/lib/jvm/java-11-openjdk-amd64" heap_size_mb: 128 python: interpreter: "python3.8" security: cgroup_name: "judge" seccomp_policy: "default.bpf" unshare_flags: ["--user", "--pid", "--mount", "--fork"]

评测机启动时加载此配置，所有路径、参数、策略均从此读取。答辩时老师问“如何修改内存限制”，你只需打开config.yaml指向对应行，比解释一百行代码更直观。

5.2 日志与监控：让“看不见”的过程可视化

评测过程涉及多个异步环节（cgroup创建、seccomp加载、进程fork、/proc读取），必须用结构化日志记录每一步。推荐使用Python的structlog库，输出JSON日志：

{"event": "task_start", "task_id": "123", "language": "cpp", "timestamp": "2023-10-05T14:22:31.123Z"} {"event": "cgroup_created", "cgroup_path": "/sys/fs/cgroup/cpu/judge/123", "timestamp": "..."} {"event": "process_exited", "pid": 12345, "exit_code": 0, "signal": 0, "time_ms": 45.2, "mem_kb": 2560, "timestamp": "..."}

这些日志可被journalctl收集，也可用tail -f /var/log/judge.log | jq '.'实时查看。毕设演示时，打开一个终端滚动显示日志，比静态截图更有说服力。

5.3 健康检查与自愈：让系统“活”起来

一个健壮的评测机应具备基础自检能力。在启动时执行：

检查cgroups子系统是否挂载（mount | grep cgroup）
检查/proc/sys/kernel/seccomp_mode是否启用
尝试创建一个测试cgroup并运行sleep 1
验证各语言编译器/解释器是否存在且可执行

若任一检查失败，打印清晰错误并退出，而非静默崩溃。更进一步，可实现“自动清理”：评测进程异常退出后，自动扫描/var/judge/sandbox/下残留目录并umount、rmdir。这体现了工程化思维，远超“功能实现”的层面。

5.4 演示设计：五分钟讲清技术亮点

毕设答辩只有10-15分钟，评测机部分建议这样组织演示：

第一分钟：展示config.yaml，说明“所有参数可配置，无需改代码”。
第二分钟：运行一个故意超时的C程序（while(1);），终端实时显示日志中cgroup_created→process_killed_by_cgroup→TLE的完整链路。
第三分钟：运行一个Java内存溢出程序，展示/proc/[pid]/status中VmPeak如何从128MB飙升到135MB，触发MLE。
第四分钟：对比两个Python输出（一个有行尾空格，一个没有），展示rstrip()比对如何正确判为AC。
第五分钟：打开judge.py源码，指向JudgeHandler接口定义，说明“新增语言只需实现5个方法，框架不变”。