DTMF run shell scripts

Tom · August 29, 2024, 12:12am

ASL3 on Pi3B+
Some DTMF run shell scripts execute and some don’t. For example, consider the folowing functions:
995=cmd, /usr/bin/astres.sh ; Restart Asterisk
996=cmd, /usr/local/sbin/reboot.sh ; Reboot PC
997=cmd, /usr/local/sbin/on_normal.sh ; Set ON_normal state
909=cmd, /usr/local/sbin/halt.sh ; Stop PC for power off

*997 works; but the other three don’t. Each of the functions run from CLI without issue.

Tom / K5TRA

Tom · August 29, 2024, 12:16am

Clarification: Each of the shell scripts run from CLI without issue

WA3WCO · August 29, 2024, 1:12am

On ASL3, the “asterisk” process no longer runs as the super-user “root” login. See ASL3 Manual (Permissions) for more info.

… and some of the commands you are trying to execute require “root” privileges.

Tom · August 29, 2024, 1:17am

Thanks for the quick reply Allan. I understand how to change ownership and group. Is there a simple work around for what I’m trying to do? (What would need to have ownership or group changed?)

Tom · August 29, 2024, 1:36am

To be able to gracefully power down the processor from DTMF is important. I don’t want to roll the dice with potential memory corruption by jerking the power on & off. Remoting in with SSH will work; but not always convenient.

WA3WCO · August 29, 2024, 1:59am

This issue is not that the “asterisk” process can’t access/execute the commands. The problem is that you are wanting the “asterisk” process to execute commands that require super-user “root” privileges that it doesn’t possess.

If you think about this a bit more you will (should) remember that to execute these commands from the CLI you would either be logged in as “root” or you would be using “sudo …”.

As for workarounds, the system is running Linux so there are lots of possibilities.

You “could” have a long running “root” process (or a “root” cron job that runs every minute) that watches/waits for a “trigger” file to be created/updated and exec’s whatever privileged commands you want executed. Then, you have “asterisk” update the “trigger” file.

Note: I’ve seen scripts that do the same type of thing but instead of watching a file they would watch for for GPIO pin transitions.
You also “might” be able to set the system up so that the “asterisk” login could execute commands with “sudo”.

Just remember to be very careful that whatever you put together cannot be abused (e.g. you don’t want to have a root level process that blindly executes the contents of a file).

Tom · August 29, 2024, 2:08am

Thanks Allan. That’s a good idea.

George_Csahanin · August 29, 2024, 5:15pm

How about add user “asterisk” to root group?

GeorgeC w2db

N8EI · August 29, 2024, 6:01pm

That would defeat the purpose of not running asterisk as root. Probably the right solution here is a PolKit policy that allows the ‘asterisk’ user to call certain patterns of commands like reboot, shutdown, and a few things like that.

George_Csahanin · August 29, 2024, 7:42pm

Maybe I’m just not clear on the reason in the first place. I’ve been running allstar since 2010 with no problems caused by root.

GeorgeC

N8EI · August 29, 2024, 7:55pm

It’s general practice that applications that do not need root access do not run as root in an operating system. Asterisk does not need root access and has not for a very long time. ASL1/2 and HamVOIP are based on extremely obsolete versions of Asterisk.

Since may ASL3 nodes sit on the public Internet, we’ve made sure that every aspect of the system is as secure as we can make it.

N8EI · August 31, 2024, 11:51pm

People may wish to follow this:

github.com/AllStarLink/ASL3

All PolicyKit Rules for the asterisk User

AllStarLink:develop ← AllStarLink:polkit_rules

opened 11:41PM - 31 Aug 24 UTC

jxmx

+63 -0

This is a PolicyKit ruleset to permit the asterisk user to execute a limited num…ber of actions without the need for sudo or prompting for a password. Those are: * `systemctl stop asterisk` * `systemctl restart asterisk` * `systemctl stop allmon3` * `systemctl restart asterisk` * `/usr/sbin/poweroff` * `/usr/sbin/reboot` Using a combination of wrapper scripts and appropriate function configuration, Asterisk can restart itself, Allmon3, shutdown the system, or reboot the system. Use of the wrapper scripts for `systemctl` commands is essential for a clean execution of the scripts under the polkit rules. The provided wrappers are: * `/etc/asterisk/scripts/allmon3-restart` * `/etc/asterisk/scripts/allmon3-stop` * `/etc/asterisk/scripts/asterisk-restart` * `/etc/asterisk/scripts/asterisk-stop`

github.com

AllStarLink/ASL3-Manual/blob/main/docs/adv-topics/permissions.md

# Permissions

## "asterisk" vs "root"

One of the new features with ASL3 is that the Asterisk process now runs as the "asterisk" user (not as the super-user; "root").
While sometimes handy this was potentially very dangerous.
This change was made for increased security.
It's a good thing!

We acknowledge that there are some applications, commands, and scripts that you may want to bring over from older (and other) versions of ASL and that these may be impacted by ASL3's heightened security.
Porting these over to ASL3 may require some simple changes to filesystem permissions.
Other issues may need other solutions (e.g. you can't execute a command that requires "root" privileges when you are not the "root" user).
For guidance, reach out to the [AllStarLink Community](https://community.allstarlink.org/).

In short, in ASL3 the Asterisk process now runs as the "asterisk" user.
If you modify the "/etc/asterisk/rpt.conf" file to execute a command (or script) it will NOT have super-user ("root") privileges.
The command itself and any file it references must be readable by the "asterisk" user.
Any files that the command needs to modify must be writable by the "asterisk" user.
Lastly, the parent directory of any file being created must also be writable.

This file has been truncated. show original

Mason10198 · September 1, 2024, 4:36pm

The tone in these posts is surprising. It seems that many people lack a clear understanding of the differences between Allstarlink, app_rpt, and Asterisk.

Asterisk is an open-source software used for creating and managing communication systems like VoIP and PBX. It is not affiliated with Allstarlink or the developers of app_rpt.

app_rpt is a third-party module for Asterisk that adds features for radio interfacing and control, enabling Asterisk to be used in building advanced radio systems.

Allstarlink is an organization, network, and software package that integrates Asterisk and app_rpt with networking capabilities, making it much easier for users to leverage these technologies without needing to build everything manually.

Recently, the Allstarlink developers released a new beta version that builds app_rpt on Asterisk 20—over 15 years newer than the previous Asterisk version used with app_rpt. This update brings new features, bug fixes, and modern security practices.

To be clear: the Allstarlink developers are not responsible for the updated security practices. Asterisk and the operating system it runs on handle security. Blaming the Allstarlink team for these updates doesn’t make sense.

n5zr · September 14, 2024, 4:11am

There is always risk in adding asterisk to admin processes but the beauty of it all is you get to choose to allow it.

add to sudoers:
asterisk ALL=(ALL) NOPASSWD: /path/to/privileged/executeable

then use sudo in your scripts.