]> git.ipfire.org Git - thirdparty/autoconf.git/commitdiff
docs: mention that not all values can be exported
authorEric Blake <eblake@redhat.com>
Sun, 28 Sep 2014 00:24:06 +0000 (18:24 -0600)
committerEric Blake <eblake@redhat.com>
Mon, 3 Nov 2014 06:17:15 +0000 (07:17 +0100)
There has been a LOT of news about bash's Shell Shock bug lately.
Document some of the ramifications it has on portable scripting.

* doc/autoconf.texi (Limitations of Builtins) <export>: Add some
details about Shell Shock CVE-2014-6271.

Signed-off-by: Eric Blake <eblake@redhat.com>
doc/autoconf.texi

index e2137aee3b00dc391588d5c933edf633b11f3097..ace1675e8413dfba1d60f06cf6f9cf20246be315 100644 (file)
@@ -17668,6 +17668,29 @@ $ @kbd{/bin/sh -c 'export foo; foo=bar; echo $foo'}
 bar
 @end example
 
+Posix requires @command{export} to work with any arbitrary value for the
+contents of the variable being exported, as long as the total size of
+the environment combined with arguments doesn't exceed @code{ARG_MAX}
+when executing a child process.  However, some shells have extensions
+that involve interpreting some environment values specially, regardless
+of the variable name.  We currently know of one case: all versions of
+Bash released prior to 27 September 2014 intepret an environment
+variable with an initial content substring of @code{() @{} as an
+exported function definition (this is the ``Shellshock'' remote
+execution bug, CVE-2014-6271 and friends, where it was possible to
+eploit the function parser to cause remote code execution on child bash
+startup; newer versions of Bash use special environment variable
+@emph{names} instead of values to implement the same feature).
+
+There may be entries inherited into the environment that are not valid
+as shell variable names; Posix states that processes should be tolerant
+of these names.  Some shells such as @command{dash} do this by removing
+those names from the environment at startup, while others such as
+@command{bash} hide the entry from shell access but still pass it on to
+child processes.  While you can set such names using @command{env} for a
+direct child process, you cannot rely on them being preserved through an
+intermediate pass through the shell.
+
 @item @command{false}
 @c ------------------
 @prindex @command{false}