oss-sec mailing list archives
Re: Healing the bash fork
From: "Kobrin, Eric" <ekobrin () akamai com>
Date: Mon, 29 Sep 2014 22:26:33 -0500
On Sep 29, 2014, at 10:34 PM, Chet Ramey <chet.ramey () case edu> wrote:
On 9/29/14, 6:06 PM, Kobrin, Eric 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?
The most portable transmission method is the environment. I'm interested in thinking through scenarios where it is not deemed necessary to have one environment variable per function, to store functions text, to support all environment variable manipulations on functions, or to support easy creation of functions in non-bash processes. What are the current set of use cases? I can think of a few, but I'm not sure they are all required; some may be accidental but still widely used, others may be unused and undesired. Here's the list so far, posed as questions: 1. Is it necessary that functions exported in one version of bash be imported into other versions? 2. Is it necessary for exported functions to be able to transition through other processes and back into bash, or is function export intended to support bash-invoked-from-bash only? 3. Is it necessary for non-bash processes to be able to define functions for a bash child? 4. Is it necessary for non-bash processes to be able to import functions from a bash parent? 5. Once a function is defined or imported, is it important that we be able to reproduce byte-for-byte the input that was used to define it? 6. Is it important that bash be required to import every function defined in the parent process? 7. Is it important to signal function import failure at startup time, or is it ok to defer parsing until the first attempt to invoke the function? Does anyone have further use cases to discuss? -- Eric Kobrin
Current thread:
- Re: Healing the bash fork, (continued)
- Re: Healing the bash fork Kobrin, Eric (Sep 29)
- Re: Healing the bash fork Tavis Ormandy (Sep 29)
- Re: Healing the bash fork David A. Wheeler (Sep 29)
- Re: Healing the bash fork John Haxby (Sep 29)
- Re: Healing the bash fork Kobrin, Eric (Sep 29)
- Re: Healing the bash fork Chet Ramey (Sep 29)
- Re: Healing the bash fork gremlin (Sep 29)
- Re: Healing the bash fork Florian Weimer (Sep 30)
- Re: Healing the bash fork Gennady Kupava (Sep 30)
- Re: Healing the bash fork gremlin (Sep 30)
- Re: Healing the bash fork Kobrin, Eric (Sep 29)
- Re: Healing the bash fork Michal Zalewski (Sep 29)
- Re: Healing the bash fork Kobrin, Eric (Sep 30)
- Re: Re: Healing the bash fork Todd C. Miller (Sep 29)
- atd (was: Re: [oss-security] Re: Healing the bash fork) Seth Arnold (Sep 29)
- Re: CVE-2014-6271: remote code execution through bash Solar Designer (Sep 24)
- Re: CVE-2014-6271: remote code execution through bash Chet Ramey (Sep 25)
- Re: CVE-2014-6271: remote code execution through bash Solar Designer (Sep 25)
- Re: CVE-2014-6271: remote code execution through bash Christos Zoulas (Sep 25)
- Re: CVE-2014-6271: remote code execution through bash Solar Designer (Sep 25)
- Re: CVE-2014-6271: remote code execution through bash Chet Ramey (Sep 25)