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.
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.
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.
How can we get Asterisk to execute scripts as the asterisk user?
How can we get Asterisk to run the script elevated without giving it full sudo access?
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.
I actually started this forum post when I also sent the reply above. I have my findings detailed there.
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.