Problems with piping into sudo-rs

[DriedSnow]

Describe the bug
When using sudo-rs in a command to remove orphens on Archlinux pipeing pacman -Qqtd in to sudo-rs pacman -Rsu - does not let you enter Y or N to continue and just exits.

To Reproduce
Steps to reproduce the behavior:

1. Install sudo-rs
2. Run pacman -Qqtd | sudo-rs pacman -Rsu -
3. see error
   pacman -Qqtd | sudo-rs pacman -Rsu -

Expected behavior
A clear and concise description of what you expected to happen.

Environment (please complete the following information):

• Linux distribution: Archlinux
• sudo-rs commit hash: b57be94 and 5314990

Additional context

pacman -Qqtd | sudo-rs pacman -Rsu -
checking dependencies...
:: binutils optionally requires debuginfod: for debuginfod server/client functionality
:: python-geopy optionally requires python-pytz: for timezone support
:: python-jinja optionally requires python-babel: for i18n support
:: python-mako optionally requires python-babel: for i18n features
:: python-pyqt5 optionally requires qt5-location: QtLocation, QtPositioning
:: python-pyqt5 optionally requires qt5-webchannel: QtWebChannel
:: systemd optionally requires libmicrohttpd: systemd-journal-gatewayd and systemd-journal-remote

Packages (51) cjson-1.7.18-1 debuginfod-0.193-5 libmicrohttpd-1.0.2-1 libx86emu-3.7-2 perl-xml-writer-0.900-5
python-babel-2.17.0-1 python-imagesize-1.4.1-6 python-pytz-2025.2-1 python-roman-numerals-py-3.1.0-1
python-snowballstemmer-2.2.0-7 python-sphinx-8.2.3-1 python-sphinx-alabaster-theme-1.0.0-4
python-sphinxcontrib-applehelp-2.0.0-3 python-sphinxcontrib-devhelp-2.0.0-4
python-sphinxcontrib-htmlhelp-2.1.0-3 python-sphinxcontrib-jquery-4.1-4 python-sphinxcontrib-jsmath-1.0.1-19
python-sphinxcontrib-qthelp-2.0.0-3 python-sphinxcontrib-serializinghtml-2.0.0-3
qt5-location-5.15.17+kde+r7-1 qt5-webchannel-5.15.17+kde+r3-1 asio-1.34.2-1 boost-1.88.0-3
cbindgen-0.29.0-1 check-0.15.2-3 ckbcomp-1.242-1 electron35-35.7.5-1 ffnvcodec-headers-13.0.19.0-1
granite-1:6.2.0-1 hwinfo-25.0-2 kitemmodels5-5.116.0-1 librist-0.2.11-1 libspng-0.7.4-2 libtar-1.2.20-7
libva-utils-2.22.0-1 mbedtls2-2.28.10-1 patchutils-0.4.2-3 profile-sync-daemon-1:6.50-2 python-ply-3.11-15
python-pyaml-24.12.0-1 python-pyliblo-0.10.0-14 python-sphinx-hawkmoth-0.21.0-1
python-sphinx_rtd_theme-2.0.0-2 qrcodegencpp-cmake-1.8.0-4 qt5-webengine-5.15.19-2 rust-bindgen-0.72.0-1
spirv-headers-1:1.4.321.0-1 valgrind-3.25.1-3 vdpauinfo-1.5-2 webkit2gtk-2.48.6-1 xmlto-0.0.29-1

Total Removed Size: 914.19 MiB

:: Do you want to remove these packages? [Y/n] %

[squell]

