Forwarding environment variables with tmux new-session

[Erotemic]

I'm looking for a way to forward environment variables in a current shell to new detatched sessions. The environment variables in question are secret, so I want to avoid any logging of their values. The names of the sensitive environment variables are known and are not secret, so they can appear in command history logs.

Context

I'm writing a Python module called cmd-queue, which executes DAGs of bash commands. It currently has 3 backends. 1. A no-dependency serial mode where all commands are executed in-order in the current shell. 2. A slurm backend for heavyweight scheduling jobs - if you have the patience to set it up, and 3. a custom tmux backend which has become my goto-backend due to its simplicity and ease of use. In this case I use tmux new-session to create a new session for each "worker" and tmux send to send each worker their list of tasks, which comes down to sourcing a bash script that has all of the tasks written out. In some cases users will have secrets in their main shell's environment, and I need to securely pass those to new sessions without writing them to the bash scripts (this is the current workaround that I'm doing, but I'd really like to avoid logging secrets) or using the values of environment variables in the bash commands I'm using to drive tmux (because these commands get logged).

Previous Research

Based on references I found:
https://unix.stackexchange.com/questions/743817/how-to-start-tmux-in-a-way-that-it-inherits-all-environment-variables-from-the-c
https://stackoverflow.com/questions/20701757/tmux-setting-environment-variables-for-sessions

I've been able to get close to what I need, but not exactly.

Partial Solution 1

I can use the -L command to forward an environment variable - importantly without specifying its value.

export MYVAR1=123
export MYVAR2=456
tmux -L MYVAR1 -L MYVAR2

Then in the new attached session the environment variables are available.

echo $MYVAR1
echo $MYVAR2

However, the problem with this option is that I immediately attatch to the session. I need to be able to start a new session without attaching to it, so I can keep executing commands in my current shell to create more new sessions and drive them.

Partial Solution 2

It is possible to specify environment variables to tmux new-session with the -e flag, however, it requires that you also specify the value.

# Can start a new session with a specific environment variable
export MYVAR1=123
tmux new-session -d -s my_session_id -e "MYVAR1=$MYVAR1" -- "bash"

# Show the environment of the new sesssion
tmux show-env -t my_session_id

tmux ls
tmux kill-session -t my_session_id

As previously stated, the text of each command is logged, and I don't want the secret value to appear in the logs, so this wont work either.

Summary

Did I understand what functionality currently exists correctly? Or did I miss something? Is there an existing way to specify which enviornment variables from the current shell should be forwarded to a new tmux session without writing the values of those variables to disk or using them in the command itself (forwarding the entire environment would also be acceptable)? If not, is that a feature that could be implemented?

Also, is tmux -L MYVAR doing what I think and not writing the value $MYVAR directly to disk? If that is true, is there any reason the same feature can't be ported to the new-session command?

[nicm]

I don't think you understand what -L does because it has nothing to do with environment variables.

You can put the variables in update-environment and they will be copied from the client environment, but there is no way to stop the environment variable ending up in the tmux global or session environment where anyone can inspect them (other than using -e).

Your best bet would either be to use -e and not log the commands, or to create a temporary script with appropriate permissions that does something like:

#!/bin/sh
trap 'rm /tmp/abcdef.sh' 0 1 15 
export FOO=abc
export BAR=def
exec $SHELL

Then run tmux new /tmp/abcdef.sh.

[Erotemic]

I definately don't have a feel for what -L is doing. I saw it in the context of the above reference (https://unix.stackexchange.com/questions/743817) but when I went to go look at what it is, the help says:

     -L socket-name
                   tmux stores the server socket in a directory under TMUX_TMPDIR or /tmp if it is unset.  The default socket is named default.  This option allows a
                   different socket name to be specified, allowing several independent tmux servers to be run.  Unlike -S a full path is not necessary: the sockets are
                   all created in a directory tmux-UID under the directory given by TMUX_TMPDIR or in /tmp.  The tmux-UID directory is created by tmux and must not be
                   world readable, writable or executable.

                   If the socket is accidentally removed, the SIGUSR1 signal may be sent to the tmux server process to recreate it (note that this will fail if any par‐
                   ent directories are missing).

My knowledge on sockets is limited, so I can't say I understand what's going on above, but it is true that if I run:

# CASE 1
export MYVAR=456
tmux
## Inside session
echo $MYVAR
exit

# CASE 2
tmux -L MYVAR
## Inside session
echo $MYVAR
exit

The new tmux session can see the value of MYVAR in case 2, but not in case 1. So it must have something to do with environment variables - at least implicitly?

---

Writing a file to a physical disk with the environs is probably a no-go, but an in-memory disk might be ok. I can try to think about how to perform that workaround, but I'd also like to understand if this is something that tmux could provide, or if it's completely out of scope.

[nicm]

First one is probably creating a session in an existing server which will use the existing global environment. Second one with -L is creating a new server on a socket named MYVAR which will have a new global environment that includes your exported variables.

[nicm]

Actually, that won't work because exec does not run the 0 trap. So you would need to think of another mechanism to delete the script.

[github-actions[bot]]

This discussion has been automatically locked since there has not been any recent activity after it was closed.