| Summary: | Allow to redirect stderr only even with tty | ||
|---|---|---|---|
| Product: | Portable OpenSSH | Reporter: | cadeaudeelie |
| Component: | ssh | Assignee: | Assigned to nobody <unassigned-bugs> |
| Status: | NEW --- | ||
| Severity: | enhancement | CC: | cadeaudeelie, djm |
| Priority: | P5 | ||
| Version: | 9.1p1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
|
Description
cadeaudeelie
2023-02-18 02:45:25 AEDT
I searched in the GitHub Pr and didn't seen someone trying to implement nor some other ticket with the same thing. I volunteer to implement this with some guidance. How would you implement this? I don't see any clear way to do it. You can't use pipes/socketpair for the stderr, as any process that used stderr for ioctl() fstat() etc would not be talking to a tty. This would be very brittle. You couldn't use another pty, as then the process would have two pty states to contend with and only one of these would be a controlling pty. IMO you're trying to force ssh around an access management system that it doesn't fit. Maybe you should reconsider your access management system instead? The original stackexchange post link to another question with suggestions: https://unix.stackexchange.com/q/226638/246754 --forwardfd=10:3 The default stderr is untouched. We have one tty but we explicitly request another fd we can use for the launched application. Either in interactive shell or in command mode. If the launched process hardcode fd3 we can still change in the CLI the number we choose. I am unsure but newfd in dup2 can be arbitrary value so we could have the desired fd unless already taken for other things. It will even allow people who know stderr won't be used with ioctl to override destination of fd2. |