[CDBUG-talk] Sysadmin blog
bcallah at devio.us
Sun Nov 16 23:06:48 EST 2014
On 11/16/14 22:49, Jaime wrote:
> On Sun, Nov 16, 2014 at 10:24 PM, Brian Callahan <bcallah at devio.us> wrote:
>>> 1) Isn't the shebang that you suggested still hardcoded? When the
>>> script is taken to a new OS, wouldn't there still be a risk of it
>>> breaking? Has env just been in Unix for so long that its always in
>> You're right: env is not guaranteed to be in /usr/bin but it is the
>> historical location of env, so it will work on Linuxes and BSDs (and afaik,
>> Solaris/AIX/HP-UX). Pretty much it's an anomaly if env isn't in /usr/bin and
>> it's also extremely likely bash, if available, wouldn't be in /bin on such a
>> system anyway!
> Gotcha. So the path of env is more consistent across different OSs
> than bash's is. Therefore, its just more likely to work without
> modification due to this "accident" of history. Do I understand?
I wouldn't call it an accident, but yes that's correct.
>> Because env searches your PATH, you could install a newer/custom bash
>> (remember shellshock?) elsewhere and have your scripts use that new bash
>> without editing the script (provided your PATH is set up to hit the new bash
> Its funny that you bring up shellshock. I was just wondering if using
> env would increase the likelihood of running a malicious program that
> happened to be called "bash" if a user managed to put it into my $PATH
> So which approach is safer from malicious attack? Using env and
> trusting your $PATH (and its contents) hasn't been adjusted or hard
> coding to a known interpreter such as /usr/bin/bash?
It's not 1999 any more... we don't use rsh, we don't say swap must be
Though I kinda wish it was 1999, I liked Mac OS 8 and Mac OS 9.
More information about the CDBUG-talk