Hacker News Reader

Comment by pyre | Hacker News Reader

My comment from the blog post:

tmux and screen both have upsides and downsides for pair programming. Ones that I know of:

1. screen requires itself to be setuid root for session sharing. This is security issue to say the least. The frustrating part of this is that screen explicitly checks that that uid == 0. This means that, even if you can iron out all of the permissions issues between you and your partner without needing root access, screen will only accept suid root as the solution.

2. When you are screen sharing in tmux, the configuration used is the configuration of the person hosting the session. This can suck if you have a lot of non-standard bindings, because it forces the person you're pairing with to know them too. screen allows you to both use your own configurations while being connected to the same session.

View on HN

Remote pair programming sucks. I don't know why there isn't a higher level protocol that would send simple tab changes, text highlights, text deletion, and other high level common tasks. This way the two connected programmer could actually be using different editors but still experience the same editor actions. And each user could maintain their own separate key bindings.

Who cares if I press cmd-t to open a file or my pair prefers to open a file with cmd-shift-n? Just send me the action that a file was opened.

I wrote up my detailed thoughts on fixing remote pair programming here.

https://gist.github.com/1999816

  > Who cares if I press cmd-t to open a file or my pair
  > prefers to open a file with cmd-shift-n? Just send
  > me the action that a file was opened.

I don't think that this was an affirmative design decision. I think it has to do with the architecture of software, and is merely a side-effect of that architecture. Pair programming isn't the main use-case for terminal multiplexers.

As with Google Documents where you can see other changes in real-time?

Yes and no. Would be really fun for five minutes and really irritating for the rest of the time.

That is what pair programming is about. Collaborative changes in real-time.

I would say that pair programming is primarily about close collaboration between people, code is just an artifact of that.

3. Both pairs get access to whatever user starts tmux. This may or may not be a problem, but it was with me as we were pairing on my personal machine and I didn't feel comfortable giving complete access like that.

What we came up with is creating a new "pair user" and running tmux within that.

The configuration wasn't a problem for us since one of us hadn't ever used tmux and had therefore had no opinion.

  > Both pairs get access to whatever user starts tmux

IIRC, if you 'host' a (gnu) screen session, then your pair will create new shells as your user. This is not a tmux-only issue.

  > What we came up with is creating a new
  > "pair user" and running tmux within that.

That's an idea that I had, but hadn't attempted to look into yet. This also gets around the screen suid root issue (though not necessarily the config issue), if you're both logged in as the same user. How has this been working, any caveats?

  > The configuration wasn't a problem for us
  > since one of us hadn't ever used tmux and
  > had therefore had no opinion.

I use ` instead of C-a/C-b in both screen and tmux, so it could be a bit jarring to others.

> That's an idea that I had, but hadn't attempted to look into yet. This also gets around the screen suid root issue (though not necessarily the config issue), if you're both logged in as the same user. How has this been working, any caveats?

I'm not sure why you need to set suid on tmux. Before we created the pair user I just used the -S option to specify a socket path and then chmoded the created socket so my pair could access it.

So far so good with the new pair user. The only thing that's different is that to push our changes up to the main repo we need ssh keys and we haven't gone through the trouble of creating a new ssh key for the pair user and adding it to our teams github repo, so we have to git push and pull from a non-pair login. That can be fixed when it gets annoying but so far I'm always logged in to that machine as myself as well as the pair user so I can just switch tabs and git push/pull when needed.

> I use ` instead of C-a/C-b in both screen and tmux, so it could be a bit jarring to others.

I use C-\ myself since C-a and C-b are both prominent Emacs keys.

  > I'm not sure why you need to set suid on tmux

I guess I should have been clearer:

  > This also gets around the "GNU screen" suid root issue

You can easily fix this. You can:

1) Use a combination of ssh-agent fowarding and manually exporting the $SSH_AUTH_SOCK variable to switch between two users' ssh-agent sockets.

2) Each user commits from a separate window/shell. Each window/shell has a separate ssh-agent running in it, with that user's ssh key ssh-add'd to it.

Though, options 2 is less secure.

I'd add:

3) Tmux sessions are restricted to the size of the smallest client connected to the session. We've recently started using it at work and it works fine for 2 of us, but 2 others found that the resolution differences between their 13" and 15" macbooks means that the 13" sets the tmux session size so the 15" doesn't use the whole screen.

I'm pretty sure this would also be an issue with screen. The pair maybe able to operate on separate 'windows' at different sizes, but would not be able to view the same window at two different sizes at the same time.

Actually Screen is even worse; it sets the size to whoever joined last. So if someone with a big screen joins a session of someone with a small screen, portions of the window will be invisible to the person who started it.

C-a F will resize screen window to size of your terminal.

I'd experiment with different font sizes to match the line count.

Regarding #1: if you are doing software development on a system with any security requirements at all, you have already lost. Maybe I can see bending that rule for debugging a live system in extremis, but not for "pair programming".

  > if you are doing software development on a
  > system with any security requirements at all,
  > you have already lost

Could you expand on how security and development are diametrically opposed to each other?

If my development server is exposed to the Internet and I do something like disable root logins in ssh, why/what have I 'lost?'

A box under development can and will have all sorts of terribly insecure behavior. It shouldn't be on the internet. I'm not saying you "lose" anything by trying to secure it, I'm saying that you already "lost the [security] game" when you put the box on the unfiltered internet in the first place. Your goal should be limiting exposure when it is compromised, not trying to lock down hatches on a leaky hull.

Specifically: dickering over whether or not to make screen suid root on your dev boxes is an exercise in needless optimization.

  > Specifically: dickering over whether or not to make
  > screen suid root on your dev boxes is an exercise
  > in needless optimization.

Are you speaking from the point of view of a 13 person startup, a 200 person business or a Fortune 500 corporation?

> Your goal should be limiting exposure when it is compromised, not trying to lock down hatches on a leaky hull.

But isn't running applications only as regular users just that, limiting exposure?

One way we are going to get around this is that we plan to have a golden .tmux.conf that we will all use at DockYard, so that any non-standard bindings will be standard to us

For #2 - there is WeMux (https://github.com/zolrath/wemux), a shell script wrapper over tmux. I am not an expert, so cannot point out how (in)effective it is in terms of applicability or security.

Reply on news.ycombinator.com