Cacti / plugin_syslog

Syslog Plugin for Cacti
GNU General Public License v2.0
21 stars 16 forks source link

Syslog 3.1 has a hardcoded path for sh which causes issues running other scripts #151

Closed bmfmancini closed 2 years ago

bmfmancini commented 3 years ago

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 !

cigamit commented 3 years ago

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.

bmfmancini commented 3 years ago

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

bmfmancini commented 3 years ago

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

cigamit commented 3 years ago

Have you tried putting the python command (with full path) in front of the command? so /usr/bin/python /path/to/my/script.py

bmfmancini commented 3 years ago

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

cigamit commented 3 years ago

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.

bmfmancini commented 3 years ago

ah ok makes sense

bmfmancini commented 3 years ago

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

cigamit commented 3 years ago

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
cigamit commented 3 years ago

So try changing it to exec_background('/bin/sh -c ', '"' . $command . '"');

cigamit commented 3 years ago

That whole section does need to be changed though, as 1) It doesn't work on Windows 2) It allows arbitrary commands to be run

bmfmancini commented 3 years ago

So try changing it to exec_background('/bin/sh -c ', '"' . $command . '"');

trying now

bmfmancini commented 3 years ago

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)

bmfmancini commented 3 years ago
  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 
TheWitness commented 3 years ago

Likely cause your Debian system is running 'dash' as it's default shell.

bmfmancini commented 3 years ago

This is a rhel system Default shell is bash though

On Tue., Mar. 9, 2021, 18:30 TheWitness, notifications@github.com wrote:

Likely cause your Debian system is running 'dash' as it's default shell.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Cacti/plugin_syslog/issues/151#issuecomment-794602449, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADGEXTCQTTPJ52KFP22GBK3TC2OQVANCNFSM4Y2E44OA .

TheWitness commented 2 years ago

Yea, makes no sense, pushing a workaround.

TheWitness commented 2 years ago

Should be fixed now. Close if so.