Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 9 Oct 2014 07:17:48 +0100
From: Stephane Chazelas <>
Subject: Re: Thoughts on Shellshock and beyond

2014-10-08 16:05:45 -0700, Michal Zalewski:
> > Well, I guess, but the way you're interpreting this separation of
> > code/data and the way that I am is clearly different.
> > There are clearly cases where separation is  practical,
> > non-destructive, and beneficial for security.
> Well, in the specific context of bash, where it's being singled out as
> a major contributing factor to the bug: how would you establish an
> out-of-band channel for exporting functions that keeps them separate
> from "pure" data? As far as I can tell, there is no trivial and
> portable way.

Just to give the discussion a bit more of perspective, here is
some info on how similar things are done in other shells:

In rc (the plan9, Research Unix v10 shell), all functions are
exported in "fn_funcname" variables that are evaluated on the
first call. rc authors considered it was a mistake of the Bourne
shell not to export all its variables to the environment. It
probably made sense for them to say that at the time. In case
you don't know of that shell, rc is the shell with the
cleanest design. It never picked up because it arrived too late
when the Bourne and C shell were predominant (like Plan9 vs

In the Almquist shell (still in dash and some BSD sh), $PATH
entries that are suffixed with
%func are looked for files with function definitions.
If you have a ~/fun/ls, and PATH=~/fun%func:/bin, and call ls,
~/fun/ls is evaluated and the ls function called instead of the
ls in /bin.

POSIX shells (features comes from ksh) have the ENV variable
which after evaluation (so yes, the parser is invoked on that
variable content) resolves to the path of a file where you can
put function definitions (or anything else). Most shells only do
that when non-interactive though (IIRC that changed because the
feature was abused). bash has BASH_ENV (even for non interactive
shells, but only when invoked as bash, not sh).

You could add a eval "$MY_FUNCTIONS" in there and do export
MY_FUNCTIONS="$(typeset -f myfunctiontoexport)" (I don't know
that it be common practice though).

All csh/tcsh invocations, except when passed the -f option read
the ~/.(t)cshrc. So you could put your alias (csh has no
functions) definitions in there (or source another file
specified in an env var or eval a $MY_ALIASES).

Similarly, zsh has ~/.zshenv (not to be confused with ~/.zshrc),
and $ZDOTDIR to specify where to look for .z*. Again you can
do eval $MY_FUNCTIONS in there.

ksh has $FPATH. like in ash, that's where to look for function
definition files. However, the functions don't take precedence
over  commands unless you add an "autoload thefunction" to your

zsh has a similar feature but the "autoload" is always required
and the files are meant to contain the function body (instead of
the full function definition among other things in ash/ksh).


Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.