On 11/18/2013 04:09 PM, Heorhi Valakhanovich wrote:
On Mon, 18 Nov 2013 15:32:59 -0500
Peter Hurley <peter@xxxxxxxxxxxxxxxxxx> wrote:
On 11/18/2013 12:37 PM, Peter Hurley wrote:
On 11/18/2013 08:42 AM, One Thousand Gnomes wrote:
After upgrading to kernel 3.12 I noticed one issue with tmux
software. The easiest way to reproduce will be:
1. Start tmux session as root.
2. Connect via ssh and use "tmux attach" to attach to the running
session.
3. Kill ssh client.
Heorhi,
Thanks for the report.
You can notice that shell (zsh in my case) and "tmux attach" are
still remains in process' list. That didn't happen in previous
kernels.
Heorhi,
I could not reproduce this behavior with zsh or bash.
In case I misunderstood, the steps I took to reproduce were,
[On ssh server machine running 3.12]
1. Add 'set-option -g default-shell /usr/bin/zsh' to /etc/tmux.conf
This is really not necessary. I also reproduced it with bash.
2a. In terminal window, 'sudo tmux'
- also tried -
2b. At root login on tty2, 'tmux'
Successfully starts tmux session. Then,
[On ssh client machine]
1. 'ssh user@server'
2. 'sudo tmux attach'
3. Switch to 2nd terminal window,
4. ps -ef | grep ssh
5. kill $pid_from_step4
This *did not* leave the 'tmux attach' process alive.
Is zsh your login shell as well? Maybe that's the required
component to reproduce the behavior you've observed.
Regards,
Peter Hurley
Thank you for your attention.
I tried to reproduce it exactly as you did and notice strange thing.
You use "sudo tmux attach" and tmux client uses the terminal created
for regular user and those works good.
But if you will use "ssh root@server" (you can use localhost too) the
"tmux attach" will use terminal created from root (i checked this with
lsof and ls -al /dev/pts) and behavior is different. Are terminals
created for root is somehow different from those created for regular
users?
If you can't use root ssh login I will try to reproduce it's for sudo by
mixing some kind of dtach and tmux but it will be very unclear at the
end.
Thanks for the additional testing; yes, the "ssh root@server" is the
crucial difference. I was able to reproduce the problem immediately.
Before sshd execs a new root shell, it hangs up and then re-opens
the current tty as a security measure. Because the tty state was not
being reset, the subsequent re-open could not be hung up.
Would you please test the patch below and confirm the fix?
--->%---
Subject: [PATCH] tty: Reset hupped state on open
A common security idiom is to hangup the current tty (via vhangup())
after forking but before execing a root shell. This hangs up any
existing opens which other processes may have and ensures subsequent
opens have the necessary permissions to open the root shell tty/pty.
Reset the TTY_HUPPED state after the driver has successfully
returned the opened tty (perform the reset while the tty is locked
to avoid racing with concurrent hangups).
Reported-by: Heorhi Valakhanovich <valahanovich@xxxxxx>
Signed-off-by: Peter Hurley <peter@xxxxxxxxxxxxxxxxxx>
---
drivers/tty/tty_io.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index 3a1a01a..c74a00a 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -2086,6 +2086,7 @@ retry_open:
filp->f_op = &tty_fops;
goto retry_open;
}
+ clear_bit(TTY_HUPPED, &tty->flags);
tty_unlock(tty);
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
