Bug 1148507 - Importing Exported Functions with Hyphens
Summary: Importing Exported Functions with Hyphens
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: bash
Version: 6.5
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Ondrej Oprala
QA Contact: Jan Kepler
URL:
Whiteboard:
Depends On:
Blocks: 1159820 1237213
TreeView+ depends on / blocked
 
Reported: 2014-10-01 15:32 UTC by cperl
Modified: 2019-07-11 08:13 UTC (History)
5 users (show)

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.
Clone Of:
: 1237213 (view as bug list)
Environment:
Last Closed: 2015-07-22 06:10:39 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:1277 normal SHIPPED_LIVE bash bug fix update 2015-07-20 17:49:11 UTC

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):

bash-4.1.2-15.el6_5.2

How reproducible:

Always:

[cperl@localhost /tmp]$ rpm -qa bash
bash-4.1.2-15.el6_5.2.x86_64
[cperl@localhost /tmp]$ foo-bar () { echo a; }
[cperl@localhost /tmp]$ foo-bar
a
[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
Hi,
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.

https://rhn.redhat.com/errata/RHBA-2015-1277.html


Note You need to log in before you can comment on or make changes to this bug.