ClusterFuzz Bot 临时测试用例目录 fuzzer-testcases：占位目录设计与 tmpfs 内存化实践

测试应用安全后端【免费下载链接】clusterfuzzScalable fuzzing infrastructure.项目地址https://gitcode.com/gh_mirrors/clu/clusterfuzz点击查看免费下载导读在 ClusterFuzz 的 bot 文件系统布局中bot/inputs/fuzzer-testcases/是一个专门存放模糊测试fuzzing任务运行期间所生成测试用例testcase的临时工作目录。本文以 fuzzer-testcases/README.md 为主线深入讲解该目录的两大设计要点任务结束后自动清空的占位目录语义以及通过 tmpfs 挂载将高频读写文件驻留内存、以换取更高性能和更低磁盘成本的优化手段。读完本文你将掌握该目录在 ClusterFuzz 环境变量体系FUZZ_INPUTS/FUZZ_INPUTS_DISK中的位置、它与磁盘版测试用例目录的分工逻辑以及生产环境中完整的 tmpfs 挂载配置方式。一、占位目录fuzzer 生成测试用例的临时工作区bot/inputs/fuzzer-testcases/README.md用一句话定义了该目录的本质Placeholder for testcases generated by a fuzzer. This gets cleared after a task is finished.即它是由 fuzzer 生成的测试用例的占位目录placeholder且生命周期严格受限——一个任务task结束后目录内容会被清空。这意味着该目录不是持久化存储而是 bot 在单次模糊测试任务运行期间的临时工作区fuzzer 在内存或磁盘中产出新输入测试用例经复现、分析、归档之后临时文件即失去价值并被回收。从源码结构看这一临时工作区 任务结束即清理的语义在 bot 任务执行体系中是普遍约定fuzz_task.py 在启动模糊测试任务时将self.testcase_directory直接指向FUZZ_INPUTS即本目录后续 fuzzer 产出的所有测试用例都落在这里corpus_pruning_task.py 在语料剪枝corpus pruning任务中会把已上传测试用例的absolute_path属性指向FUZZ_INPUTS下的testcase文件而不是本地隔离quarantine目录以保证后续处理路径一致各任务运行完毕、进入下一轮任务前系统会统一清空测试用例目录详见下文第三节。因此任何部署者都不应把重要数据放入该目录也不应在任务之间假定目录内容仍然存在。二、环境变量映射FUZZ_INPUTS 与 bot 目录布局该目录在代码中通过环境变量FUZZ_INPUTS被引用。ClusterFuzz 在 bot 启动时统一初始化一套输入目录布局相关逻辑位于 environment.py 的set_bot_environment()inputs_dir os.path.join(bot_dir, inputs) os.environ[INPUT_DIR] inputs_dir os.environ[CRASH_STACKTRACES_DIR] os.path.join(inputs_dir, crash-stacks) os.environ[FUZZERS_DIR] os.path.join(inputs_dir, fuzzers) os.environ[DATA_BUNDLES_DIR] os.path.join(inputs_dir, data-bundles) os.environ[FUZZ_INPUTS] os.path.join(inputs_dir, fuzzer-testcases) os.environ[FUZZ_INPUTS_MEMORY] os.environ[FUZZ_INPUTS] os.environ[FUZZ_INPUTS_DISK] os.path.join(inputs_dir, disk) os.environ[FUZZ_DATA] os.path.join(inputs_dir, fuzzer-common-data-bundles) os.environ[IMAGES_DIR] os.path.join(inputs_dir, images) os.environ[SYMBOLS_DIR] os.path.join(inputs_dir, symbols) os.environ[USER_PROFILE_ROOT_DIR] os.path.join(inputs_dir, user-profile-dirs)要点归纳如下环境变量对应目录相对 bot 根目录用途FUZZ_INPUTSbot/inputs/fuzzer-testcases内存版测试用例目录本文主题FUZZ_INPUTS_MEMORY与FUZZ_INPUTS相同显式别名强调其内存驻留属性FUZZ_INPUTS_DISKbot/inputs/disk磁盘版测试用例目录用于放不下内存的大文件其中FUZZ_INPUTS_MEMORY与FUZZ_INPUTS被设置为同一路径这种双名一址的写法在语义上明确区分了内存目录与磁盘目录方便代码在引用时表达意图。磁盘版目录bot/inputs/disk的说明见 disk/README.md其中同样声明任务结束后会被清空并补充说明它是始终位于磁盘上、用于存放无法放入内存的大测试用例的目录。三、tmpfs 内存化性能与磁盘成本的双重优化fuzzer-testcases/README.md的第二段给出了该目录最关键的部署建议For better performance and lower disk usage costs, this directory can be mounted as tmpfs and reside in memory.fuzzing 任务对测试用例目录的读写极为频繁每个新变异输入都要写入、复现时还要反复读取如果这些 I/O 都落盘既拖慢任务速度又会持续磨损/占用磁盘空间。将目录挂载为 tmpfs 后文件内容直接驻留内存读写不再经过磁盘同时 tmpfs 本身不占用持久化存储空间从而同时优化了性能和磁盘成本。3.1 生产环境中的挂载实现ClusterFuzz 的官方 Docker 基镜像启动脚本 setup_clusterfuzz.sh 给出了完整的落地方案。脚本在DISABLE_MOUNTS环境变量未设置时执行一组挂载# Some configurations (e.g. hosts) run many instances of ClusterFuzz. Dont # set up mounts in this case. if [[ -z $DISABLE_MOUNTS ]]; then # Setup Tmpfs dirs for frequently accessed files to save disk I/O. mount -t tmpfs -o size250M,mode777 tmpfs $INSTALL_DIRECTORY/clusterfuzz/bot/inputs/fuzzer-testcases/ mount -t tmpfs -o size10M,mode777 tmpfs $INSTALL_DIRECTORY/clusterfuzz/bot/logs/ mount -t tmpfs -o size90M,mode777 tmpfs $BOT_TMPDIR # Setup mount to limit disk space for fuzzer testcases disk directory. FUZZER_TESTCASES_DISK_FILE$INSTALL_DIRECTORY/fuzzer-testcases.mnt fallocate -l 8GiB $FUZZER_TESTCASES_DISK_FILE mkfs.ext4 -F $FUZZER_TESTCASES_DISK_FILE # mkfs.ext4 seems to remove the previous allocation, so do it again. fallocate -l 8GiB $FUZZER_TESTCASES_DISK_FILE mount -o loop $FUZZER_TESTCASES_DISK_FILE $INSTALL_DIRECTORY/clusterfuzz/bot/inputs/disk fi其中与本文主题直接相关的关键参数挂载点$INSTALL_DIRECTORY/clusterfuzz/bot/inputs/fuzzer-testcases/即 bot 安装目录下的对应路径文件系统类型tmpfs内容保存在内存及可能的 swap中size250M为该 tmpfs 设定 250 MiB 容量上限。这是有意的容量约束——fuzzer 产出的测试用例总量被限制在这个范围内避免无限增长耗尽内存mode777允许 bot 进程以任意用户身份在该目录下创建/读写文件适配 bot 以非特权用户运行的实际场景。与之一同挂载的还有bot/logs/10M和$BOT_TMPDIR90M三者共同构成高频临时数据放内存的优化策略。DISABLE_MOUNTS则用于某些特殊部署例如一台宿主机运行多个 ClusterFuzz 实例时关闭这些挂载避免每个实例都抢占内存。3.2 配套的磁盘目录与容量上限值得注意脚本同时创建了磁盘版目录bot/inputs/disk方式不是直接挂载磁盘而是先fallocate分配一个 8 GiB 的稀疏文件格式化为 ext4 后以 loop 设备挂载。这样做的目的是给 fuzzer 测试用例的磁盘目录设置硬性容量上限8 GiB防止失控的用例把宿主磁盘写满。由于mkfs.ext4会清除之前的分配脚本在格式化后再次fallocate补回文件大小。内存目录250M与磁盘目录8G的容量差异正是后续大测试用例走磁盘分流机制的物理基础。四、内存目录与磁盘目录的分工has_large_testcases 机制既然内存 tmpfs 只有 250M那些体积超过内存容量的测试用例例如大型语料库、超大输入文件显然不能写入fuzzer-testcases。ClusterFuzz 在 fuzzer 实体上提供了has_large_testcases标志位来显式声明这一点见 data_types.py# If this flag is set, fuzzer generates the testcase in the larger directory # on disk |FUZZ_INPUTS_DISK|, rather than smaller tmpfs one (FUZZ_INPUTS). has_large_testcases ndb.BooleanProperty(defaultFalse)该标志位在任务设置阶段被消费。在 setup.py 的 fuzzer/数据包更新逻辑中# If the fuzzer generates large testcases or a large number of small ones # that dont fit on tmpfs, then use the larger disk directory. if fuzzer.has_large_testcases: testcase_disk_directory environment.get_value(FUZZ_INPUTS_DISK) environment.set_value(FUZZ_INPUTS, testcase_disk_directory)即当 fuzzer 声明has_large_testcasesTrue时FUZZ_INPUTS会被临时改写为FUZZ_INPUTS_DISK磁盘目录从而让所有下游逻辑自动把测试用例写入磁盘而非内存。这与 unpack_task.py 中的注释互为印证# We cant use FUZZ_INPUTS directory since it is constrained # by tmpfs limits. testcases_directory environment.get_value(FUZZ_INPUTS_DISK)解包unpack任务需要把上传的测试用例压缩包解压到本地动辄数百 MB受 tmpfs 容量限制因此必须落到FUZZ_INPUTS_DISK。另一方面bot/inputs/disk/README.md还提到它是提供语料库corpus的 fuzzer 的默认目录——语料库通常体量大、可复用天然适合磁盘而非内存。五、任务结束后的清理clear_testcase_directoriesREADME 强调任务结束后目录被清空其实现位于 shell.py 的clear_testcase_directories()def clear_testcase_directories(): Clears the testcase directories. remove_directory(environment.get_value(FUZZ_INPUTS), recreateTrue) remove_directory(environment.get_value(FUZZ_INPUTS_DISK), recreateTrue) if environment.is_android(): from clusterfuzz._internal.platforms import android android.device.clear_testcase_directory() if environment.is_trusted_host(): from clusterfuzz._internal.bot.untrusted_runner import file_host file_host.clear_testcase_directories()该函数在每轮任务结束后被调用统一处理四类清理目标内存目录FUZZ_INPUTS删除全部内容并重新创建目录本身recreateTrue确保下一个任务拿到干净的目录磁盘目录FUZZ_INPUTS_DISK同样清空重建Android 设备目录若运行在 Android 平台上同步清理设备端的测试用例目录对应 device.py 中读取的FUZZ_INPUTS受信任宿主机trusted host在 untrusted runner 架构下还需通过file_host.clear_testcase_directories()清空 worker 侧对应目录相关集成测试见 untrusted_runner_integration_test.py。这一清空重建而非只删文件的做法保证了即使 tmpfs 挂载点或目录权限发生变化目录本身也始终以正确权限就位。六、更多使用场景从 NFS 减压到机器人专属用例除了作为 fuzzer 产出的临时落点FUZZ_INPUTS还被多个子系统复用体现了该目录高频读写、就近存放的设计价值避免 NFS 高负载utils.py 的get_bot_testcases_file_path()把bot 专属测试用例文件格式为.bot_name_testcases放在FUZZ_INPUTS下注释明确说明这是为了在input_directory是云存储数据包data bundle时避免把高频读写压力打到 NFS 服务器上。函数还做了降级处理本地测试local fuzzer testing时FUZZ_INPUTS可能未定义此时退回使用input_directory。HTTP 资源依赖的本地映射testcase_manager.py 在解析 Android 测试用例的远程依赖时会将设备目录DEVICE_TESTCASES_DIR替换为本地FUZZ_INPUTS确保file://依赖能解析到本机实际文件。测试用例路径解析setup.py 在解析 testcase 绝对路径时默认以FUZZ_INPUTS作为相对路径的基目录将相对路径拼接为完整路径。在 untrusted runner非可信执行架构中FUZZ_INPUTS还被用作 host 与 worker 之间文件 rebase 的基准目录参见 file_host.py。七、小结bot/inputs/fuzzer-testcases是 ClusterFuzz bot 上小而关键的临时目录作为 fuzzer 生成测试用例的占位目录它通过环境变量FUZZ_INPUTS贯穿任务执行、依赖解析与清理全流程通过 tmpfs 内存挂载250M 容量上限换来高频 I/O 的高性能与零磁盘占用通过与FUZZ_INPUTS_DISK8G loop 挂载的磁盘目录的has_large_testcases分流机制保证大用例不撑爆内存任务结束后由clear_testcase_directories()统一清空重建。理解这一目录的设计与配置是部署、调优 ClusterFuzz bot 存储与 I/O 行为的基础也是排查测试用例目录空间不足任务间数据残留等问题的第一现场。赞分享测试应用安全后端【免费下载链接】clusterfuzzScalable fuzzing infrastructure.项目地址https://gitcode.com/gh_mirrors/clu/clusterfuzz点击查看免费下载相关推荐pipreqs测试数据设计_data目录用例解析pipreqs测试数据设计_data目录用例解析 在Python项目开发中依赖管理是确保项目可移植性和稳定性的关键环节。pipreqs作为一款自动生成req开发工具CLIClusterFuzz Bot 日志体系完全指南bot/logs 目录日志文件的作用、配置与排查实践ClusterFuzz Bot 日志体系完全指南bot/logs 目录日志文件的作用、配置与排查实践 导读 ClusterFuzz 的可扩展模糊测试scal应用安全后端开发工具Pytest 测试隔离实战用 tmp_path 与 monkeypatch 探究临时目录结构Pytest 测试隔离实战用 tmp_path 与 monkeypatch 探究临时目录结构 在测试会读写文件系统的 CLI 程序时最怕的就是单个测试用例相文档教程知识库上一篇风扇全部消失时如何快速救回FanControl新手3步搞定Windows风扇控制排查指南下一篇致远OA A6 createMysql.jsp 未授权访问致数据库账户与密码哈希泄露漏洞深度解析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考