Syslog 3.1 has a hardcoded path for sh which causes issues running other scripts
bmfmancini opened this issue · 18 comments
Hey Everyone,
I ran into an issue with syslog 3.1 where it would execute a shell script but would not execute a python script
the Log would repport the script was executed without error but the script was not actually run
I even created a simple hello world script to log to a file same deal
I came across the below block of code and I notice that exec_background has a hardcoded path to /bin/sh
I removed that path still no go I changed
exec_background('/bin/sh', $command);
To
exec($command);
And that resolved my issue
See the original block
if ($alert['open_ticket'] == 'on' && strlen(read_config_option('syslog_ticket_command'))) {
if (is_executable(read_config_option('syslog_ticket_command'))) {
exec(read_config_option('syslog_ticket_command') .
" --alert-name='" . clean_up_name($alert['name']) . "'" .
" --severity='" . $alert['severity'] . "'" .
" --hostlist='" . implode(',',$hostlist) . "'" .
" --message='" . $alert['message'] . "'");
}
}
}
}else{
/* get a list of hosts impacted */
$hostlist[] = $a['host'];
}
if (trim($alert['command']) != '' && !$ignore) {
$command = alert_replace_variables($alert, $a);
cacti_log("SYSLOG NOTICE: Executing '$command'", true, 'SYSTEM');
exec_background('/bin/sh', $command);
}
}
Is there a reason to have the exec_background vs exec ?
I will send a pull request but just want to understand the original design
Thanks !
exec_background is a Cacti function
https://github.com/Cacti/cacti/blob/ad7f9e7e30a5c55d3b09d807153377e41bfa294e/src/lib/poller.php#L132
that takes into account whether Cacti is running on Windows or Linux and what arguments are passed.
Thanks @cigamit I will re-test with exec_background but I am sure the hardcoded shell path should be removed
not all script being run will be shell in my opinion
Ah actually I noticed this
in syslog_process.php
the only files included are
include(dirname(FILE) . '/../../include/cli_check.php');
include(dirname(FILE) . '/config.php');
include_once(dirname(FILE) . '/functions.php');
I dont see poller.php being included which I would think would be required for that function to work
I dont see exec_background mentioned in any other file in the syslog files aside from setup.php
Have you tried putting the python command (with full path) in front of the command?
so
/usr/bin/python /path/to/my/script.py
yes it also fails until you removed the path to sh
I figure it must be running /bin/sh /usr/bin/python /path/to/script
cli_check.php includes global.php, which then includes the lib/poller.php.
Otherwise you would be getting an error in your cacti log about it, and Cacti would be disabling the plugin.
ah ok makes sense
OK I just tried again with background_exec($command) that breaks it
log shows the command is being executed but doesnt
move that to exec($command) and back to working state
ya, we may have a to make a change to pass "-c" tell /bin/sh that its a command as /bin/sh can execute python just fine like so
[root@localhost ~]# /bin/sh -c "/usr/bin/python ~/test.py"
Hello World
[root@localhost ~]# /bin/sh -c "~/test.py"
Hello World
Your other option for now is to wrap the python script in a shell executor
#!/bin/sh
/usr/bin/python /path/to/my/script.py
So try changing it to
exec_background('/bin/sh -c ', '"' . $command . '"');
That whole section does need to be changed though, as
- It doesn't work on Windows
- It allows arbitrary commands to be run
So try changing it to
exec_background('/bin/sh -c ', '"' . $command . '"');
trying now
No go
I did run that command using /bin/sh -c command manually as the apache user and it did execute the script
but not via php it will only work with exec($command)
if (trim($alert['command']) != '' && !$ignore) {
$command = alert_replace_variables($alert, $a);
cacti_log("SYSLOG NOTICE: Executing '$command'", true, 'SYSTEM');
exec($command);#working
#exec_background('/bin/sh -c ', '"' . $command . '"'); #not working
Likely cause your Debian system is running 'dash' as it's default shell.
Yea, makes no sense, pushing a workaround.
Should be fixed now. Close if so.