Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Let's say you have a program you want to run unattended, as root, which requires a secret (such as a passphrase; something you don't want other people to find out), which can be read from an environment variable. One way of accomplishing this would be to create a script like the following, and run it from root's crontab.

export SECRET='my_secret'
export SECRET=

Okay, so I can think of two security issues here.

First, someone could find the value of $SECRET by reading the script. Using chmod 700 should take care of that.

Second, someone could use something like ps ae while some_program is running. However, if the script is running as root, only root (or sudoers) can see its environment, right?

Am I correct in believing the value of $SECRET can only be found by root or sudoers? Are there other security issues?

And, to make all this a little less abstract, this is what got me thinking.

share|improve this question
up vote 0 down vote accepted

Is this a script that will only ever run on your own box?

Modern Linux defaults environment variables to only being visible to root or yourself, but that's not portable. Various other OSes either can't filter them, or don't filter them by default.

share|improve this answer
Ah, there we go. Now I see why this would be a security problem in the general case. (In my case, this script will only ever run on my box.) – sarnesjo Jan 3 '10 at 15:56

My first thoughts would be to avoid exporting pass-phrases at all times.
duplicity seems has an option '--use-agent' that might help here.

If this option is specified, then '--use-agent' is passed to the GnuPG encryption process and it will turn off any passphrase interaction with the user with respect to '--encrypt-key' or '--sign-key'.

Update: These are my biased opinions.

  • A script should not cause security information to be exported in to the environment
  • If you are not working with a special application (like duplicity),
    it would be easier to avoid the problem from my previous point by just shifting to the user-agent based mechanism (ssh has one for example, and I expected duplicity to have one -- which it did)
  • the secret information is better (in a relative sense) protected with unix-access attributes under the application private data (I refer to things like .ssh/id_dsa)
share|improve this answer
I have some gripes with that answer. ;) 1. It didn't answer my question. I am not trying to make some script more secure, I am trying to understand if and why I should. Sorry if my question was unclear. 2. It only addresses the specific situation where some_program is duplicity. – sarnesjo Nov 7 '09 at 14:05

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.