Running a script

divyashree · 08-23-2011, 12:16 AM

I want to run a script only when a particular command executes .. how will I achieve this ?

angel115 · 08-23-2011, 06:38 AM

One way of doing it would be:
1. To create a script of the same name of the command and store it in a different folder
2. Add this folder to the PATH (but before the path where the legitimate executable is stored)
3. When you will run this command it will be executed instead the command.

Ex:
We will run the script for the "cat" command

Code:

root:~# which cat
/bin/cat
root:~# cat /etc/issue
Ubuntu 10.04.2 LTS \n \l

root:~# mkdir /opt/myscript
root:~# vi /opt/myscript/cat
root:~# chmod +x /opt/myscript/cat
root:~# /opt/myscript/cat /etc/issue
Hello World!!!
Ubuntu 10.04.2 LTS \n \l

root:~# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
root:~# PATH=/opt/myscript:$PATH
root:~# export PATH
root:~# echo $PATH
/opt/myscript:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
root:~# cat /etc/issue
Hello World!!!
Ubuntu 10.04.2 LTS \n \l

root:~# which cat
/opt/myscript/cat
root:~#

and here is the content of my /opt/myscript/cat file:

Code:

#!/bin/bash
echo "Hello World!!!"
/bin/cat $1

Best regards,
Angel.

AnanthaP · 08-23-2011, 08:28 PM

Use ps command with -C cmdlist to list only processes with program name = cmdlist.

So write a script like this:

Code:

EXECUTOR=prog_to_execute
CMDLIST=prog_to_verify_is_running
if [ $(ps -C CMDLIST | wc -l) -gt 1 ]; then
 $EXECUTOR
fi

Test it out.

PTrenholme · 08-23-2011, 11:10 PM

And there's also the alias command, so you don't need to change your PATH. See man alias for details.

divyashree · 08-24-2011, 12:38 AM

Quote:

Originally Posted by AnanthaP

Use ps command with -C cmdlist to list only processes with program name = cmdlist.

So write a script like this:

Code:

EXECUTOR=prog_to_execute
CMDLIST=prog_to_verify_is_running
if [ $(ps -C CMDLIST | wc -l) -gt 1 ]; then
 $EXECUTOR
fi

Test it out.

This does not work in many cases as ps lists only the processes running now. And my goal was ,suppose someone restarting a service or stopping a service to catch the user.

TB0ne · 08-24-2011, 10:39 AM

Quote:

Originally Posted by divyashree

This does not work in many cases as ps lists only the processes running now. And my goal was ,suppose someone restarting a service or stopping a service to catch the user.

Stating a goal when you ask a question is always a good thing. With what you've said, you need to put sudo in place, and set users up accordingly. Sudo can be easily configured to send emails when it's run.
http://www.cyberciti.biz/faq/sudo-se...sudo-log-file/

Since you've got a built-in way of sending mail, you'll get emails when someone does something that needs root permissions, like killing/restarting a service. Taking it a step further, you can then alias your mail command to another script that you write, to parse the output, and filter what's getting sent out to only send on SPECIFIC instances.

Reuti · 08-24-2011, 11:37 AM

Under which account should this additonal command being executed? The one of the user which started the original program, or something like a housekeeping routine running by root?

divyashree · 08-24-2011, 11:31 PM

Quote:

Originally Posted by angel115

One way of doing it would be:
1. To create a script of the same name of the command and store it in a different folder
2. Add this folder to the PATH (but before the path where the legitimate executable is stored)
3. When you will run this command it will be executed instead the command.

Ex:
We will run the script for the "cat" command

Code:

root:~# which cat
/bin/cat
root:~# cat /etc/issue
Ubuntu 10.04.2 LTS \n \l

root:~# mkdir /opt/myscript
root:~# vi /opt/myscript/cat
root:~# chmod +x /opt/myscript/cat
root:~# /opt/myscript/cat /etc/issue
Hello World!!!
Ubuntu 10.04.2 LTS \n \l

root:~# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
root:~# PATH=/opt/myscript:$PATH
root:~# export PATH
root:~# echo $PATH
/opt/myscript:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
root:~# cat /etc/issue
Hello World!!!
Ubuntu 10.04.2 LTS \n \l

root:~# which cat
/opt/myscript/cat
root:~#

and here is the content of my /opt/myscript/cat file:

Code:

#!/bin/bash
echo "Hello World!!!"
/bin/cat $1

Best regards,
Angel.

I used this method but the command doesnot run with its options.

divyashree · 08-24-2011, 11:32 PM

Quote:

Originally Posted by TB0ne

Stating a goal when you ask a question is always a good thing. With what you've said, you need to put sudo in place, and set users up accordingly. Sudo can be easily configured to send emails when it's run.
http://www.cyberciti.biz/faq/sudo-se...sudo-log-file/

