1

If there are no sessions (eg tmux a returns "no sessions") a call to start tmux under a namespace (eg sudo ip netns exec ns1 tmux new -s test) will have the shells within (even newly spawned ones) respect the namespace (eg ip a will only list the interfaces belonging to the namespace).

Forgetting the issue that in the above example has tmux running under root (which can be dealt with but convolutes the question), subsequent tmux executions calling for a new session under a different (or no-) namespace result in shells that run under the original namespace (eg sudo ip netns exec ns2 tmux new -s test2's ip a yields ns1's interfaces).

How can I run a sequestered session if the tmux server already has a session running?

Improve this question

1 Answer 1

Reset to default
2

It's kind of obvious with that last line, but the solution is to force a new server to run, even if it's the same user.

Use the option -S to specify a unix socket for tmux to run on (defaults to /tmp/tmux-`id -u $USER`/default)

So whenever you want to use a specific namespace (as your own user) I'd run

sudo ip netns exec $namespace sudo -u $USER tmux -S /tmp/$namespace.tmux $tmuxArguments

So long as you don't exit any final session on a particular server, you can simply call tmux -S /tmp/$namespace.tmux $tmuxArgs (whether those args are a existingSession or new -s newSession) they will have shells running under the respective namespaces without sudo ip netns exec!

Improve this answer
8
  • 1
    +1 nice solution (and good question), but you should a) double-quote your variables, and b) use an array for $tmuxArguments - a single string var containing space separated options kind of works but is very fragile and inflexible (there are some things, esp involving args which need to be quoted, that are easy to do using array elements but very difficult with just a single string). e.g. sudo ip netns exec "$namespace" sudo -u "$USER" tmux -S "/tmp/$namespace.tmux" "${tmuxArguments[@]}" Commented Oct 7 at 5:00
  • 1
    I used to advise "Double-quote your variables except in the few rare instances when you know you want the shell to do word-splitting (e.g. to pass multiple args to a program)". Now my advice is "Always double quote your variables. Use an array where you might otherwise be tempted to rely on shell word-splitting (e.g. to pass multiple args to a program)" Commented Oct 7 at 5:00
  • @cas I use powershell, this isnt an issue. $var is always a single parameter, and if you deliberately want it expanded you have to do that consciously. If you tried to use the above example verbatim in my scripts, $tmuxArguments would just be a single string and wouldnt do much (basically only permitting a or new). No mention of bash in this post! Commented Oct 7 at 6:02
  • You can see I'm pretty diligent about that if I am forced to work within bash, even deliberately using single 's if I know no variables are meant to be interpreted at all Commented Oct 7 at 6:11
  • 1
    When using -S, tmux doesn't check the ownership and permission of the path components, so using a socket with a fixed name in a world writable directory is very unsafe and could allow another user on the system take over the account. Better would be to use the -L option instead. Commented Oct 7 at 6:13

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.