Bug 1148507

Summary: Importing Exported Functions with Hyphens
Product: Red Hat Enterprise Linux 6 Reporter: cperl
Component: bashAssignee: Ondrej Oprala <ooprala>
Status: CLOSED ERRATA QA Contact: Jan Kepler <jkejda>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 6.5CC: dkutalek, fweimer, jkejda, johnlcf, ovasik
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Fixed In Version: bash-4.1.2-32.el6 Doc Type: Bug Fix
Doc Text:
Prior to this update, Bash refused to import previously exported functions whose names contained a hyphen. As a consequence, scripts that used such functions did not work properly, and Bash printed the following error message: bash: error importing function definition for `BASH_FUNC_function-name' With this update, Bash accepts hyphens in the names of imported functions.
Story Points: ---
Clone Of:
: 1237213 (view as bug list) Environment:
Last Closed: 2015-07-22 06:10:39 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 1159820, 1237213    

Description cperl 2014-10-01 15:32:57 UTC
Description of problem:

Importing of functions that were previously exported with `export -f' fails if the function name contains a hyphen (i.e. '-').

Version-Release number of selected component (if applicable):


How reproducible:


[cperl@localhost /tmp]$ rpm -qa bash
[cperl@localhost /tmp]$ foo-bar () { echo a; }
[cperl@localhost /tmp]$ foo-bar
[cperl@localhost /tmp]$ export -f foo-bar
[cperl@localhost /tmp]$ bash
bash: error importing function definition for `BASH_FUNC_foo-bar'
[cperl@localhost /tmp]$ 

Actual results:

Importing of previously exported functions whose name have a hyphen in them fails.

Expected results:

Importing of previously exported functions whose name have a hyphen in them should work.

Additional info:

This has been discussed in a few places already [1][2].  However, it looks like the latest upstream patch at [3] (bash 4.3, patch 27, git commit 3590145af6f1c9fa321dff231f69ae696e7e740b) actually fixes this.

I believe the relevant part of the patch is:

-         if (legal_identifier (name))
-           parse_and_execute (temp_string, name, SEVAL_NONINT|SEVAL_NOHIST|SEVAL_FUNCDEF|SEVAL_ONECMD);
+         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);

Would it be possible to release a new bash 4.1 package for RHEL 6.5 with the patch updated to accommodate this change?

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1148318 (this is for fedora, which is why I'm opening this bug)
[2] https://lists.gnu.org/archive/html/bug-bash/2014-09/msg00186.html
[3] git://git.savannah.gnu.org/bash.git

Comment 2 cperl 2014-10-02 16:13:44 UTC
I also have a valid support contract, so if it will get more traction, I can open an official support ticket, I just thought it would be useful to put this in the public bugzilla to help others out there googling for answers.

Comment 3 cperl 2014-10-13 19:44:26 UTC
Any thoughts on this one way or the other?

Comment 4 Ondrej Oprala 2014-10-20 08:40:02 UTC
I think Florian explained it very well in the Fedora bug.
However, bash-4.3-27 doesn't fix the hyphen "ban".

> Would it be possible to release a new bash 4.1 package for RHEL 6.5 with the
> patch updated to accommodate this change?

I really don't think this would make it into z-stream. We try to coordinate as much as possible with usptream, so if they decide to allow function names with hyphens, we can do that as well, but that would probably appear in a release later than 6.5.

Comment 5 cperl 2014-10-20 12:31:00 UTC
Upstream's 4.3 patch 27 *does* fix the "hyphen ban."  That's the point of this ticket.  I believe the original fix for CVE-2014-6271 that florian was referencing was bash 4.3 patch 25.

The diff I included in the original comment was part of the difference introduced in bash 4.3 patch 27, which changes the requirement on the function name from passing `legal_identifier()' (as alluded to by florian and the thing that reject the hyphen) to instead saying "Is it an absolute pathname?  Then fail.  Else, are we in posix correct mode?  Then it must pass `legal_identifier()', else take it).

Comment 10 errata-xmlrpc 2015-07-22 06:10:39 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.