[CDBUG-talk] Sysadmin blog

[Brian Callahan]

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
>>> /usr/bin?
>> 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
>> first).
> 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
> somehow.
>
> 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 
2*RAM either...
Though I kinda wish it was 1999, I liked Mac OS 8 and Mac OS 9.

~Brian