Since you've got a built-in way of sending mail, you'll get emails when someone does something that needs root permissions, like killing/restarting a service. Taking it a step further, you can then alias your mail command to another script that you write, to parse the output, and filter what's getting sent out to only send on SPECIFIC instances.

No the services are not running as root, so no one use sudo. One particular user runs the production server and everyone logged in that only.

Let me try alias.

divyashree · 08-24-2011, 11:44 PM

Quote:

Originally Posted by Reuti

Under which account should this additonal command being executed? The one of the user which started the original program, or something like a housekeeping routine running by root?

One of the user started the server and he runs everything even not root.

Reuti · 08-26-2011, 09:06 AM

I was thinking of something like inotify, whenever the binary was accessed to act on this event.

TB0ne · 08-26-2011, 10:06 AM

Quote:

Originally Posted by divyashree

One of the user started the server and he runs everything even not root.

Ok...so again, use sudo. Sudo does NOT have to run the root user, since (as you can do if you ARE root), you can assume any other user's ID. So, something like

Code:

sudo -u <some user ID> <some command>

would let, say, USER1 run a command as USER5, and you'd get an email. Also, if you have just 'regular' users set up to be able to start/stop system level processes without any sort of security in place, that's not a very good idea. If they're NOT system level processes, you can also just check their .bash_history files to see what they're doing.

Add to that, you can check the system logs to see when processes were stopped/started, and also do a "last" to see who logged in when, from where, and reconcile that against the system logs, so even if they remove their bash history files, you'll still have something.

ta0kira · 08-26-2011, 12:16 PM

Quote:

Originally Posted by Reuti

I was thinking of something like inotify, whenever the binary was accessed to act on this event.

I had the same idea, but it's a script that needs to be run, not C. I suppose there could be a daemon written in C that executes the script. It wouldn't be particularly difficult.
Kevin Barry

edit:

Code:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>
#include <unistd.h>
#include <sys/inotify.h>


int main(int argc, char *argv[])
{
        if (argc < 3)
        {
        fprintf(stderr, "%s [binary] [command...]\n", argv[0]);
        return 1;
        }


        int notify = inotify_init1(IN_CLOEXEC);
        if (notify < 0)
        {
        fprintf(stderr, "%s: can't monitor binary '%s': %s\n", argv[0], argv[1], strerror(errno));
        return 1;
        }


        int monitor = inotify_add_watch(notify, argv[1], IN_OPEN | IN_DELETE_SELF | IN_MODIFY | IN_MOVE_SELF);
        if (monitor < 0)
        {
        fprintf(stderr, "%s: can't open binary '%s': %s\n", argv[0], argv[1], strerror(errno));
        return 1;
        }


        struct inotify_event events;

        while (read(notify, &events, sizeof events) == sizeof events || errno == EINTR)
        {
        if (errno == EINTR || events.wd != monitor) continue;
        if (events.mask & (IN_DELETE_SELF | IN_MODIFY | IN_MOVE_SELF)) break;

        if (events.mask & IN_OPEN)
         {
        if (fork() == 0)
          {
        setpgid(0, 0);
        execvp(argv[2], argv + 2);
        _exit(1);
          }
         }
        }

        return 0;
}

Code:

> gcc main.c
> ./a.out `which ls` echo hello & #<-- monitor ls, execute echo hello
[1] 2266
> ls
hello
a.out  main.c

I tried this with monitoring a script and the script was opened twice, resulting in two "hello"s, however (probably once to id the shebang and a second time by the identified shell).

divyashree · 08-26-2011, 11:16 PM

Quote:

Originally Posted by TB0ne

Ok...so again, use sudo. Sudo does NOT have to run the root user, since (as you can do if you ARE root), you can assume any other user's ID. So, something like

Code:

sudo -u <some user ID> <some command>

would let, say, USER1 run a command as USER5, and you'd get an email. Also, if you have just 'regular' users set up to be able to start/stop system level processes without any sort of security in place, that's not a very good idea. If they're NOT system level processes, you can also just check their .bash_history files to see what they're doing.

Add to that, you can check the system logs to see when processes were stopped/started, and also do a "last" to see who logged in when, from where, and reconcile that against the system logs, so even if they remove their bash history files, you'll still have something.

Actually my concern is only for 2/3 commands. Who run them at what time, I should be informed immediately. This should not happen within production as I have to answer for that .Anytime they configure anything from GUI, they just restart the service from the commandline to load new ones.

So the mail should be fired as soon as they run the command.

TB0ne · 08-27-2011, 01:09 PM

Quote:

Originally Posted by divyashree

Actually my concern is only for 2/3 commands. Who run them at what time, I should be informed immediately. This should not happen within production as I have to answer for that .Anytime they configure anything from GUI, they just restart the service from the commandline to load new ones.

So the mail should be fired as soon as they run the command.

Right....AGAIN, that's what sudo does. You can allow/disallow as many commands as you'd like, and get emails when it's run.