On Mon, Mar 18, 2019 at 05:18:10PM -0400, Daniel Kahn Gillmor wrote: > strace -o tmp/bash.herestring.strace -f bash -c 'cat <<<"hello there"' > It turns out that this creates a temporary file, actually touching the > underlying filesystem:
Yes, just like here documents do. And have always done, in all shells. > For example, sending a password or secret key material from the > environment to stdin would be a typical way to use a herestring. Note that the environment may also be visible to users on the system, via "ps eww aux" or similar commands. The availability of the BSD ps(1) options and the details about who can see what are OS-specific. > A few possible options for trying to improve the situation: Don't put sensitive data in shell scripts? In general: 1) Do not pass secrets as arguments to external commands. The arguments of a command are generally visible in ps(1). 2) Do not pass secrets as environment variables. The initial environment of a process is generally visible in ps(1). 3) Read the documentation of the thing you're trying to authenticate against. Find out the various ways it can accept authentication secrets/tokens and choose the most appropriate. This may mean using ssh keys stored in an ssh-agent, etc. 4) If something requires a password, let it prompt the user for the password by itself. Just run it inside a terminal so that it can launch a dialog with the end user if required. Do not try to "help" it by storing the password in your script and then trying to figure out how to circumvent its security in order to pass the password to it. 5) If you absolutely MUST store a password somewhere on disk, don't store it inside the shell script. Shell scripts must have read permissions in order to be used. Store the password in a separate file that doesn't have universal read permission, and let the appropriate process read that file. The appropriate process may be your script in rare cases, but more often it'll be whatever program is actually going to use that password. Thus, there is absolutely no reason you should ever have a secret password inside a here document or here string. That would mean the password is hard-coded inside a shell script, which violates several of my points. If the password has been read from a file and is now inside a shell variable (NOT environment variable) in memory, and you want to pass it on stdin to a process, you do that by running something like printf %s\\n "$secret" | program No here strings are wanted. printf is a builtin, so you aren't violating point 1. $secret is not exported, so you aren't violating point 2. https://mywiki.wooledge.org/BashFAQ/069 and https://mywiki.wooledge.org/BashFAQ/078 also touch on this, but they could both use some expansion/rewriting, I see.
