Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le 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

Aperta
#583 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
42/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
c

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.
Lingua principale
C
Stelle
1.7k
Fork
306
Merge medio
1g 2h
PR unite (30g)
22

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di sudo-project/sudo

Tutte le issue di sudo-project/sudo

Issue simili

Altre issue su C

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.