use_pty with non-tty stdin: command starts in background pgrp; foreground handoff only reaches the original pgrp, so a shell that creates its own pgrp (zsh) ends up unusable on FreeBSD/macOS
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 42/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- c
- Lĩnh vực
- operating-systems
Hướng nghiên cứu
Start by tracing the use_pty execution and SIGCONT_FG handoff paths in sudo’s C source; the issue provides debug output and a FreeBSD truss observation, but no source files or tests. Reproduce with the posted command on FreeBSD or macOS, then compare the process group and terminal foreground group during the handoff. Done means zsh gets a usable controlling terminal with non-tty stdin while existing behavior remains intact.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
use_pty with non-tty stdin: command starts in a background pgrp; the foreground handoff only reaches the original pgrp, so a shell that creates its own pgrp (zsh) is unusable on FreeBSD/macOS
Version / platforms
- sudo 1.9.17p2 on FreeBSD 14 and 15 and macOS 27: fails
- sudo 1.9.17p2 on Fedora: works (Ubuntu also works, with
Defaults use_ptyset) - zsh 5.9 / 5.9.2
Reproducer
With use_pty enabled, from an interactive terminal:
sudo sh -c 'cat; exec zsh </dev/tty' <<<ok
Actual result (FreeBSD/macOS)
ok
zsh: can't set tty pgrp: interrupt
The resulting zsh has no job control and does not execute commands (Enter does nothing). bash and ksh started the same way (exec bash </dev/tty) are fully usable.
Also on FreeBSD:
sudo sh -c 'cat; head -1 </dev/tty; echo "rc=$?"' <<<ok
returns immediately with rc=0 and no output. Under truss, head instead blocks and reads typed input, so there is a timing component.
Expected result
Same as Linux: the shell gets a usable controlling terminal.
Workarounds
Defaults>root !use_ptyfixes it.- Adding
kill -TTIN $$before the exec fixes it, with job control working:sudo sh -c 'cat; kill -TTIN $$; exec zsh </dev/tty' <<<ok
Findings from Debug sudo /var/log/sudo_debug all@debug
stdin not user's tty, not logging
exec_pty: follower: 11, stdin: 14, stdout: 11, stderr: 11
exec_cmnd_pty: executing /bin/sh in the background
mon_handle_sigchld: command (16272) stopped, SIGTTIN
suspend_sudo_pty: command received SIGTTIN, parent running in the foreground
scheduled SIGCONT_FG for command
received SIGCONT_FG from parent
In truss on FreeBSD, head receives SIGTTIN from the kernel on its first read of /dev/tty. A SIGCONT from the sudo front-end follows, and then the read succeeds.
Analysis (my interpretation, not verified in the sudo source or the kernel)
- With a non-tty stdin, sudo deliberately starts the command in a background process group on the pty. The foreground is granted only after the command stops on
SIGTTIN/SIGTTOU, and it is granted to the group of the command sudo launched. - zsh at startup moves itself into a new process group and calls
tcsetpgrp(). From the background this appears to raiseSIGTTOU. The monitor's handoff then goes to the original group, not zsh's new one. The call fails withEINTR, and zsh stays in a background group with no input. - The
kill -TTIN $$workaround triggers the handoff while the shell is still in the original group.execkeeps the same pid and group, so zsh then finds itself in the foreground. - It is unclear why Linux works with the same sudo version. I have not investigated that.
Possible fix directions
- Start the command in the foreground when the pty is its only terminal.
- Or make the
SIGCONT_FGhandoff follow the stopped process's current process group instead of the command pid.
- Ngôn ngữ chính
- C
- Star
- 1.7k
- Fork
- 306
- Merge trung bình
- 1 ngày 3 giờ
- Pull request đã merge (30 ngày)
- 21
Chuẩn bị môi trường
Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của sudo-project/sudo
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
sudo-project/sudo#586 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 45/100
sudo-project/sudo#581 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Signal forwarded to the command is lost when it arrives between fork() and execve() of the commandĐang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 35/100
sudo-project/sudo#566 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 52/100
sudo-project/sudo#553 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 48/100
sudo-project/sudo#552 ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của sudo-project/sudo
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
zephyrproject-rtos/zephyr#123881 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 65/100
ly05010419/MacNativeGames#1252 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
Maintainer thường phản hồi trong vòng 2 ngày
-
Component - Build
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Description of the bugĐang mởbug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
HarbourMasters/Lighthouse#655 ·
Maintainer thường phản hồi trong vòng 1 ngày