Re: Healing the bash fork

[Florian Weimer <fweimer () redhat com>]

On 09/30/2014 05:11 AM, gremlin () gremlin ru wrote:
> On 29-Sep-2014 22:34:20 -0400, Chet Ramey wrote:
>
>   >> What is the motivation to not store executable code (functions)
>   >> differently from standard variables?
>
>   > What would you use for such a store, considering the environment
>   > is the only portable way to pass this information from one process
>   > to another in the general case, and support the current set of
>   > use cases?
>
> C.O. to the rescue: temporary file.

You cannot use a named temporary file because the creator does not know 
its required lifetime.  That's a challenge all solutions not based on 
the process environment will face.

Theoretically, you could pass an unnamed temporary file via a file 
descriptor, and communicate the descriptor number in some safe way (but 
what's that, if you don't trust the environment?).  But that's going to 
be far less interoperable than what we currently have, and barely more 
secure.

> If one shell instance needs to pass some functions to another, it
> could dump those functions to a temporary file and pass the --load
> (or, better, --load-functions) options with a filename parameter.

We need to keep support exporting functions to grandchildren through 
non-bash processes (that is, bash -> some-other-program -> bash).

--
Florian Weimer / Red Hat Product Security