[Proposal]: Use host TERM environment variable when starting TTY

[kazkansouh]

Summary

This is a feature request for the cli to automatically pick up the hosts TERM environment variable and assign it to the container when starting with -t (tty) flag. I.e. in effect implicitly add -e TERM=${TERM} to the command line arguments when -t is present.

The current situation is to apply a default of value xterm in the engine, and this is clearly documented.

Justification

When running an interactive container from the command line its possible for the cli to pick up the correct TERM value and assign it to ensure any text editors, tools that use readline, ncurses, etc, work correctly out of the box - this should not affect the default defined in the engine that seems reasonable.

For me, I use tmux so often find small issues with key bindings due to the default of xterm.

$ echo ${TERM}
screen-256color

$ docker run -t -i --rm  alpine:latest /bin/sh -c 'echo ${TERM}'
xterm

$ docker run -t -i --rm  -e TERM=${TERM} alpine:latest /bin/sh -c 'echo ${TERM}'
screen-256color

I see two possible concerns:

1. Running older containers might not support the same as that used on the host, esp. w.r.t. the -256color.
2. Security risk of implicitly using a host's environment variable. E.g. running an older container that is vulnerable to something like shellshock.

[alemax-xyz]

Current implementation is incorrect, it deserves a separate bug... and there is one #2189 (more or less).

For those, looking for a workaround: docker run -t -eTERM ... does the trick.

I'm commenting here, since implementing this "proposal" will actually close all related bugs.

Currently, Docker tells apps that it knows for sure there is an xterm running on the client. It should either tell "I don't know" by not setting it, or tell the truth by passing it through.

Yes, it is documented. -t attaches containers stdin/stdout/stderr to the current (host) tty. Current (host) tty capabilities are identified by the TERM environment variable on the host (set by the client terminal app). Setting it to xterm in the container does not make any sense, since Docker has nothing to do with the terminal app.

As I understand, TERM=xterm was done to prettify the output of the commands. For this purpose TERM=ansi does the job as well, but it is considerably more reliable choice, however still breaks things.

xterm has quite a few custom/proprietary sequences which are different from a other terminals. Here is a pretty good material on the topic from ncurses themselves: Why not just use TERM set to “xterm”?

Consider a pretty common environment: linux server (host) running docker, windows with putty or mac as a client ... there is no xterm whatsoever ... This is enough to cause malfunctioning of some apps. Add screen or tmux on top and you have it pretty broken.

man tmux states that care must be taken not to reset this (referring to the TERM variable).

---

Running older containers might not support the same as that used on the host, esp. w.r.t. the -256color.

Currently, properly configured containers malfunction. After fixing it, improperly configured containers MAY malfunction. In other words, it will finally work as expected.

Security risk of implicitly using a host's environment variable. E.g. running an older container that is vulnerable to something like shellshock.

shellshock is a security risk for the underlying application that uses the variable(s). Isolation with Docker is not a fix, it is a workaround. The underlying application should be patched, and Docker has nothing to do with it. Docker's job is to properly inform containers about the environment it is attached to.

For instance, OpenSSH, which is (arguably) more sensitive to security vulnerabilities, explicitly passes TERM variable through (alone with LANG, TZ and some others). #2189 (comment) describes how OpenSSH implements it.