Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bash scripting across linux and solaris



On Fri, Aug 28, 2009 at 10:08 AM, Derek Martin<invalid-yPs96gJSFQo51KKgMmcfiw at public.gmane.org> wrote:
>
> Bash, when invoked as bash, looks for the variable $BASH_ENV and
> sources this file whenever it starts in non-interactive mode (i.e., a
> shell script). ?Suppose you have a program that purges the invironment
> of possibly dangerous environment variables, and in the course of
> doing whatever it does, it runs a shell script. ?Your script, invoked
> as bash, finds the $BASH_ENV variable, and sources that file, quite
> possibly re-setting the environment variables that were culled from
> the environment. ?In a security-sensitive context, this could
> potentially be a serious problem...

The bash -p flag is your friend in this scenario.

> But it's actually worse than that, even. ?Suppose you implement the
> "which" command as a bash script (as Debian sarge did, originally).
> Then, a user puts something like this in his .profile:
>
> export BASH_ENV="my_env_file"
> vi=`which vi`
>
> And in my_env_file, the user also has something like:
>
> vi=`which vi`

I'm not really sure why you would want to do this.

> Also note that if your or .bashrc has commands in it that produce
> output to your terminal, then very likely if you scp files to that
> machine, the scp will fail.

Not sure why you would do this either.

> Speaking from a portability perspective, these days, most Unix systems
> have the actual Bourne shell hidden away somewhere, and /bin/sh is
> actually the vendor's implementation of the "Posix" shell, which is
> very bash-like (and often enough is actually bash). ?Debian and
> debian-derived Linux distros are notable exceptions;

Yes, because bash is POSIX-compliant.  The only argument I can see for
not symlinking sh to bash is if you're concerned about script
execution performance, in which case you can just install dash (which
is lighter and faster with fewer dependencies) and symlink sh to that.

> Obviously, I disagree. :) ?The better option IMO is to learn to write
> portable shell scripts, and use /bin/sh.

If you've written what you believe to be a portable script using
/bin/sh, there's very little chance that it will not "just work" on a
system that symlinks sh to bash.







BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org