ioctl_tiocsctty passes the address of a zero instead of the documented 0 argument
维护者通常 3 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 2/5
- 预计耗时
- 1-3 小时
- 新手友好度
- 68/100
- Issue 类型
- 缺陷
- 描述清晰度
- 描述清楚
- 活跃度
- 活跃
- 技术栈
- linux, rust
调研方向
问题出在 src/process/ioctl.rs：有文档记载的调用位于第 13 行，而第 45-47 行的参数适配器传递的是栈上局部变量 0u32 的地址，而不是值 0。请先阅读该适配器和 ioctl_tiocsctty 的文档注释，然后运行 issue 中的 strace 复现步骤以确认错误参数。完成标准是：适配器传递字面量 0，注释引用 ioctl_tty(2)，并且 strace 输出显示 TIOCSCTTY, 0。
由索引模型根据 Issue 内容生成。
描述
rustix::process::ioctl_tiocsctty is documented as performing ioctl(fd, TIOCSCTTY, 0):
but the argument adapter passes the address of a stack-local 0u32:
Linux from 2.6.12 requires the third arg to be exactly 1 for the option to steal the terminal, and only uses that arg anyway when CAP_SYS_ADMIN. On BSDs the arg is ignored. The Linux manpage says to use 0 otherwise; the comment in the code has tty_ioctl(4) but that's since been renamed to ioctl_tty(2) and TIOCSCTTY(2const) has the detail:
Make the given terminal the controlling terminal of the
calling process. The calling process must be a session
leader and not have a controlling terminal already. For
this case, arg should be specified as zero.
If this terminal is already the controlling terminal of a
different session group, then the ioctl fails with EPERM,
unless the caller has the CAP_SYS_ADMIN capability and arg
equals 1, in which case the terminal is stolen, and all
processes that had it as controlling terminal lose it.
From kernel source:
static int tiocsctty(struct tty_struct *tty,
struct file *file, int arg)
{
// ...
if (tty->ctrl.session) {
if (arg == 1 && capable(CAP_SYS_ADMIN)) {
session_clear_tty(tty->ctrl.session);
} else {
ret = -EPERM;
goto unlock;
}
}
// ...
}
This isn't unsafe exactly, but it's still confusing. Also, it might be worth exposing the steal variant.
Tiny repro:
#!/usr/bin/env -S cargo +nightly -Zscript
---cargo
package.edition = "2024"
dependencies.rustix = { version = "1.1.5", features = ["process"] }
---
fn main() {
let _ = rustix::process::ioctl_tiocsctty(std::io::stdin());
}
With strace:
$ ./repro.rs >/dev/null # compile
$ sudo strace -e ioctl ~/.cargo/build/*/*/target/debug/repro # run with CAP_SYS_ADMIN
ioctl(0, TIOCSCTTY, -527932840) = -1 ENOTTY (Inappropriate ioctl for device)
The return may vary and isn't relevant: -527932840 is an address and is neither 0 nor 1, the two permitted values. A silver lining is that it's also impossible for arg to be 1 under the current code, so it's technically harmless.
- 主要语言
- Rust
- 星标
- 2.1k
- 派生
- 308
- PR 合并指标
- 30 天内没有已合并 PR
环境准备
- 没有 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 条评论 ·
维护者通常 3 天内回复
-
Wrong flag used for (set_)ipv6_multicast_hops可能已有人在做 @RajaBabu15 于 62 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 84/100
bytecodealliance/rustix#1660 ·
维护者通常 3 天内回复
-
难度 2/5 1-3 小时 新手友好度 68/100
bytecodealliance/rustix#1635 ·
维护者通常 3 天内回复
-
enhancement
难度 2/5 1-3 小时 新手友好度 62/100
bytecodealliance/rustix#1068 ·
维护者通常 3 天内回复
-
难度 5/5 一周以上 新手友好度 8/100
bytecodealliance/rustix#1702 ·
维护者通常 3 天内回复
查看 bytecodealliance/rustix 的全部 Issue
相似的 Issue
-
RUSTSEC-2026-0348: Brotli certificate decompression can allocate up to 1 GiB before authentication未关闭
难度 2/5 1-3 小时 新手友好度 60/100
-
难度 1/5 1-3 小时 新手友好度 62/100
-
core: Amount::from_str panics on values above 21M BTC instead of returning an error可能已有人在做 @bhuvan-somisetty 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 82/100
维护者通常 1 天内回复
-
crate: spate-s3
难度 2/5 半天 新手友好度 62/100
维护者通常 1 天内回复
-
write_iceberg ignores the table's write.parquet.compression-codec property可能已有人在做 @YuangGao 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 82/100
Eventual-Inc/Daft#7606 ·
维护者通常 1 天内回复