On 10/15/2014 11:49 AM, lorenz.bucher....@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
