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
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
- Ambito
- operating-systems
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_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.
- 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
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di sudo-project/sudo
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 45/100
sudo-project/sudo#581 · 4 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
Signal forwarded to the command is lost when it arrives between fork() and execve() of the commandAperta
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
sudo-project/sudo#566 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 52/100
sudo-project/sudo#553 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
sudo-project/sudo#552 ·
I maintainer di solito rispondono entro 1 giorno
-
Documentation text overflows container instead of wrappingForse di nuovo libera @BittuBarnwal7479 l’ha presa 130 giorni fa e non c’è nessuna pull request aperta. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 58/100
sudo-project/sudo#547 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di sudo-project/sudo
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
InukaAsith/TwinDesk#84 ·
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
CanadaHonk/porffor#426 ·
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 77/100
raysan5/raylib.com#132 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100