Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Malformed stderr output when stdout is not piped #349

Open
bboozzoo opened this issue Jan 23, 2024 · 2 comments
Open

Malformed stderr output when stdout is not piped #349

bboozzoo opened this issue Jan 23, 2024 · 2 comments

Comments

@bboozzoo
Copy link

The change https://www.sudo.ws/repos/sudo/rev/faa06b1e8913 (78b7121) fixed the problem with 'staircase' output when stdout is piped. However when invoking applications under program like strace (which poduces its output mainly to stderr), it is possible that only stderr is piped, while stdin/stdout remain as they were. In this case, the autodetection of a piped output will fail to identify the scenario correctly and the output of stderr will be badly formatted.

A possible workaround is to pipe the stdout as well, but that has unwanted side effects if the application is interactive like eg. bash.

@millert
Copy link
Collaborator

millert commented Jan 23, 2024

This is a non-trivial problem for interactive commands. I don't know what command you are using but for, e.g.

sudo strace bash 2> >(tee /tmp/foo)

The user's terminal needs to be in raw mode so input can be passed to the interactive bash process running in a pseudo-terminal. The tee in this case is also writing to the user's terminal (not the pty being used by bash), which won't automatically convert newlines to newline + carriage return pairs (because it is in raw mode).

I'm not sure why you wouldn't just use strace's -o flag in this type of situation. You could work around the problem by only running commands in a pty is the target user is something other than root. E.g.

Defaults>root !use_pty

@bboozzoo
Copy link
Author

bboozzoo commented Jan 24, 2024

Thanks for the reply, appreciated. I suspected the problem may indeed be non-trivial and I'm not sure it can be addressed in sudo without falling back to changing the system wide configuration.

For context, there is a command snap run --strace <app>, which will invoke strace on a app for the caller, but since a setuid binary (snap-confine) is included in the command chain, it's really calling sudo strace -u <target-user> .. under the hood. The output from strace is going directly to stderr in this case, unless the user explicitly passed -o to strace (eg. snap run --strace='-o myfile' <app>). Even after I identified that adding sudo would make the stderr output go weird, there was some head scratching involved when trying to guess why it's correct on Debian, Ubuntu (with sudo 1.9.13), but wrong on Fedora, Arch (with sudo 1.9.15). I obviously wanted to preserve the default behavior, and our own controlled --output was one of the options I considered, but that obviously came with more questions depending on whether the destination would be a file/fifo, cleanup, reading etc. Then piping stdout triggers the behavior I wanted.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants