[asterisk-bugs] [Asterisk 0014231]: [patch] Parsing and escaping of characters is broken in some cases (e.g. app_System)

Asterisk Bug Tracker noreply at bugs.digium.com
Tue Jan 13 12:17:32 CST 2009


The following issue has been UPDATED. 
====================================================================== 
http://bugs.digium.com/view.php?id=14231 
====================================================================== 
Reported By:                jcovert
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   14231
Category:                   Core/Configuration
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
Asterisk Version:           1.6.0.3 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             2009-01-13 11:12 CST
Last Modified:              2009-01-13 12:17 CST
====================================================================== 
Summary:                    [patch] Parsing and escaping of characters is broken
in some cases (e.g. app_System)
Description: 
It is no longer possible to pass a semicolon (an important shell construct)
to a System command.

I started writing this up specific to the System command, and actually
developed a patch for it in the system command, but the problem is more
widespread, and needs to be addressed globally, not as a point solution in
each command.

In 1.4, it was possible to construct a System command such as the
following:

exten => h,n,System(printf "Channel:
local/${ThisExt}@localstations\\nContext:
dialstation${ThisExt}\\nExtension: 811\\nCallerID: ${ThisExt}"
>/var/spool/asterisk/ringback$$\;(sleep 1\;mv
/var/spool/asterisk/ringback$$ /var/spool/asterisk/outgoing/ringback$$)&)

When executed, the escaped characters were removed by the parser before
reaching the System command:

-- Executing [h at ringback:2] System("SIP/x28-0188be00", "printf "Channel:
local/28 at localstations\nContext: dialstation28\nExtension: 811\nCallerID:
28" >/var/spool/asterisk/ringback$$;(sleep 1;mv
/var/spool/asterisk/ringback$$ /var/spool/asterisk/outgoing/ringback$$)&")
in new stack

In 1.6.0.3, the escaped characters, except for an escaped '\', are passed
directly through.  That most characters do not need to be escaped any more
could be seen as "good" except that the semicolon does still need to be
escaped, or the rest of the command is lost due to being considered a
comment.

While my patch to System solves the problem there, the problem exists in
most
other places you might need to insert a semicolon, such as in the Set
Command.
Consider the following in 1.6:

exten => 954,1,Noop(Generic test.  ${CALLERID})
exten => 954,n,Set(var=a,b, ,d\;e\;f,g)
exten => 954,n,noop(${var})
exten => 954,n,noop(${CUT(var,\,,2)})
exten => 954,n,noop(${CUT(var,\;,2)})
exten => 954,n,Noop(onward....)
exten => 954,n,Hangup

Note in the output below that the variable ends up with the escapes before
the semicolons included. Fortunately, the CUT command handles the escaping
correctly.


    -- Goto (dialstation,954,1)
    -- Executing [954 at dialstation:1] NoOp("SIP/x28-01894200", "Generic
test.  ") in new stack
    -- Executing [954 at dialstation:2] Set("SIP/x28-01894200", "var=a,b,
,d\;e\;f,g") in new stack
    -- Executing [954 at dialstation:3] NoOp("SIP/x28-01894200", "a,b,
,d\;e\;f,g") in new stack
    -- Executing [954 at dialstation:4] NoOp("SIP/x28-01894200", "b") in new
stack
    -- Executing [954 at dialstation:5] NoOp("SIP/x28-01894200", "e\") in new
stack
    -- Executing [954 at dialstation:6] NoOp("SIP/x28-01894200",
"onward....") in new stack
    -- Executing [954 at dialstation:7] Hangup("SIP/x28-01894200", "") in new
stack


In 1.4, the Set command needed to be constructed differently:
Set(var=a\,b\, \,d\;e\;f\,g)

The escape characters, as expected, do not end up in the variable.

    -- Executing [954 at dialstation:1] NoOp("SIP/x28-018ba000", "Generic
test.  ") in new stack
    -- Executing [954 at dialstation:2] Set("SIP/x28-018ba000", "var=a,b,
,d;e;f,g") in new stack
    -- Executing [954 at dialstation:3] NoOp("SIP/x28-018ba000", "a,b,
,d;e;f,g") in new stack
    -- Executing [954 at dialstation:4] NoOp("SIP/x28-018ba000", "b") in new
stack
    -- Executing [954 at dialstation:5] NoOp("SIP/x28-018ba000", "e") in new
stack
    -- Executing [954 at dialstation:6] NoOp("SIP/x28-018ba000",
"onward....") in new stack

Getting this right is not all that simple, of course.  Consider the
following:

The following is right:

    -- Executing [958 at dialstation:5] Set("SIP/x28-0189aa00", "cid=Caller
Name is Snom 28\, Number is 28") in new stack
    -- Executing [958 at dialstation:6] AGI("SIP/x28-0189aa00",
"sayexpnum,Caller Name is Snom 28\, Number is 28") in new stack

Because if the escape didn't stay in, you end up with the AGI thinking it
has more than one argument.

Please consider how best to fix this globally, in the mean time, I think
users can expect to have to continue adjusting dial plans until a permanent
parsing scheme is adopted that then will hopefully never be incompatibly
changed.

/john
====================================================================== 

---------------------------------------------------------------------- 
 (0097607) Corydon76 (administrator) - 2009-01-13 12:17
 http://bugs.digium.com/view.php?id=14231#c97607 
---------------------------------------------------------------------- 
Actually, we'd rather go with something a little more portable, like this. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-01-13 12:17 Corydon76      Asterisk Version         1.6.0.3-rc1 => 1.6.0.3
2009-01-13 12:17 Corydon76      Note Added: 0097607                          
2009-01-13 12:17 Corydon76      Additional Information Updated                  
 
======================================================================




More information about the asterisk-bugs mailing list