147

I'm looking for a clean and easy way to share a tmux session with another user on the same machine. I've tried the -S socket-path option, but it requires opening up all permissions of the socket-path before someone else can connect to the session. It works, but it's a little cumbersome. For example:

# Me
$ tmux -S /tmp/pair
$ chmod 777 /tmp/pair

# Another user
$ tmux -S /tmp/pair attach

This works, but both users now share the same tmux configuration (the configuration of the user who initiated the session). Is there a way to allow the two users to use their own tmux config and their own individual tmux key bindings?

For bonus points, ideally, it would also be nice to give read-only access of the tmux session to other users.

Ryan McGeary
  • 1,575
  • 33
    I'm too lazy I just use your question as my answer :D – phunehehe May 23 '13 at 07:20
  • 1
    Warning: now tmux detach supports -E that replaces the client with an arbitrary shell command. It doesn't matter if the target client runs under a different Unix user. So any user that can access /tmp/pair can run arbitrary code replacing any attached client. The victim may not notice if you re-attach them fast enough: tmux -S /tmp/pair detach -t /dev/victim_tty -E '(malicious shell code) & exec tmux -S /tmp/pair attach' – Kamil Maciorowski Nov 22 '19 at 18:27

6 Answers6

57

From https://github.com/zolrath/wemux:

wemux enhances tmux to make multi-user terminal multiplexing both easier and more powerful. It allows users to host a wemux server and have clients join in either:

Mirror Mode gives clients (another SSH user on your machine) read-only access to the session, allowing them to see you work, or

Pair Mode allows the client and yourself to work in the same terminal (shared cursor)

Rogue Mode allows the client to pair or work independently in another window (separate cursors) in the same tmux session.

It features multi-server support as well as user listing and notifications when users attach/detach.

It is a shellscript wrapper over tmux - no compiling necessary.

