getpgid: UB when the kernel returns process group 0 (kernel threads / other PID namespace)
维护者通常 4 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 30/100
- Issue 类型
- 缺陷
- 描述清晰度
- 基本清楚
- 活跃度
- 活跃
- 技术栈
- rust
- 领域
- api, backend, operating-systems
调研方向
Read src/backend/linux_raw/process/syscalls.rs and src/backend/libc/process/syscalls.rs, starting at getpgid and comparing how each handles the kernel result. Then check the public Pid API and related wrappers such as getsid to understand the impact of the proposed choices. Done means a safe, consistent way to represent or handle a returned 0 is agreed on and applied; the issue does not specify which fix to choose.
由索引模型根据 Issue 内容生成。
描述
getpgid can return a process group ID of 0 on Linux. rustix then builds a Pid from that value with Pid::from_raw_unchecked, which calls NonZeroI32::new_unchecked(0). That is undefined behavior in release builds. Debug builds hit the debug_assert!(pgid > 0) instead.
Where: src/backend/linux_raw/process/syscalls.rs, getpgid, unchanged in 1.1.4 and on main. The libc backend (src/backend/libc/process/syscalls.rs) does the same without the debug assertion.
When the kernel returns 0: getpgid(2) reports the group ID as seen from the caller's PID namespace. Two cases give 0:
- kernel threads, for example PID 2 (
kthreadd) and its children; - any process whose process group is not visible in the caller's namespace.
A process that scans /proc and calls getpgid on every PID will meet both cases.
Reproduction (Linux, debug build):
let pgid = rustix::process::getpgid(rustix::process::Pid::from_raw(2));
// panics on the debug_assert; in release it creates a Pid holding 0 (UB)
Possible fixes:
- return
Result<Option<Pid>>, withNonefor 0; - map 0 to an error;
- document it and return a type that may hold 0.
Other wrappers that hand a kernel-provided ID to from_raw_unchecked (for example getsid) may have the same issue.
We found this while running a test suite natively on Ubuntu 26.04. As a workaround we now call libc::getpgid directly and treat 0 as "no visible group".
- 主要语言
- Rust
- 星标
- 2.1k
- 派生
- 301
- 平均合并
- 10 天 1 小时
- 30 天内合并 PR
- 1
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
bytecodealliance/rustix 的其他 Issue
-
net feature alone fails to compile in 1.1.5: sockopt uses crate::timespec, which net does not gate in可能重新可做 关联的 PR 已关闭且未合并。 未关闭
难度 2/5 1-3 小时 新手友好度 70/100
bytecodealliance/rustix#1689 · 2 条评论 ·
维护者通常 4 天内回复
-
Wrong flag used for (set_)ipv6_multicast_hops可能已有人在做 @RajaBabu15 于 53 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 84/100
bytecodealliance/rustix#1660 ·
维护者通常 4 天内回复
-
难度 2/5 1-3 小时 新手友好度 68/100
bytecodealliance/rustix#1635 ·
维护者通常 4 天内回复
-
enhancement
难度 2/5 1-3 小时 新手友好度 62/100
bytecodealliance/rustix#1068 ·
维护者通常 4 天内回复
-
难度 4/5 3-5 天 新手友好度 42/100
bytecodealliance/rustix#1698 ·
维护者通常 4 天内回复
查看 bytecodealliance/rustix 的全部 Issue
相似的 Issue
-
难度 1/5 1 小时以内 新手友好度 80/100
Devolutions/picky-rs#546 · 1 条评论 ·
维护者通常 3 天内回复
-
难度 2/5 1-3 小时 新手友好度 74/100
维护者通常 1 天内回复
-
enhancement
难度 2/5 1-3 小时 新手友好度 78/100
zcashlabs/thus-spoke-zakura#153 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 79/100
topgrade-rs/topgrade#2395 ·
维护者通常 1 天内回复
-
app bug windows-os
难度 2/5 1-3 小时 新手友好度 67/100
维护者通常 1 天内回复