5

I have a personal program, that has a server/client design.

The server daemon part of it, should be run as its own limited user, and the program was not designed to drop its root privileges (if started as root) like some Linux programs do.

So my question, in its startup script in /etc/init.d/, should I use sudo or su to run this daemon as another user? Does it make a difference? Will either of the two even work? Something else?

The operating system is a custom GNU/Linux one, built using "Linux From Scratch" instructions, and does have both programs running correctly.

3
  • 2
    Do you have the source for server and client? You could add the uid dropping in case it was started as root.
    – ott--
    Feb 19, 2013 at 14:27
  • yes, it's a python program. os.setuid is what i should do, right? Feb 19, 2013 at 14:31
  • 1
    You could check if os.getuid() returns 0, then switch to another uid.
    – ott--
    Feb 19, 2013 at 14:35

4 Answers 4

3

Of the two, I would use su for this purpose, because it is less configurable and therefore more predictable. If you use sudo in your init script, and then (accidentally or purposefully) remove the root ALL=(ALL) ALL entry in /etc/sudoers, your init script will mysteriously break.

Furthermore, I would use the following form to reduce the configuration footprint even further:

su -s /bin/sh -c "my_program my_args etc" my_user

The -s option means you can change the user's default shell to /bin/false or /sbin/nologin or something without breaking the script. You might also want to redirect the standard I/O to /dev/null or some other suitable place, if your program doesn't already handle that itself.

3

In terms of convenience I suggest you to look at chpst program from runit supervisor stack. It's very convenient and saves one from messing with command line parameter escaping etc. which is a pain with sudo/su.

If you want to run program as another user you call it just like that:

chpst -u my_user /path/to/program

It does setsid, setgid, execve on your program, that's all (it have a lot other nice features).

If your distribution includes busybox, you also can check if it has chpst applet compiled, you may already have it and don't need separate package.

1
  • chpst sets only uid ang gid and eventually environment variables for UID and GID. It won't set up the whole shell environment for you as expected (eg $HOME ...). May 15, 2017 at 11:31
2

If you can easily alter the program so that it drops its privileges, then this is the best approach. Switching user ID in the startup scripts is kludgey and rather inflexible, even if it does "work".

1
  • I ended up doing that. I figured i can use os.setuid, which is a far cleaner solution than using sudo or su. Feb 20, 2013 at 12:13
2

Technically, both should work fine, however you probably want to follow convention here. Sudo is generally used to elevate to root to run a single command, while su is generally used to change to a new user and then run commands as that new user:

That said, there are a few views on sudo vs su if you do a quick Google search:

3
  • 1
    Actually su is usually used for becoming another user while sudo is used for executing ad hoc commands as another user. su -c is the (rough) equivalent of sudo and sudo -s is the equivalent of su. Contrary to popular belief the "su" in either command stands for "switch user" not "super user". They are both for switching to any user, but both default to root.
    – bahamat
    Feb 19, 2013 at 23:00
  • Agreed. I was simply stating what I've seen used as convention on most Linux/Unix in the past; sudo generally for a single root based command while su more generally to execute as another user.
    – sbtkd85
    Feb 20, 2013 at 15:15
  • 3
    Sudo can break init scripts if requiretty is enabled in /etc/sudoers (on by default in cent 6, cent 7, fedora)github.com/influxdb/influxdb/issues/800
    – spuder
    Oct 10, 2014 at 16:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .