Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question
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 '13 at 14:27
yes, it's a python program. os.setuid is what i should do, right? – Waleed Hamra Feb 19 '13 at 14:31
You could check if os.getuid() returns 0, then switch to another uid. – ott-- Feb 19 '13 at 14:35
up vote 1 down vote accepted

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".

share|improve this answer
I ended up doing that. I figured i can use os.setuid, which is a far cleaner solution than using sudo or su. – Waleed Hamra Feb 20 '13 at 12:13

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.

share|improve this answer

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.

share|improve this answer

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:

share|improve this answer
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 '13 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 '13 at 15:15
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 '14 at 16:38

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.