Re: Issue with Bash-4.3 Official Patch 27

[Eric Blake]

On 10/15/2014 11:49 AM, Lorenz.Bucher.ext@rohde-schwarz.com wrote:
> Yes, you got it. I just gave an example to reproduce that Bug. In my case 
> I didn't find the save script/binary yet. 
> I use unset -f function as workaround. 
> 
> But anyway.
> In my opinion I should trust a shell not violating their own rules and be 
> able to import their own variables.
> So the % character should be allowed to be used in variable names.

No, it should not.  POSIX is already explicit that applications MUST be
prepared to tolerate garbage in the environment (by ignoring or purging
names that they don't like):

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html
"These strings have the form name=value; names shall not contain the
character '='. For values to be portable across systems conforming to
POSIX.1-2008, the value shall be composed of characters from the
portable character set (except NUL and as indicated below). There is no
meaning associated with the order of strings in the environment. If more
than one string in an environment of a process has the same name, the
consequences are undefined.

Environment variable names used by the utilities in the Shell and
Utilities volume of POSIX.1-2008 consist solely of uppercase letters,
digits, and the <underscore> ( '_' ) from the characters defined in
Portable Character Set and do not begin with a digit. Other characters
may be permitted by an implementation; applications shall tolerate the
presence of such names."

That said, one of the proposals on this list is to add a _single_ new
environment variable, maybe named BASH_FUNC_EXPORTS, that contains a
list of all exported functions (and maybe even a sanity check prefix
stating how many functions are in the list, to make parsing a little
more robust), so that people can easily whitelist or blacklist a single
environment variable name/value pair to cover all functions, and so that
bash is no longer sticking non-portable names in the environment.  By
having a SINGLE known-special variable, we still avoid the Shellshock
vulnerability (the problem there was that the namespace that triggered
special handling was infinite, and therefore caused collisions with
regular variables and difficulty in blacklisting when sanitizing across
a security boundary).

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

signature.asc
Description: OpenPGP digital signature