3

UPDATE: I know that environment variables are generally secure, and am familiar with this question. My question is can other users see them if they are entered as part of a command (same line, no semi-colon), seeing as command line options are not secure. Normally env vars are entered as a distinct command, on their own line.

You can enter environment variables just before a command like this:

# FOO=bar some-command

(ie, all in one line, no ;, not in separate commands)

is FOO=bar visible to other users (in Unixy systems)?

Improve this question
0

3 Answers 3

Reset to default
2

I fully agree with @AndreBorie, you have the shell history where the command will be logged together with the variables. e.g.

$ FOO=bar echo 3 3 $ history 2 674 FOO=bar echo 3 675 history 2

You can disable that with set +o history for bash or the POSIX way with set -o posix; set -o nolog (which does not work in either bash or zsh according to my tests).

On Linux you have two more files of interest: /proc/<PID>/environ and /proc/<PID>/cmdline. The environment file is safe from other users:

$ ls -l /proc/self/environ -r-------- 1 grochmal users 0 Sep 28 00:51 /proc/self/environ

But the command line file, not quite:

$ ls -l /proc/self/cmdline -r--r--r-- 1 grochmal users 0 Sep 28 00:51 /proc/self/cmdline

Fortunately the Linux folks have been there and the cmdline file does not log the environment variables passed:

$ cat -v /proc/self/cmdline cat^@-v^@/proc/self/cmdline^@ $ FOO=bar cat -v /proc/self/cmdline cat^@-v^@/proc/self/cmdline^@

The important thing about /proc/<PID>/cmdline is that it is from here that ps takes its information about processes' command lines. Therefore these variables will not be seen in something like ps aux or ps -afe.

Improve this answer
1

The command may end up in your shell's history. Depending on the permissions of the history file it may present a security risk. It will also be written to the disk which may pose a risk for transient secret data that's not supposed to exist anywhere once it's used (think TLS perfect forward secrecy keys).

You can inhibit this behavior by configuring your shell to disable history or by prepending the command with a space.

Improve this answer
2
  • The prepend with a space is a cool trick +1, just FYI it doesn't work on OSX Commented Sep 28, 2016 at 1:04
  • Using bash on CentOS 6.8 and Ubuntu, prepending a space to a command does not prevent it from being logged. Commented Apr 3, 2017 at 6:27
0

No. The variables in a program environment must be explicitly exported to be incorporated into a child processes environment, and each process can only read its own environment. An exception to this is where the OS exposes the environment as is the case in the linux proc pseudo filesystem. Here a processes' environment can be read as a file, assuming permissions allow - however by default files are 0600 i.e. only reaadable by the uid of the process to which the file belongs.

The processing of the declaration is handled by the shell itself and does not intrinsically create a new process readable using (for example) ps; if the variable was assigned by a new process its value would be lost when that program exited and its environment destroyed.

Improve this answer
4
  • "a program environment must be explicitly exported to be incorporated into a child processes environment" I'm not sure what that means in reference to my question Commented Sep 27, 2016 at 23:03
  • That's wrong info. On any POSIX compatible shell you can add the variables on the command line and they will be set by the shell after the fork() but before the exec() call. Commented Sep 27, 2016 at 23:43
  • ...only if they are marked for export. Try it: TESTVAR=something \n bash \n echo $TESTVAR \n exit \n export TESTVAR \n bash \n echo $TESTVAR \n Commented Sep 28, 2016 at 10:26
  • But it is meant on the same command line. Try this: unset TESTVAR; echo -n '$TESTVAR='; TESTVAR=yay bash -c 'echo $TESTVAR'. Note that the single quotes prevent expansion but they're dropped before reaching the inner shell. Commented Sep 28, 2016 at 17:20

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.