I need a linux user (lets call him "bob") who is allowed to run a list of commands which require root privileges. So let him be required to run /sbin/firstcommand and /sbin/secondcommand (which are part of the infamous bob-daemon¹) as root, as in sudo firstcommand. Without having to input a password.

This is what I've done to /etc/sudoers so far:

Cmnd_Alias BOBCOMMANDS = /sbin/firstcommand, /sbin/secondcommand

This leads to bob$ sudo firstcommand and bob$ sudo secondcommand successfully be run as root, but leaves no way to run i.e. bob$ sudo mount ... ..., even with providing a password, which feels perfect to me.

Now, I want the aforementioned bob-daemon¹ to run as user bob rather than root, because it only needs those privileges for the BOBCOMMANDS. In fact, whenever the bob$ firstcommand is issued, I want bob$ sudo firstcommand to be executed.

Looked to me like an alias could fix this: bob$ alias firstcommand="sudo firstcommand"; alias secondcommand="sudo secondcommand" actually worked, but I failed to make the aliases persistent without bob having a home directory.

The last thing I should mention is that this should be easily deployable to multiple machines, so I would prefer not to touch linux' existing system files, apart from having to create bob and changing sudoers.

Any solutions?

¹ simplified by me

  • How you start the daemon; with systemd ? or is it possible to set it up with systemd units?
    – Maze
    Commented Mar 3, 2020 at 19:57

2 Answers 2


You said the commands the user needs to run with root privileges are /sbin/firstcommand and /sbin/secondcommand?

If those commands are indeed located in /sbin, that is a directory which is not included in the regular user PATH by default. You can use this to your advantage: you could create two very simple scripts /usr/local/bin/firstcommand and /usr/local/bin/secondcommand, whose contents would essentially be just the sudo /sbin/firstcommand and sudo /sbin/secondcommand respectively.

The user's shell will normally look for /usr/local/bin before the standard /usr/bin and /bin, allowing the system administrator to override the standard system commands with local versions if necessary. In much the same way, when the user runs firstcommand, they'll end up running whichever version of firstcommand can be found first in their PATH... which can be a script of your choosing that runs the real /sbin/firstcommand prefixed with sudo and/or with some parameters appended as necessary.

The actual program files and other system files won't need to be modified at all, other than for the configuration of the necessary sudo access.


If this is for a daemon, the standard way of doing things is to put something like this in the init script file:

su -c '/command/to/start/actual/daemon' "$USER"

In the script file that should be run as bob, just put sudo in front of the pertinent commands.

Also, make sure you read this about enabling alias expansion in non-interactive Bash shells (e.g. the ones started by a script or daemon).

  • Actually, the daemon handles user switching itself - started up as root, it does some bootstraps before forking and continuing to run as bob. Plus, I did not create the daemon and would like to avoid patching it for the sake of updatability …
    – LDericher
    Commented Oct 28, 2014 at 12:07

You must log in to answer this question.

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