Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
#583 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

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_pty set)
  • 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_pty fixes 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 raise SIGTTOU. The monitor's handoff then goes to the original group, not zsh's new one. The call fails with EINTR, 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. exec keeps 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_FG handoff 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

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. 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.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của sudo-project/sudo

Tất cả issue của sudo-project/sudo

Issue tương tự

Thêm issue về C

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.