Re: [PATCH] docs: mention that not all values can be exported

Eric Blake <[email protected]> Mon, 03 Nov 2014 07:21:36 +0100

Newsgroups	gmane.comp.sysutils.autoconf.patches
Organization	Red Hat, Inc.
Message-ID	<[email protected]>

On 09/29/2014 04:44 PM, Zack Weinberg wrote:
> On Sat, Sep 27, 2014 at 8:26 PM, Eric Blake <[email protected]> wrote:
>> There has been a LOT of news about bash's Shell Shock bug lately.
>> Document some of the ramifications it has on portable scripting.
> 
> I think this is a good idea in the abstract, but I think it's maybe a
> little too specific to this particular incident.  Can I suggest
> instead
> 
> +Posix requires @command{export} to work with any arbitrary value for the
> +contents of the variable being exported.  However, some shells have extensions
> +that involve interpreting some values specially.  We currently know of only one
> +case: all versions of Bash released prior to 27 September 2014 interpret
> +an environment variable whose value begins with @code{() @{} as a shell
> +function definition.  (This is the ``Shellshock'' bug, CVE-2014-6271; it was
> +possible to exploit the parser and cause code to execute immediately upon
> +shell startup.  Newer versions of Bash use special environment variable
> +@emph{names} to implement the same feature.)

Thanks for the suggestions.  I incorporated a lot of this wording, and
also mentioned that there is still an inherent ARG_MAX limitation (you
can't shove infinite data through the environment, although modern Linux
has moved towards no arbitrary limit) and on the issues of not being
able to preserve non-shell-name variables created by env when passing
through certain shells.  The result is finally pushed.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc (application/pgp-signature, 539 B)