Thanks for the report! This is the behaviour that I would naively expect. To gather information for deciding on the priority of this bug, we are curious whether this usage does work with original sudo? (I'm not on Arch Linux machine at the moment but a quick check on Ubuntu shows sudo-rs and sudo behaving similarly, and not unexpectedly so, in a comparable situation with apt-get, but it might be that pacman of course implements its prompt differently).

[DriedSnow]

Thanks for the report! This is the behaviour that I would naively expect. To gather information for deciding on the priority of this bug, we are curious whether this usage does work with original sudo? (I'm not on Arch Linux machine at the moment but a quick check on Ubuntu shows sudo-rs and sudo behaving similarly, and not unexpectedly so, in a comparable situation with apt-get, but it might be that pacman of course implements its prompt differently).

It does work the the original sudo properly, letting me press Y or N to continue the command

[DriedSnow]

If it helps here is a video of me running both the commands "pacman -Qqtd|sudo pacman -Rsu -" and "pacman -Qqtd|sudo-rs pacman -Rsu -"

2025-09-09.18-42-56.mp4

[mrmonopoly-cyber]

Hi, recently i looked at this bug. From what i understood from the code seems like dev/tty is not available as a prompt if stdin is piped since the process is considered as working in background. I would like to work on the issue if it is possible. Regardless of that i will post a few things i discovered. I hope it can be useful to someone else in case.

src/exec/use_pty/parent.rs:107

    if !io::stdin().is_terminal() {
        dev_info!("stdin is not a terminal, command will inherit it");
        pipeline = true;
        command.stdin(Stdio::inherit());

        if foreground && parent_pgrp != sudo_pid {
            // If sudo is not the process group leader and stdin is not a terminal we might be
            // running as a background job via a shell script. Starting in the foreground would
            // change the terminal mode.
            exec_bg = true;
        }
    }

In the snippest above pipeline is set to true and also maybe exec_bg

src/exec/use_pty/parent.rs:182

        match exec_monitor(
            pty.follower,
            command,
            foreground && !pipeline && !exec_bg,
            &mut backchannels.monitor,
            original_set,
        ) {

Because of the previous flags (pipeline, exec_bg) the process is considered as a background process even if, as in the case of the issue, we need the input from /dev/tty.

The % character in the example, from what i understood, is the EOF of the stdin pipe which is used as fallback from pacman since it has no access to the /dev/tty (user input).

I already tested my theory and if we force the execution of the process as foreground

        match exec_monitor(
            pty.follower,
            command,
            true,
            //foreground && !pipeline && !exec_bg,
            &mut backchannels.monitor,
            original_set,
        ) {

the problem is not present for the example above.

I tried a solution for the problem and all the tests are passing but i would like to hear someone who knows the argument more than me.

src/exec/use_pty/parent.rs:107

    if !io::stdin().is_terminal(){
        command.stdin(Stdio::inherit());
        if !fs::File::open("/dev/tty").is_ok() {
            dev_info!("stdin is not a terminal, command will inherit it");
            pipeline = true;

            if foreground && parent_pgrp != sudo_pid {
                // If sudo is not the process group leader and stdin is not a terminal we might be
                // running as a background job via a shell script. Starting in the foreground would
                // change the terminal mode.
                exec_bg = true;
            }
        }
    }

What i'm doing whit this little snippet of code is adding another check which keep the process in foreground even if the stdin is not a tty. Only if /dev/tty is no accessible/closed i consider everything as pipeline or exec_bg. I tested the the suggested snippest and it passes all the tests. So all of that to say that i would like to work on the issue to find the solution to problem. I'm not suggesting the snippest as a solution since it's more an hack which solves the issue.

I hope it can be useful. I'm open to questions and i'm sorry if my description in imprecise but i never work on the sudo code and i'm not really too familiar with it.

[squell]

The issue is indeed caused because sudo starts the command in the background in this situation and then doesn't make the TTY available.

The fix here that I expect is that as soon as the process does want to read from the TTY, sudo-rs will receive the SIGTTIN signal and then should indeed make the TTY available to the child process.

But if we do that too early you could end up in a similar situation to #1260

Note that if moving the Stdio::inherit() call in the way you describe still lets sudo-rs pass all integration tests in test-framework/, it would also be useful to us to try and write one where it does behave differently, so that's also a way you could help even if you don't know where to begin with the above description. Most integration tests are testing single invocations and have a bias towards testing security features (for obvious reasons).

[mrmonopoly-cyber]

Thank you for the answer, i was already thinking on making a test for this situation. For this reason i'm looking on the test framework you are using. Also i understand what you are saying and it makes sense so i will start working on it, if it's not a problem, pretty soon.

[squell]

Happy hacking! At some point we'll want to have this fixed, but we won't have time before december and more likely january. But I'll notify you if we start taking a stab ourselves to avoid wasting your time.

[squell]

Note: this is related to exec_background in man sudoers. Essentially if this setting is set to true, any process run in pty mode will be "backgrounded" initially and then handed the TTY when SIGTTIN , I'll quote it here:

By default, sudo runs a command as the foreground process as long as sudo itself is running in the foreground. When the exec_background flag is enabled and the command is being run in a pseudo-terminal (due to I/O logging or the use_pty flag), the command will be run as a background process. Attempts to read from the controlling terminal (or to change terminal settings) will result in the command being suspended with the SIGTTIN signal (or SIGTTOU in the case of terminal settings). If this happens when sudo is a foreground process, the command will be granted the controlling terminal and resumed in the foreground with no user intervention required. The advantage of initially running the command in the background is that sudo need not read from the terminal unless the command explicitly requests it. Otherwise, any terminal input must be passed to the command, whether it has required it or not (the kernel buffers terminals so it is not possible to tell whether the command really wants the input). This is different from historic sudo behavior or when the command is not being run in a pseudo-terminal.

For this to work seamlessly, the operating system must support the automatic restarting of system calls. Unfortunately, not all operating systems do this by default, and even those that do may have bugs. For example, macOS fails to restart the tcgetattr(3) and tcsetattr(3) functions (this is a bug in macOS). Furthermore, because this behavior depends on the command stopping with the SIGTTIN or SIGTTOU signals, programs that catch these signals and suspend themselves with a different signal (usually SIGTOP) will not be automatically foregrounded. Some versions of the linux su(1) command behave this way. This flag is off by default.

Basically this mechanism of 'being passed the TTY when in background' is not implemented in sudo-rs.

I'm not sure if we need to implement exec_background, but it could help in testing to have a way to enable the 'start in background mode, then jump to foreground as needed'.

[mrmonopoly-cyber]

I have a question, i looked a bit into the code to understand the flow and how it works. I understand the signal handling, the processes (parent, monitor, user process) and the event loop. I was asking myself if it has any sense to set the SIGTTIN signal of the monitor to stream instead of ignoring. Since the user process will inherit the stdio descriptors from the parent (monitor) by setting the SIGTTIN to stream it will be then passed to the parent through its event loop. I see that there are some comments on why SIGTTIN is ignored in the monitor but i would like to better understand why SIGTIN is ignored and if what i said has any sense.

Here the change (src/exec/use_pty/monitor.rs:47):

match SignalHandler::register(SIGTTIN, SignalHandlerBehavior::Stream) {
        Ok(handler) => handler.forget(),
        Err(err) => dev_warn!("cannot set handler for SIGTTIN: {err}"),
}

I tested an execution with the following command:

pacman -Qqtd | sudo-rs pacman -Rsu -;

the behaviour for the command with this modification is the expected one

Also the dev-log:

src/sudo/mod.rs:66:5: development logs are enabled
src/sudo/mod.rs:59:5: Running with /etc/sudoers file
src/exec/use_pty/parent.rs:90:5: sudo is running in the foreground
src/exec/use_pty/parent.rs:109:9: stdin is not a terminal, command will inherit it
src/exec/use_pty/parent.rs:361:37: event Backchannel(Readable) is ready
src/exec/use_pty/parent.rs:403:25: received command PID (7017) from monitor
src/exec/use_pty/parent.rs:361:37: event Pty(Readable) is ready
src/exec/use_pty/parent.rs:361:37: event Tty(Writable) is ready
src/exec/use_pty/parent.rs:361:37: event Tty(Writable) is ready
src/exec/use_pty/parent.rs:361:37: event Pty(Readable) is ready
src/exec/use_pty/parent.rs:361:37: event Tty(Writable) is ready
src/exec/use_pty/parent.rs:361:37: event Tty(Writable) is ready
src/exec/use_pty/parent.rs:361:37: event Pty(Readable) is ready
src/exec/use_pty/parent.rs:361:37: event Tty(Writable) is ready
src/exec/use_pty/parent.rs:361:37: event Tty(Writable) is ready
src/exec/use_pty/parent.rs:361:37: event Pty(Readable) is ready
src/exec/use_pty/parent.rs:361:37: event Tty(Writable) is ready
src/exec/use_pty/parent.rs:361:37: event Tty(Writable) is ready
src/exec/use_pty/parent.rs:361:37: event Pty(Readable) is ready
src/exec/use_pty/parent.rs:361:37: event Tty(Writable) is ready
src/exec/use_pty/parent.rs:361:37: event Tty(Writable) is ready
src/exec/use_pty/parent.rs:361:37: event Pty(Readable) is ready
src/exec/use_pty/parent.rs:361:37: event Tty(Writable) is ready
src/exec/use_pty/parent.rs:361:37: event Tty(Writable) is ready
src/exec/use_pty/parent.rs:361:37: event Pty(Readable) is ready
src/exec/use_pty/parent.rs:361:37: event Tty(Writable) is ready
src/exec/use_pty/parent.rs:361:37: event Tty(Writable) is ready
src/exec/use_pty/parent.rs:361:37: event Pty(Readable) is ready
src/exec/use_pty/parent.rs:361:37: event Tty(Writable) is ready
src/exec/use_pty/parent.rs:361:37: event Tty(Writable) is ready
src/exec/use_pty/parent.rs:361:37: event Pty(Readable) is ready
src/exec/use_pty/parent.rs:361:37: event Tty(Writable) is ready
src/exec/use_pty/parent.rs:361:37: event Tty(Writable) is ready
src/exec/use_pty/parent.rs:361:37: event Pty(Readable) is ready
src/exec/use_pty/parent.rs:361:37: event Pty(Readable) is ready
src/exec/use_pty/parent.rs:361:37: event Tty(Writable) is ready
src/exec/use_pty/parent.rs:361:37: event Tty(Writable) is ready
src/exec/use_pty/monitor.rs:146:27: event Signal is ready
src/exec/use_pty/monitor.rs:354:9: monitor received 17 from <none>
src/exec/mod.rs:282:9: 7017 (command) was stopped by SIGTTIN
src/exec/use_pty/parent.rs:361:37: event Backchannel(Readable) is ready
src/exec/use_pty/parent.rs:419:33: command was stopped by SIGTTIN, suspending parent
src/exec/use_pty/parent.rs:528:17: command received SIGTTIN, parent running in the foreground
src/exec/use_pty/parent.rs:471:9: scheduling message with SIGCONT_FG for monitor
src/exec/use_pty/parent.rs:361:37: event Pty(Writable) is ready
src/exec/use_pty/parent.rs:361:37: event Tty(Writable) is ready
src/exec/use_pty/parent.rs:361:37: event Backchannel(Writable) is ready
src/exec/use_pty/parent.rs:483:13: sending message Signal(SIGCONT_FG) to monitor over backchannel
src/exec/use_pty/monitor.rs:146:27: event ReadableBackchannel is ready
src/exec/use_pty/monitor.rs:308:9: sending SIGCONT_FG from parent to command
src/exec/use_pty/monitor.rs:146:27: event Signal is ready
src/exec/use_pty/monitor.rs:354:9: monitor received 17 from <none>
src/exec/mod.rs:273:24: 7017 (command) has no status report
src/exec/use_pty/parent.rs:361:37: event Tty(Readable) is ready
src/exec/use_pty/parent.rs:361:37: event Pty(Writable) is ready
src/exec/use_pty/parent.rs:361:37: event Pty(Writable) is ready
src/exec/use_pty/parent.rs:361:37: event Pty(Readable) is ready
src/exec/use_pty/parent.rs:361:37: event Tty(Writable) is ready
src/exec/use_pty/parent.rs:361:37: event Tty(Writable) is ready
src/exec/use_pty/parent.rs:361:37: event Tty(Readable) is ready
src/exec/use_pty/parent.rs:361:37: event Pty(Writable) is ready
src/exec/use_pty/parent.rs:361:37: event Pty(Writable) is ready
src/exec/use_pty/parent.rs:361:37: event Pty(Readable) is ready
src/exec/use_pty/parent.rs:361:37: event Tty(Writable) is ready
src/exec/use_pty/parent.rs:361:37: event Tty(Writable) is ready
src/exec/use_pty/parent.rs:361:37: event Pty(Readable) is ready
src/exec/use_pty/parent.rs:361:37: event Tty(Writable) is ready
src/exec/use_pty/parent.rs:361:37: event Tty(Writable) is ready
src/exec/use_pty/monitor.rs:146:27: event Signal is ready
src/exec/use_pty/monitor.rs:354:9: monitor received 17 from <none>
src/exec/mod.rs:279:9: 7017 (command) exited with status code 1
src/exec/use_pty/parent.rs:361:37: event Backchannel(Readable) is ready
src/exec/use_pty/parent.rs:411:33: command exited with status code 1

By looking at the log i see that the process suspends itself since it needed the tty from the parent, the monitor catch the signal, send it to the parent through the backchannel, the parent manage it through the event loop, give the tty to the process and resume the user process through the SIGCONT_FG signal. I'm worried this may cause issues if the parent is in background but in that case SIGGTIN cannot arise and it should not be a problem since also the monitor and the user process would also be in background.

[pvdrz]

I see that there are some comments on why SIGTTIN is ignored in the monitor but i would like to better understand why SIGTIN is ignored and if what i said has any sense.

This logic is inherited from the original sudo, basically. And it is still in place: sudo-project/sudo@1186f398#diff-3a68ced1c93ec0f53f18c9b9a4aaa4ee858bdc89e3ab267eb666fa99da9a608cR508

I don't remember the specific details on why this is the case. Maybe @millert could answer this more concretely.

[pvdrz]

I tried a solution for the problem and all the tests are passing but i would like to hear someone who knows the argument more than me.

src/exec/use_pty/parent.rs:107

if !io::stdin().is_terminal(){
    command.stdin(Stdio::inherit());
    if !fs::File::open("/dev/tty").is_ok() {
        dev_info!("stdin is not a terminal, command will inherit it");
        pipeline = true;

        if foreground && parent_pgrp != sudo_pid {
            // If sudo is not the process group leader and stdin is not a terminal we might be
            // running as a background job via a shell script. Starting in the foreground would
            // change the terminal mode.
            exec_bg = true;
        }
    }
}

What i'm doing whit this little snippet of code is adding another check which keep the process in foreground even if the stdin is not a tty. Only if /dev/tty is no accessible/closed i consider everything as pipeline or exec_bg. I tested the the suggested snippest and it passes all the tests. So all of that to say that i would like to work on the issue to find the solution to problem. I'm not suggesting the snippest as a solution since it's more an hack which solves the issue.

This solution seems to be on track for me, but I suspect we should do this accessibility check in a more direct way as there could be other reasons to not be able to open /dev/tty

Edit: to be more concise, @mrmonopoly-cyber do you think it is possible to just check if the file descriptor that we have for the terminal is owned by the user or the user's group, for example?