2014-09-27 22:48:44 -0600, Eric Blake: > On 09/27/2014 08:50 PM, Chet Ramey wrote: > > BASH PATCH REPORT > > ================= > > > /* Don't import function names that are invalid identifiers from the > > environment, though we still allow them to be defined as shell > > variables. */ > > ! if (absolute_program (tname) == 0 && (posixly_correct == 0 || > > legal_identifier (tname))) > > ! parse_and_execute (temp_string, tname, > > SEVAL_NONINT|SEVAL_NOHIST|SEVAL_FUNCDEF|SEVAL_ONECMD); > > This patch forbids importing function names containing '/' (yay!), and > we already established that bash has never been able to properly import > functions with names containing '='. But I'm assuming there will need > to be a followup patch to actually reject the attempt to create such > function names (that is, "bash -c 'a/b () { echo oops; }; a/b'" should > issue an error message instead of printing "oops"), so that we do not > have the confusing situation of being unable to pass all permitted > function names through an export/import cycle. [...]
I'd say it's unfortunate that the fix for CVE-2014-6271 removes the support for exporting functions with slash in their name. functions share the same namespace as other commands (and not as variables which is also why the original implementation of function exports was flawed/inconsistent), so it would make sense to allow any name for a function. Exported functions was a usefully debugging tool. You could do things like: env rm='() { [ "$1" = want-to-keep ] || command rm "$@"; } ' /bin/rm='() { [ "$1" != want-to-keep ] && command rm "$@"; } ' my-command To avoid want-to-keep be removed by my-command eventually running system("/bin/rm want-to-keep"). I guess I'll have to switch to zsh now (using $ZDOTDIR/.zshenv) for this kind of trick. In zsh, any function name is allowed, even the empty string, even those with spaces or NUL characters, using quoting: $'\0' () echo I am the nul command Or 'my command' () echo spaces in my name... Forbidding functions (even importing them) with those names doesn't bring any significant security benefit AFAICT. >From what I understand, it was done as a simple fix to avoid problems with env vars whose name contains shell code and because bash parser does not support defining functions with arbitrary names like zsh does. A better fix, IMO, would have been to allow any name in a function name, or allow the same names from imported functions as for functions declared normally. I'd agree that if you can no longer import them, not allowing declaring them would make sense, but might break existing scripts which rely on that ability. Also, as I said before, what is deemed a valid identifier is locale specific (and there's a bug in that it only works properly in single-byte locales), so one can still make locales where "("` or "=" are part of valid identifiers. -- Stephane