Re: [PATCH] tty: Only hangup once

[Peter Hurley]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/