Managing per-user rc.d init scripts

Question

I want to delegate SysV init scripts to each user.

Like the SysV init, each item in ${HOME}/rc.d starting with S will be launched on server start-up with the start argument. The same for the server shut-down with the one starting with K and with the stop argument.

I thought about scripting it myself, but maybe there is already some kind of implementation out there¹. In summary it would be a script in /etc/init.d/ that iterates through all the users and launches runparts as the user on the relevant scripts.

The platform here is a Linux (Debian flavour), but I think the solution would be quite portable among various Unix-like platforms.

Update:

The point here is for users to be able to create their own init scripts that should be launch on their behalf when the system boots up. As Dan Carley pointed out, the services won't be able to access any system asset (priviledged ports, system logs, ...).

_{1. This way I don't have to think that much about all the subtle security implications such as script timeouts for example...}

Answer 1

Your question basically includes the answer.... A script that'll iterate through a subdir of each users home, looking for executable scripts. Then it sudo -u user /export/home/user/scripts/scriptname.sh start. You'll have no control over what the scripts do, so you`ll need to trust your users.

Insist that they write their scripts to accept stop start restart as $1 param and that they shouldn't use any environment variables that have been set up in their .profile, .cshrc or .bashrc files. The script effectively needs to be standalone.

#!/usr/bin/bash

run_cmd {
cd /export/home
for HOMEDIR in *; do
  for SCRIPT in /export/home/$HOMEDIR/scripts/*;  do
     if [ -x $SCRIPT ]; then
       echo "$ACTION user $HOMEDIR's script $SCRIPT"
       sudo -u $HOMEDIR $SCRIPT $ACTION &
     fi
  done
done

}

case $1 in
    start) ACTION=start;
           run_cmd;;
    stop) ACTION=stop;
           run_cmd;;
    restart) ACTION=stop;
             run_cmd;
             sleep 60;
             ACTION=start;
             run_cmd;;
    *) echo "$1 not recognized as valid cmd";;
esac

exit 0

You'll need to tweak this for your environment, location of bash/homedirs etc.

Answer 2

The point here is for users to be able to create their own init scripts that should be launch on their behalf when the system boots up.

This is already possible on most systems, using the cron utility. Simply instruct your users to do the following:

1. run the command crontab -e
2. add a line like the following:

   @reboot /home/user/script argument

3. save

More info: http://www.cyberciti.biz/faq/linux-execute-cron-job-after-system-reboot/

Answer 3

I'm not quite sure of what you want to achieve, but to me, it sounds a bit similar to .profile and .bash_logout, which are executed when a user starts a shell, or exits a shell.

The difference with your solution is that the scripts are run when a user login, or start a new shell and not when the computer starts up. But I have to admit i would not feel comftable to let any users run scripts on startup ...

Answer 4

You construction sounds like the makings of a nightmare :)

Just give your users sudo access to the existing init scripts as required.

Answer 5

I would be inclined to disallow scripts and enforce a very strict short list of canned scripts and commands that a user can reference in a simple list file that can easily be validated at boot time. The canned scripts would be stored in a common place without user write permissions. The list file would name the script or command and any arguments required. One of these common scripts would provide the user with stop/start/restart processing if it is needed after they have logged in.

The reason for all this paranoia is partly due to security, but more about control of what goes on during startup. I mean can you imagine what kind of a nightmare it would be if your users get carried away with starting up all manner of stuff all at the same time "just because they can"? Not to mention poorly written scripts.

Otherwise, if you can find a ready-made solution that addresses these issues (which is one criteria you mention in your question), that would be the way to go.