Cannot run external application from dial plan, but it is working from the CLI

[guyjerby]

Hello,
I need assistance regarding execution of external program from the dial plan.
I already have simple KSH scripts that are executing and working as expected.

the problem is when I am trying to use an application instead of shell script.
the asteriskis not running the application (using SHELL command) at all, but when I am trying to run it using the asterisk CLI or the linux CLI with asterisk user - it is working as expected.

at the first thing I assumed that it is permission problem, but if asterisk user can run it - I believe that it is not the case.

I saw many cases like that in the forum, but the solution is not documented.

can you please assist?

Thanks,
Guy

[danielf]

Hello @guyjerby,

Can you share your code? what type of an external program do you use?

Thank you,

Daniel Friedman
Trixton LTD.

[guyjerby]

Hi Daniel,

Sure.
I am trying to run javascript application using “babel-node”

here is the code from the dial plan:

exten => 1,n,Set(STATE_STRING=${SHELL(/var/spool/asterisk/interface/scripts/get_user_state.ksh ${FORWARDER} ${CALLER}):0:-1})

the get_user_state.ksh is calling the babel-node application with the following command:

#-------
STATE_STRING=$(/usr/bin/babel-node /home/backend/server/scripts/get_state.js ${USER} ${CALLER} --presets es2015,stage-2)

it is working from the linux CLI.
it is also working from asterisk CLI using ! for executing the command.

in this case the STATE_STRING is receiving an empty value, from further testing I found that the application is not running at all, without any error message.

Thanks,
Guy

[navaismo]

Is your ksh script executable? Try chmod +x
And how do you invoke it from Linux shell?
Folder is also own by asterisk user?

[guyjerby]

Hi navaismo,
yes, the KSH is executable, I run it with full path or with “./” from the script path and get the expected result.
yes, the folder of the script is owned by asterisk user.

Guy

[lgaetz]

Try using system dialplan application instead of shell.

[dicko]

As @lgaetz suggests, SHELL always uses /bin/sh SYSTEM or bash would call eventually call /bin/ksh for *.ksh

[guyjerby]

Hello,
Thanks guy’s, the issue is solved.
Although that the application was run from the CLI, it was permission problem.
it solved by using sudo before the command in order to have root access for asterisk user.

in order to use sudo for asterisk user without the need to enter password, I added it to the sudoers file using the visudo.

I added the following line:
asterisk ALL=(ALL) NOPASSWD:ALL

from my opinion it is a temporary solution, I have to fix the permission in order to have the ability to run it without sudo.

Guy

[xptpa2020]

Sorry to resurrect this thread, but this is the same problem I am experiencing. I need to be able to execute a script with elevated permissions, and following what Guy recommended above is the only thing that fixed it for me.

My system runs Asterisk as the user ‘asterisk’. Yet when the Dialplan command System(/var/lib/asterisk/bin/makevmal.sh… ) runs, it executes the script as the ‘root’ user, in a non-elevated state.

1. How can we get Asterisk to execute scripts as the asterisk user?
2. How can we get Asterisk to run the script elevated without giving it full sudo access?

[cynjut]

it executes the script as the ‘root’ user, in a non-elevated state.

OK - first things first. There is no such thing as a script running as root in a non-elevated state. By definition, if the script is run as root, it is run with root (elevated) privileges.

So, there’s something called a "chroot’ bit. This allows programs to run as the “owner” of the script with all of the rights and privileges that come with it.

I’d need to see what you’re talking about with your questions 1 and 2. It could be that you’re experiencing some discontinuity with what’s actually happening with what you think is happening. In my experience, unless the script takes steps to change its running user, everything that Asterisk kicks off (if it is. in fact, running as the asterisk user) will run as the asterisk user. It’s one of the basic tenets of Unix user security.

In 2, you talk about ‘sudo’ access. Scripts (IMEO) should not run out of sudo. If your script needs to run as ‘root’, you may need to reassess what the program is supposed to be doing and adjust your user and group permissions to manage the processes without giving unfettered access to a process like asterisk (which has several publicly facing interface and a huge security attack surface).

So, rather than “I have the same generic problem”, we’d really rather talk about what you are trying to actually accomplish so we can help you do it in a way that is both sustainable and safe.

[xptpa2020]

I actually started this forum post when I also sent the reply above. I have my findings detailed there.

Dialplan Executing Shell Script But Chroot Blocking Required Access

Trying to be as exhaustive in the title, but now I think I should have shortened it. I have a script that I am using to transcribe voicemails via the Google Cloud Speech API that is on my account. The script, and voicemail transcriptions work flawlessly when I run the script the following ways: [root@pbx ~] # /var/lib/asterisk/bin/makevmal.sh “SIP/TRUNK” 2535551234 “Tue Nov 26 03:01:24 PM EST 2019” 1574798484 127 1574798478.463 7 as asterisk: [asterisk@pbx ~] # /var/lib/asteri…

The tldr; version is:
I discovered that it is actually doing some sort of chroot.
Asterisk does in fact run as ‘asterisk’.
The dialplan executes a script as System(/var/lib/asterisk/bin/makevmal.sh parameter1 param2 … param8).
The script above I pieced together from an article I found in 2013 and another person’s post from 2016, which sends a voicemail to Google Voice API for Speech to Text, and then includes the contents in the body of the email that is sent out, with an MP3 attachment.

In the script, I added a line that does “echo $USER” so that I can see who is running it, which it always reported root… even though it is executed by Asterisk, running as ‘asterisk’. This execution method doesn’t have root access, so I had to add asterisk to the list of suders with the commands in the script that require elevation. Then, and only then, did it actually work.

The real headache was the fact that when I run the script as root or as the asterisk (su asterisk, and then ran the script), I never had a problem. So something with how the script was executed by Asterisk was locked down. Either way, adding to sudoers with those commands and adding sudo in front of those commands in the script resolved the problem for me.