SerenityOS 移植 the_silver_searcher为 pledge 权限列表补充 thread 的补丁全解析【免费下载链接】serenityThe Serenity Operating System 项目地址: https://gitcode.com/GitHub_Trending/se/serenity本篇文章围绕 SerenityOS 移植 the_silver_searcher命令行代码搜索工具 ag过程中所需的一份关键补丁展开。该补丁的核心是在程序调用pledge()限制自身系统能力时把thread权限显式加入权限列表——原因在于 OpenBSD 的stdio通常已隐式授予thread而 SerenityOS 将thread作为独立权限项。读完本文你将理解这份补丁的动机、四处分歧点的具体改动以及 SerenityOS 内核侧pledge系统调用的实现原理与移植构建流程。补丁文档说了什么仓库中的 补丁说明文档 内容非常聚焦它只描述了一个补丁补丁文件0001-Add-the-thread-pledge-to-the-pledge-list.patch补丁标题Add the thread pledge to the pledge list向 pledge 权限列表中添加 thread 权限补丁动机文档原文On OpenBSD, stdio typically grants thread, but on Serenity it is its own option.这句话是整个补丁的灵魂在 OpenBSD 的 pledge 语义里stdio权限会顺带赋予进程创建线程thread的能力而 SerenityOS 对权限的划分更细stdio与thread是两个完全独立的权限位。因此 the_silver_searcher 这份原本面向 OpenBSD 的pledge调用在 SerenityOS 上运行时会因缺少显式的thread权限而导致线程相关系统调用被拒绝必须打上这个补丁才能正常发挥多线程并行搜索能力。补丁的四处分歧点详解该补丁由作者 Raymond Lucke 提交共修改了上游源码中的两个文件、四处pledge()调用统计为 4 行新增、4 行删除4 insertions(), 4 deletions(-)。所有改动模式一致在原有权限字符串中追加thread。1.src/main.c主函数入口的初始权限补丁将主函数main()一开始的权限声明从pledge(stdio rpath proc exec, NULL)改为pledge(stdio rpath proc exec thread, NULL)这是进程最早一次声明能力边界涵盖标准 I/O、文件路径读取rpath、进程管理proc、执行子进程exec以及线程创建thread。从补丁上下文可以看到main()中声明了int num_cores;从源码结构看ag 会按 CPU 核心数并行调度搜索任务这正是需要thread权限的直接原因。2.src/main.c扫描开始前的权限收紧在完成初始化、即将进入实际搜索阶段时ag 再次调用pledge()将权限从上面的宽集合收紧为pledge(stdio rpath thread, NULL)注意这里去掉了proc与exec——搜索阶段不再需要派生子进程这是典型的最小权限实践先以较宽权限完成启动再在不需要时立即放弃多余权限降低被攻破后的影响面。3.src/options.c--skip-vcs-ignores分支parse_options()中当用户指定skip_vcs_ignores跳过.gitignore等版本控制忽略文件此时需自行递归读取文件系统时权限从pledge(stdio rpath proc, NULL)改为pledge(stdio rpath proc thread, NULL)4.src/options.c选项解析完成后的兜底调用在parse_options()末尾无论是否跳过 VCS 忽略规则都会执行最后一次权限设置同样从stdio rpath proc追加为pledge(stdio rpath proc thread, NULL)为什么必须是 threadSerenityOS 的 pledge 实现要理解这个补丁需要看 SerenityOS 内核如何实现pledge。核心实现位于 Kernel/Syscalls/pledge.cpp系统调用入口为Process::sys$pledge()它接收两个字符串参数promises立即生效的权限与execpromisesexec 新程序后生效的权限。权限字符串的解析逻辑在 pledge.cpp 中内核按空格拆分字符串将每一段与ENUMERATE_PLEDGE_PROMISES枚举出的权限名逐一比对命中则置位对应的权限掩码位若出现任何无法识别的权限名整个调用返回EINVAL。因此补丁中追加的thread必须与内核枚举中的名字完全一致否则会导致pledge失败并触发die(pledge: %s, strerror(errno))。SerenityOS 内核对权限的完整清单定义在 Kernel/Tasks/Process.h 的ENUMERATE_PLEDGE_PROMISES宏中一共 25 项其中thread位于列表中部紧跟在chown之后stdio、rpath、proc、exec均在列。这从内核源码层面印证了文档的说法在 SerenityOS 上thread是一个独立权限位不会由stdio隐式授予。此外pledge.cpp 还展示了一个值得注意的细节权限一旦设置后续调用只能收缩、不能扩张——若新权限超出已有权限集除非声明了no_error否则返回EPERM。这意味着补丁必须把thread写进每一次包括最初的宽权限调用pledge 中否则进程会在中途失去创建线程的能力。这也是为什么这份补丁需要同时修改四处调用点而不是只改第一处。移植构建配置port 是如何被打包的这份补丁所属的移植位于 Ports/thesilversearcher/目录结构只有两个文件package.sh与patches/。其中 package.sh 定义了移植的构建方式portthesilversearcher版本2.2.0构建方式useconfiguretrue即采用 autoconf 式的 configure make 流程源码从上游官方发布渠道下载the_silver_searcher-2.2.0.tar.gz并以 SHA 值校验完整性工作目录解压后为the_silver_searcher-2.2.0依赖pcre正则表达式引擎与xzLZMA 压缩解码支持编译标志export CFLAGS-fcommon -D_GNU_SOURCE -lpthread。值得留意的是-lpthread它保证链接阶段正确引入 POSIX 线程库与补丁中显式声明thread权限形成呼应——运行期需要线程能力构建期同样需要线程库支持两者缺一不可。SerenityOS 的 Ports 机制会在构建时自动应用patches/目录下的全部补丁patch 采用标准git format-patch格式包含From、Date、Subject头部并带diff --git变更块构建系统据此将改动打到解压后的源码树上随后执行 configure 与 make 完成编译安装。移植工作流参考若你想在本地复现或验证这个移植可以遵循 SerenityOS 通用的 Ports 构建流程详见 Ports/README.md 与 BuildInstructions.md准备 SerenityOS 工具链与构建环境进入Ports/目录对目标移植执行构建脚本例如cd Ports/thesilversearcher ./package.sh构建系统会依次完成下载源码 → 校验 → 应用patches/0001-Add-the-thread-pledge-to-the-pledge-list.patch→ configure → make → 安装在 SerenityOS 系统中执行ag即可体验多线程并行代码搜索。若在运行中观察到pledge: ...类报错可从两个方向排查一是确认 patches 已正确应用对比补丁中四处pledge调用是否已带thread二是确认当前 SerenityOS 内核版本中的Pledge枚举Kernel/Tasks/Process.h仍包含thread项。小结这份看似只有 4 行改动的补丁背后串联起 SerenityOS 的安全设计与移植工程的完整链条上游 OpenBSD 的 pledge 语义与 SerenityOS 的权限粒度差异stdio是否隐含thread决定了必须在所有权限声明点显式追加thread内核侧 pledge.cpp 的权限只减不增校验决定了四处调用必须同步修改而 package.sh 中的-lpthread则从构建层面保证了线程能力的完整落地。理解这一补丁也就理解了 SerenityOS 移植第三方软件时处理平台安全 API 差异的典型范式。【免费下载链接】serenityThe Serenity Operating System 项目地址: https://gitcode.com/GitHub_Trending/se/serenity创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
SerenityOS 移植 the_silver_searcher为 pledge 权限列表补充 thread 的补丁全解析【免费下载链接】serenityThe Serenity Operating System 项目地址: https://gitcode.com/GitHub_Trending/se/serenity本篇文章围绕 SerenityOS 移植 the_silver_searcher命令行代码搜索工具 ag过程中所需的一份关键补丁展开。该补丁的核心是在程序调用pledge()限制自身系统能力时把thread权限显式加入权限列表——原因在于 OpenBSD 的stdio通常已隐式授予thread而 SerenityOS 将thread作为独立权限项。读完本文你将理解这份补丁的动机、四处分歧点的具体改动以及 SerenityOS 内核侧pledge系统调用的实现原理与移植构建流程。补丁文档说了什么仓库中的 补丁说明文档 内容非常聚焦它只描述了一个补丁补丁文件0001-Add-the-thread-pledge-to-the-pledge-list.patch补丁标题Add the thread pledge to the pledge list向 pledge 权限列表中添加 thread 权限补丁动机文档原文On OpenBSD, stdio typically grants thread, but on Serenity it is its own option.这句话是整个补丁的灵魂在 OpenBSD 的 pledge 语义里stdio权限会顺带赋予进程创建线程thread的能力而 SerenityOS 对权限的划分更细stdio与thread是两个完全独立的权限位。因此 the_silver_searcher 这份原本面向 OpenBSD 的pledge调用在 SerenityOS 上运行时会因缺少显式的thread权限而导致线程相关系统调用被拒绝必须打上这个补丁才能正常发挥多线程并行搜索能力。补丁的四处分歧点详解该补丁由作者 Raymond Lucke 提交共修改了上游源码中的两个文件、四处pledge()调用统计为 4 行新增、4 行删除4 insertions(), 4 deletions(-)。所有改动模式一致在原有权限字符串中追加thread。1.src/main.c主函数入口的初始权限补丁将主函数main()一开始的权限声明从pledge(stdio rpath proc exec, NULL)改为pledge(stdio rpath proc exec thread, NULL)这是进程最早一次声明能力边界涵盖标准 I/O、文件路径读取rpath、进程管理proc、执行子进程exec以及线程创建thread。从补丁上下文可以看到main()中声明了int num_cores;从源码结构看ag 会按 CPU 核心数并行调度搜索任务这正是需要thread权限的直接原因。2.src/main.c扫描开始前的权限收紧在完成初始化、即将进入实际搜索阶段时ag 再次调用pledge()将权限从上面的宽集合收紧为pledge(stdio rpath thread, NULL)注意这里去掉了proc与exec——搜索阶段不再需要派生子进程这是典型的最小权限实践先以较宽权限完成启动再在不需要时立即放弃多余权限降低被攻破后的影响面。3.src/options.c--skip-vcs-ignores分支parse_options()中当用户指定skip_vcs_ignores跳过.gitignore等版本控制忽略文件此时需自行递归读取文件系统时权限从pledge(stdio rpath proc, NULL)改为pledge(stdio rpath proc thread, NULL)4.src/options.c选项解析完成后的兜底调用在parse_options()末尾无论是否跳过 VCS 忽略规则都会执行最后一次权限设置同样从stdio rpath proc追加为pledge(stdio rpath proc thread, NULL)为什么必须是 threadSerenityOS 的 pledge 实现要理解这个补丁需要看 SerenityOS 内核如何实现pledge。核心实现位于 Kernel/Syscalls/pledge.cpp系统调用入口为Process::sys$pledge()它接收两个字符串参数promises立即生效的权限与execpromisesexec 新程序后生效的权限。权限字符串的解析逻辑在 pledge.cpp 中内核按空格拆分字符串将每一段与ENUMERATE_PLEDGE_PROMISES枚举出的权限名逐一比对命中则置位对应的权限掩码位若出现任何无法识别的权限名整个调用返回EINVAL。因此补丁中追加的thread必须与内核枚举中的名字完全一致否则会导致pledge失败并触发die(pledge: %s, strerror(errno))。SerenityOS 内核对权限的完整清单定义在 Kernel/Tasks/Process.h 的ENUMERATE_PLEDGE_PROMISES宏中一共 25 项其中thread位于列表中部紧跟在chown之后stdio、rpath、proc、exec均在列。这从内核源码层面印证了文档的说法在 SerenityOS 上thread是一个独立权限位不会由stdio隐式授予。此外pledge.cpp 还展示了一个值得注意的细节权限一旦设置后续调用只能收缩、不能扩张——若新权限超出已有权限集除非声明了no_error否则返回EPERM。这意味着补丁必须把thread写进每一次包括最初的宽权限调用pledge 中否则进程会在中途失去创建线程的能力。这也是为什么这份补丁需要同时修改四处调用点而不是只改第一处。移植构建配置port 是如何被打包的这份补丁所属的移植位于 Ports/thesilversearcher/目录结构只有两个文件package.sh与patches/。其中 package.sh 定义了移植的构建方式portthesilversearcher版本2.2.0构建方式useconfiguretrue即采用 autoconf 式的 configure make 流程源码从上游官方发布渠道下载the_silver_searcher-2.2.0.tar.gz并以 SHA 值校验完整性工作目录解压后为the_silver_searcher-2.2.0依赖pcre正则表达式引擎与xzLZMA 压缩解码支持编译标志export CFLAGS-fcommon -D_GNU_SOURCE -lpthread。值得留意的是-lpthread它保证链接阶段正确引入 POSIX 线程库与补丁中显式声明thread权限形成呼应——运行期需要线程能力构建期同样需要线程库支持两者缺一不可。SerenityOS 的 Ports 机制会在构建时自动应用patches/目录下的全部补丁patch 采用标准git format-patch格式包含From、Date、Subject头部并带diff --git变更块构建系统据此将改动打到解压后的源码树上随后执行 configure 与 make 完成编译安装。移植工作流参考若你想在本地复现或验证这个移植可以遵循 SerenityOS 通用的 Ports 构建流程详见 Ports/README.md 与 BuildInstructions.md准备 SerenityOS 工具链与构建环境进入Ports/目录对目标移植执行构建脚本例如cd Ports/thesilversearcher ./package.sh构建系统会依次完成下载源码 → 校验 → 应用patches/0001-Add-the-thread-pledge-to-the-pledge-list.patch→ configure → make → 安装在 SerenityOS 系统中执行ag即可体验多线程并行代码搜索。若在运行中观察到pledge: ...类报错可从两个方向排查一是确认 patches 已正确应用对比补丁中四处pledge调用是否已带thread二是确认当前 SerenityOS 内核版本中的Pledge枚举Kernel/Tasks/Process.h仍包含thread项。小结这份看似只有 4 行改动的补丁背后串联起 SerenityOS 的安全设计与移植工程的完整链条上游 OpenBSD 的 pledge 语义与 SerenityOS 的权限粒度差异stdio是否隐含thread决定了必须在所有权限声明点显式追加thread内核侧 pledge.cpp 的权限只减不增校验决定了四处调用必须同步修改而 package.sh 中的-lpthread则从构建层面保证了线程能力的完整落地。理解这一补丁也就理解了 SerenityOS 移植第三方软件时处理平台安全 API 差异的典型范式。【免费下载链接】serenityThe Serenity Operating System 项目地址: https://gitcode.com/GitHub_Trending/se/serenity创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
