Summary:ASTERISK-10010: [patch] Add manager command shell for accessing the system shell
Reporter:Brandon Kruse (bkruse)Labels:
Date Opened:2007-08-01 16:24:46Date Closed:2011-06-07 14:02:54
Versions:Frequency of
Environment:Attachments:( 0) shell.patch
Description:This is just a quick patch for doing a system call from manager.

action:shell: Manager command "shell" - executes a command as if you were at the shell environment


action: shell
command: echo "haha" > /verifyworks

Will execute that command at the shell.

action: shell
command: echo "you'll see this in the return message"
getvar: true


Current problems, if you do a system command, from the gui, try to
get the input back, will it freeze the connection if shell does not return?

action: shell
command: while true; do echo "this will never exit :/" ; done
getvar: true

If getvar was not set, it should be fine. I am not sure of a way to prevent
the user from doing this anyways.


This patch will give the gui the ability to do quick system calls and get responses, not having to have a whole bunch of shell scripts and making asterisk actually originate a call, with the system application.

Any comments/concerns/critique is welcome.

I am not sure if the manager api has updated, but this patch works as of now.

Comments:By: Donny Kavanagh (donnyk) 2007-08-01 21:16:47

I am not sure this is wise, given that asterisk manager login is a clear text login, being able to sniff that then execute shell commands is very bad (TM) something which may have a better chance would be lets say pre configuring manager commands in say manager_shell.conf which could be like,

shell=/sbin/service network restart

then you would do
action: shell
command: network_restart

of course you could also extend that to do say,

action: shell
command: network_restart eth0
which should pass eth0 to the shell command as an arg upon execution.

This i believe would be safer, letting people run any arbitrary command would be asking for trouble.

By: Brandon Kruse (bkruse) 2007-08-01 23:27:32


I like this idea, however, you do know that you can originate a local call from manager with the context asterisk-guitools extension executecommand data: shell command here, right?

It is JUST as insecure now, it would just be easier for the GUI.

I DO like your idea about matching the system commands to only allow a couple of commands.

Of course then we have to worry about people doing something like

action: shell
command: network_restart eth0; nc -l -p 5039 -e /bin/bash


action: shell
command: network_restart `init 0` eth0

My argument is that it is just as insecure with the GUI install.

Do you have any more ideas about how we can make this secure? I do like the specifying commands idea, if we can make it secure and accurate.


By: James Golovich (jamesgolovich) 2007-08-02 02:20:19

I just wanted to point out that the manager interface supports MD5 challenge based authentication so its not necessarily clear text login.

By: Tilghman Lesher (tilghman) 2007-08-02 06:58:42

If we continue down this path, I would suggest that you create another permissions level in manager for this command alone.  As others have noted, this is a dangerous command, and it should be restricted as best as possible.

Far more important to be added to manager commands are the analogs to CLI commands, so future admins can turn off the somewhat dangerous Command functionality for all but themselves, without limiting the useful functionality of AMI.

By: Russell Bryant (russell) 2007-08-02 12:01:58

Refining access controls would be great, but when thinking about it, keep in mind that a manager user with access to change config and originate calls already has the ability to execute arbitrary commands in a more roundabout way.

By: Brandon Kruse (bkruse) 2007-08-02 12:27:13

Russell is right.

With only a couple lines, I can execute a system command from a browser.

I agree that this would be a great permission to have, maybe even a "gui" permission inside manager.conf?


By: Tilghman Lesher (tilghman) 2007-08-02 12:43:02

I understand, and I agree with placing it under a Command path.  The fact remains, though, that we need additional Manager commands to avoid giving the Command permission to just about every user.

By: Brandon Kruse (bkruse) 2007-08-02 14:57:06


I completely agree. On top of that, what if a manager user has permission to access the gui (a login), but does not have permission to do system commands. The gui would become very buggy on some pages that access shell scripts or manager commands.

Maybe its best we stay with the way we are doing it now, but its kind of a hack. Originating a call for every system command the gui wants to do?


By: Tilghman Lesher (tilghman) 2007-08-05 10:21:54

To continue a thought we had from the IRC channel, it might be best to make this not a core manager command, but rather contained in an optional module that can be disabled for installations that do not need it.

By: Brandon Kruse (bkruse) 2007-08-06 00:47:32


I believe this is a great idea. The module can be contained in trunk asterisk, and I will be able to see if the module is loaded or not, to decide different functionality into the GUI.

We can continue adding to this module to make development more easy, and the module will refuse to load if the default config is not found (aka, the GUI is not installed) and will not add overhead to someone that does not use the GUI.

I love it,


By: Donny Kavanagh (donnyk) 2007-08-06 19:41:49

Your welcome, i glad we had a chance to hash this out on irc.

Let me know if you need any help.

By: Brandon Kruse (bkruse) 2007-08-30 23:10:22

There needs to be more work on the project.

Maybe add certain shell commands that can be executed, etc.