Peter
  • 686
  • 4
    Sadly, in April 2021, this appears to be abandonware. – Jesse Adelman Apr 27 '21 at 16:21
  • 1
    @JesseAdelman I disagree. The project is not archived, and after setting up port forwarding and an ssh-server, I was able to use this for pair programming in neovim between two different machines. Also nice that only the host needs to install wemux; the client just uses a plain ssh-client to connect. – TamaMcGlinn Jul 15 '21 at 08:24
  • 1
    (I understand the reaction, given it hasn't had an update since 2014 - but evidently this piece of software is simple enough that it just keeps working) I used it on Ubuntu 20. – TamaMcGlinn Jul 15 '21 at 08:26
  • 2
    So, when I say 'abandonware', I mean 27 GitHub Issues not addressed, and 9 Pull Requests uncommented on, and 6 years since the last update. Based on the definition here: https://en.wikipedia.org/wiki/Abandonware I think this repo's software meets the criteria. :) Cheers. – Jesse Adelman Jul 16 '21 at 20:45
  • 1
    The https://github.com/zigdon/wemux fork is active. – Douglas Royds Dec 08 '22 at 20:21
27

I've tried this on Ubuntu but don't see why it wouldn't work on other unix variants.

If both users are members of a common group and the socket-path uses that group both users will be able to attach fine.

Rather than having to change the permissions of the socket-path every time you create one you could create a specific directory for sockets (I used /var/tmux).

First add a group for tmux users

$ addgroup $TMUX_GROUP

Create a directory with the group set to $TMUX_GROUP and use the setgid bit so that files created within the directory automatically have the group set to $TMUX_GROUP.

$ mkdir /var/tmux
$ chgrp $TMUX_GROUP /var/tmux
$ chmod g+ws /var/tmux

Next make sure the users that want to share the session are members of $TMUX_GROUP

$ usermod -aG $TMUX_GROUP user1
$ usermod -aG $TMUX_GROUP user2

Now you create a shared session with

$ tmux -S /var/tmp/shared-session

and attach to it from another account with

$ tmux -S /var/tmp/shared-session attach
ntc2
  • 146
Stephen Paulger
  • 371
  • 4
    If you have a filesystem that supports ACLs, you don't need to use a group (and in particular you don't need any root intervention). But this doesn't solve the issue of sharing the tmux configuration, does it? – Gilles 'SO- stop being evil' Apr 11 '11 at 20:15
  • 5
    To create shared sesion: tmux -S $TMUX_GROUP/shared-session. To attach to it from another account: tmux -S $TMUX_GROUP/shared-session attach – jfs Sep 20 '16 at 17:14
  • 2
    The comment above (by @J.F.Sebastian) should be part of the answer. The setup proposed is ok, but the answer falls short when explaining how to real use it. And for all answers in this page, this answer is the one that better address the problem. – DrBeco Jul 16 '17 at 00:07
  • 2
    I was not successful with tmux -S $TMUX_GROUP/shared-session ("lost server) but was successful with tmux -S /var/tmux/shared-session (after logging out and logging back in) – Jason Dufair May 25 '21 at 13:30
  • I updated the answer to include jfs suggestion, but corrected per the jason-dufair comment. – ntc2 Jul 20 '21 at 06:06
14

This is not exclusive to tmux, but right now it's what I'm using:

You can use script -f /path/to/some/file to write a terminal session to a file. The -f option updates the file while you type.

Someone else (with only read permissions to the file, if you want) can do tail -f to see the file, your terminal session. The -f option makes tail output whatever gets appended.

The combination of the two "sync" the view of a terminal. When used whith tmux, it also has the advantage of avoiding the resize that happens when both users have different resolutions. Another trait is that each user can work on another private window or session.

One potential inconvenience is that some commands (ncurses based for example) may do weird things to the output, escape sequences too (colors). However, I am using this inside tmux, and it seems that tmux fixes those issues. I can see the other user read man pages and use other commands that create buffers, colors are displayed right, etc.

This does not allow to write to each other's terminal though (maybe some other solution could be added for that).

I like to have a window with two panes: one pane running script -f for my peer to see, an another one next to it where I tail -f it's terminal.

It works in ttys as well (and sockets or named pipes may be used too for the file)

0xC0000022L
  • 16,593
ferhtgoldaraz
  • 657
12

As far as I know, it is not possible to share sessions with other users in a "clean" way.

Also read-only access is not possible, if the client doesn't use the -r switch.

As another terminal multiplexer screen supports the features you are looking for, sadly also in a cumbersome way... I'm not sure if this is an option for you, but maybe someone other will find this useful.

Solution for screen:

Host a session:

  • SUID bit of screen must be set :-/
  • Open the session with screen -S sessionname
  • ctrla + :multiuser on
  • ctrla + :acladd otherUsername

Join a session:

  • screen -x username/sessionname

You can set permission bits for the user (* for all) with :aclchg or :chacl. # appended will affect windows, ? appended will affect the commands.

Examples:

  • :aclchg * -wx "#,?" will set the session permissions to read only for all users
  • :aclchg foo +w 2 will give write access for user foo on window 2
  • :aclchg bar +x detach will give the permission for detaching a session to user bar
echox
  • 18,103
  • 1
    For what it's worth, I feel that the tmux solution (although slightly more verbose) is actually "cleaner", since it doesn't involve leaving setuid binaries floating around the filesystem. – Glyph Dec 22 '10 at 21:01
  • Unfortunately, tmux used this in this way has a security issue: those to whom you give access can easily create new sessions and do things in them that you're not seeing. – cjs Sep 05 '11 at 05:37
  • @CurtJ.Sampson How about if the user is forced to run "attach -r", such as through a restricted shell? – Max Barraclough Dec 29 '19 at 00:37
2

There's a very handy tool, it's tmate.

You can use it when you don't have the hand on network, like in a hotel by example.

$ apt-cache show tmate
Package: tmate
[...]
Homepage: http://tmate.io/
Description-en: terminal multiplexer with instant terminal sharing
 tmate provides an instant pairing solution, allowing you to share a terminal
 with one or several teammates. Together with a voice call, it's almost like
 pairing in person. The terminal sharing works by using SSH connections to
 backend servers maintained by tmate upstream developers; teammates need to be
 given a randomly-generated token to be able to join a session.
 .
 tmate is a modified version of tmux, and uses the same configurations such as
 keybindings, color schemes etc.
Gilles Quénot
  • 33,867
2

Here is a quick and dirty way of doing it (similar to your example tho updated with a new necessary step):

on the first user account session run:

# create a tmux session using /tmp/tmux_shared_session socket (automatically create it if it doesn't exits already)
tmux -S /tmp/tmux_shared_session

give group owneship of the tmux socket to the second user


sudo chown $(whoami):SECOND_USER_GROUP_NAME /tmp/tmux_shared_session


give permissions to the second user group


sudo chmod g+rwx /tmp/tmux_shared_session


give the second user the tmux authorization to use the current session (note: you need to run this while inside the tmux session)


tmux server-access -a SECOND_USER_NAME

on the second user account session run:

tmux -S /tmp/tmux_shared_session attach

You will need to replace SECOND_USER_NAME and SECOND_USER_GROUP_NAME in the above commands based on your situation.

note: SECOND_USER_GROUP_NAME is basically always identical to SECOND_USER_NAME

creeloper27
  • 21