3

I'm looking for a framework/library/environment so an ordinary user can set up it's own server processes. These processes should run under his uid as any other user process.

However the definition of which processes should be started, with arguments they get etc should be specified by an ordinary user without extra privileges. It's important to me that this happens without the necessity for the user to actually log in. Ideally it should work with SYSV init but a systemd-based thing is ok as well.

Examples/use cases:

  • nginx uwsgi/fast cgi processes
  • mongodb instances
  • different builders for continuous integration server

All of these have in common, that I might want to start multiple instances of the same binary (with different parameters) and that these parameters might need regular changes. However users should be able to tweak all of that without requiring root privileges.

Any suggestions/pointers how this can be implemented in Linux?

EDIT: The minimal requirement is just to start the user processes but obviously there will be the need for more advanced control mechanisms. For example there should be an easy way to query if the service is running, stopping the instance, restarting it, reloading it, ...

Felix Schwarz
  • 203
  • 2
  • 11
  • This is the type of thing `sudo` is for. – Michael Martinez Jul 16 '14 at 18:43
  • No, `sudo` only handles the actual switch to a different user account but it doesn't enable users to manage their own services. – Felix Schwarz Jul 17 '14 at 09:12
  • In /etc/sudoers, you define which which users can run which programs. This does let them manage their own services. – Michael Martinez Jul 17 '14 at 19:37
  • This doesn't solve "start service at startup without manual interaction". You'd still have to put each service in /etc/init.d and that's what I tried to avoid. Of course sudo may be a part of the final solution but by itself it doesn't solve the problem. – Felix Schwarz Jul 18 '14 at 07:21

3 Answers3

4

cron provides for this with the @reboot prefix (Vixie, and perhaps other flavors, check man 5 crontab). The user would use crontab to create/edit their own crontab file, and specify

@reboot /some/path/command -flags --moreflags

Which will run that command on startup, as that user.

DerfK
  • 19,313
  • 2
  • 35
  • 51
  • That's a very nice start and actually fulfills all my basic needs! However (I'm not easy to satisfy you know ;-) I hoped for something more sophisticated with job control (is the service running?, restarting it, reloading it, ...). – Felix Schwarz Oct 17 '11 at 19:12
  • 1
    @FelixSchwarz Make your users write their own initscripts that handle the vagaries of managing their process, then you can tell them to put all the scripts in a folder in $HOME and use symcbean's script to run them all at once (or tell them to put `@reboot /home/user/init/foo start` in their crontab). symcbean's script has the advantage that if everyone implements `status` you can call them all at once with `/etc/init.d/symcbean status` – DerfK Oct 17 '11 at 20:08
3

This would be about 10 lines of shell script, why do you need a framework/library/environment?

As a quick example, using sysV init....

#!/bin/bash

. /etc/rc.d/init.d/functions

. /etc/sysconfig/network

DAEMON_USERS=`cat /etc/daemon_users`

CMD="$1"

for DUSER in $DAEMON_USERS ; do
   DSCRIPTS=`ls /home/${DUSER}/init/`
   for DFILE in DSCRIPTS ; do
      if [ -x "/home/${DUSER}/init/${DFILE}" -a ! -d "/home/${DUSER}/init/${DFILE}" ]
      then
         su -c $DUSER /home/${DUSER}/init/${DFILE} $CMD
      fi
   done
done

If you really want to allow them to run stuff as root, then remove the 'su -c $DUSER' and add them to the sudoers so they can restart / add stuff without a reboot.

symcbean
  • 19,931
  • 1
  • 29
  • 49
  • As I commented above I hoped for something more sophisticated with daemon control/status querying etc (without building this all by myself for each and every service again). I mean my needs are not that uncommon, are they? – Felix Schwarz Oct 17 '11 at 19:17
  • @Felix: Unix provides all that out of the box. – symcbean Oct 18 '11 at 08:11
2

So... just start the application as the user you want to run it as and don't try to access anything that would require root (like privileged ports, files that can only be read by root, etc.)?

If you want to automatically start these daemons and control them via the SysV init process you're going to need to create an init script for each one that specifies the parameters (or reads them from a file that the unprivileged user has write access to) and launches the daemon using su -c or similar, but BEWARE: Doing this has SERIOUS security implications (a carefully-crafted "parameters" file can let the user execute arbitrary code as the user running your init sequence, which is usually root).
DerfK mentioned the cron @reboot option, which may be a better choice (less of a security risk), but your admins need to be aware that these programs are going to be started by cron...

voretaq7
  • 79,345
  • 17
  • 128
  • 213
  • Well, as I said it's not about running as root so of course the daemon instances can't access privileged ports but that's fine. However the problem with creating an init script is that this requires root privileges. – Felix Schwarz Oct 17 '11 at 19:10
  • Actually creating an init script doesn't require root privileges - you can make the rc.d directory group or world writable. This too has all sorts of horrible security implications (for the love of $_DEITY don't do it! :) – voretaq7 Oct 17 '11 at 19:17
  • voretaq7: I take that as a joke. Of course I won't fiddle around with permissions on important directories like /etc/rc.d! So yes, in practice adding an init script *does* require root privileges. – Felix Schwarz Oct 18 '11 at 07:29