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)?

Community
  • 1
Neil McGuigan
  • 3,379
  • 1
  • 16
  • 20

3 Answers3

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.

grochmal
  • 5,677
  • 2
  • 19
  • 30
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.

André Borie
  • 12,706
  • 3
  • 39
  • 76
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.

symcbean
  • 18,278
  • 39
  • 73
  • "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 – Neil McGuigan Sep 27 '16 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. – grochmal Sep 27 '16 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 – symcbean Sep 28 '16 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. – grochmal Sep 28 '16 at 17:20