[linux] Best practice to run Linux service as a different user

Services default to starting as root at boot time on my RHEL box. If I recall correctly, the same is true for other Linux distros which use the init scripts in /etc/init.d.

What do you think is the best way to instead have the processes run as a (static) user of my choosing?

The only method I'd arrived at was to use something like:

 su my_user -c 'daemon my_cmd &>/dev/null &'

But this seems a bit untidy...

Is there some bit of magic tucked away that provides an easy mechanism to automatically start services as other, non-root users?

EDIT: I should have said that the processes I'm starting in this instance are either Python scripts or Java programs. I'd rather not write a native wrapper around them, so unfortunately I'm unable to call setuid() as Black suggests.

After looking at all the suggestions here, I've discovered a few things which I hope will be useful to others in my position:

1. hop is right to point me back at /etc/init.d/functions: the daemon function already allows you to set an alternate user:

   daemon --user=my_user my_cmd &>/dev/null &
   

   This is implemented by wrapping the process invocation with runuser - more on this later.

2. Jonathan Leffler is right: there is setuid in Python:

   import os
   os.setuid(501) # UID of my_user is 501
   

   I still don't think you can setuid from inside a JVM, however.

3. Neither su nor runuser gracefully handle the case where you ask to run a command as the user you already are. E.g.:

   [my_user@my_host]$ id
   uid=500(my_user) gid=500(my_user) groups=500(my_user)
   [my_user@my_host]$ su my_user -c "id"
   Password: # don't want to be prompted!
   uid=500(my_user) gid=500(my_user) groups=500(my_user)
   

To workaround that behaviour of su and runuser, I've changed my init script to something like:

if [[ "$USER" == "my_user" ]]
then
    daemon my_cmd &>/dev/null &
else
    daemon --user=my_user my_cmd &>/dev/null &
fi

Thanks all for your help!

Just to add some other things to watch out for:

• Sudo in a init.d script is no good since it needs a tty ("sudo: sorry, you must have a tty to run sudo")
• If you are daemonizing a java application, you might want to consider Java Service Wrapper (which provides a mechanism for setting the user id)
• Another alternative could be su --session-command=[cmd] [user]

• Some daemons (e.g. apache) do this by themselves by calling setuid()
• You could use the setuid-file flag to run the process as a different user.
• Of course, the solution you mentioned works as well.

If you intend to write your own daemon, then I recommend calling setuid(). This way, your process can

1. Make use of its root privileges (e.g. open log files, create pid files).
2. Drop its root privileges at a certain point during startup.

After looking at all the suggestions here, I've discovered a few things which I hope will be useful to others in my position:

1. hop is right to point me back at /etc/init.d/functions: the daemon function already allows you to set an alternate user:

   daemon --user=my_user my_cmd &>/dev/null &
   

   This is implemented by wrapping the process invocation with runuser - more on this later.

2. Jonathan Leffler is right: there is setuid in Python:

   import os
   os.setuid(501) # UID of my_user is 501
   

   I still don't think you can setuid from inside a JVM, however.

3. Neither su nor runuser gracefully handle the case where you ask to run a command as the user you already are. E.g.:

   [my_user@my_host]$ id
   uid=500(my_user) gid=500(my_user) groups=500(my_user)
   [my_user@my_host]$ su my_user -c "id"
   Password: # don't want to be prompted!
   uid=500(my_user) gid=500(my_user) groups=500(my_user)
   

To workaround that behaviour of su and runuser, I've changed my init script to something like:

if [[ "$USER" == "my_user" ]]
then
    daemon my_cmd &>/dev/null &
else
    daemon --user=my_user my_cmd &>/dev/null &
fi

Thanks all for your help!

Some things to watch out for:

• As you mentioned, su will prompt for a password if you are already the target user
• Similarly, setuid(2) will fail if you are already the target user (on some OSs)
• setuid(2) does not install privileges or resource controls defined in /etc/limits.conf (Linux) or /etc/user_attr (Solaris)
• If you go the setgid(2)/setuid(2) route, don't forget to call initgroups(3) -- more on this here

I generally use /sbin/su to switch to the appropriate user before starting daemons.

• Some daemons (e.g. apache) do this by themselves by calling setuid()
• You could use the setuid-file flag to run the process as a different user.
• Of course, the solution you mentioned works as well.

If you intend to write your own daemon, then I recommend calling setuid(). This way, your process can

1. Make use of its root privileges (e.g. open log files, create pid files).
2. Drop its root privileges at a certain point during startup.

on a CENTOS (Red Hat) virtual machine for svn server: edited /etc/init.d/svnserver to change the pid to something that svn can write:

pidfile=${PIDFILE-/home/svn/run/svnserve.pid}

and added option --user=svn:

daemon --pidfile=${pidfile} --user=svn $exec $args

The original pidfile was /var/run/svnserve.pid. The daemon did not start becaseu only root could write there.

 These all work:
/etc/init.d/svnserve start
/etc/init.d/svnserve stop
/etc/init.d/svnserve restart

Why not try the following in the init script:

setuid $USER application_name

It worked for me.

• Some daemons (e.g. apache) do this by themselves by calling setuid()
• You could use the setuid-file flag to run the process as a different user.
• Of course, the solution you mentioned works as well.

If you intend to write your own daemon, then I recommend calling setuid(). This way, your process can

1. Make use of its root privileges (e.g. open log files, create pid files).
2. Drop its root privileges at a certain point during startup.

After looking at all the suggestions here, I've discovered a few things which I hope will be useful to others in my position:

1. hop is right to point me back at /etc/init.d/functions: the daemon function already allows you to set an alternate user:

   daemon --user=my_user my_cmd &>/dev/null &
   

   This is implemented by wrapping the process invocation with runuser - more on this later.

2. Jonathan Leffler is right: there is setuid in Python:

   import os
   os.setuid(501) # UID of my_user is 501
   

   I still don't think you can setuid from inside a JVM, however.

3. Neither su nor runuser gracefully handle the case where you ask to run a command as the user you already are. E.g.:

   [my_user@my_host]$ id
   uid=500(my_user) gid=500(my_user) groups=500(my_user)
   [my_user@my_host]$ su my_user -c "id"
   Password: # don't want to be prompted!
   uid=500(my_user) gid=500(my_user) groups=500(my_user)
   

To workaround that behaviour of su and runuser, I've changed my init script to something like:

if [[ "$USER" == "my_user" ]]
then
    daemon my_cmd &>/dev/null &
else
    daemon --user=my_user my_cmd &>/dev/null &
fi

Thanks all for your help!

on a CENTOS (Red Hat) virtual machine for svn server: edited /etc/init.d/svnserver to change the pid to something that svn can write:

pidfile=${PIDFILE-/home/svn/run/svnserve.pid}

and added option --user=svn:

daemon --pidfile=${pidfile} --user=svn $exec $args

The original pidfile was /var/run/svnserve.pid. The daemon did not start becaseu only root could write there.

 These all work:
/etc/init.d/svnserve start
/etc/init.d/svnserve stop
/etc/init.d/svnserve restart

Just to add some other things to watch out for:

• Sudo in a init.d script is no good since it needs a tty ("sudo: sorry, you must have a tty to run sudo")
• If you are daemonizing a java application, you might want to consider Java Service Wrapper (which provides a mechanism for setting the user id)
• Another alternative could be su --session-command=[cmd] [user]

I needed to run a Spring .jar application as a service, and found a simple way to run this as a specific user:

I changed the owner and group of my jar file to the user I wanted to run as. Then symlinked this jar in init.d and started the service.

So:

#chown myuser:myuser /var/lib/jenkins/workspace/springApp/target/springApp-1.0.jar

#ln -s /var/lib/jenkins/workspace/springApp/target/springApp-1.0.jar /etc/init.d/springApp

#service springApp start

#ps aux | grep java
myuser    9970  5.0  9.9 4071348 386132 ?      Sl   09:38   0:21 /bin/java -Dsun.misc.URLClassPath.disableJarChecking=true -jar /var/lib/jenkins/workspace/springApp/target/springApp-1.0.jar

Some things to watch out for:

• As you mentioned, su will prompt for a password if you are already the target user
• Similarly, setuid(2) will fail if you are already the target user (on some OSs)
• setuid(2) does not install privileges or resource controls defined in /etc/limits.conf (Linux) or /etc/user_attr (Solaris)
• If you go the setgid(2)/setuid(2) route, don't forget to call initgroups(3) -- more on this here

I generally use /sbin/su to switch to the appropriate user before starting daemons.

I needed to run a Spring .jar application as a service, and found a simple way to run this as a specific user:

I changed the owner and group of my jar file to the user I wanted to run as. Then symlinked this jar in init.d and started the service.

So:

#chown myuser:myuser /var/lib/jenkins/workspace/springApp/target/springApp-1.0.jar

#ln -s /var/lib/jenkins/workspace/springApp/target/springApp-1.0.jar /etc/init.d/springApp

#service springApp start

#ps aux | grep java
myuser    9970  5.0  9.9 4071348 386132 ?      Sl   09:38   0:21 /bin/java -Dsun.misc.URLClassPath.disableJarChecking=true -jar /var/lib/jenkins/workspace/springApp/target/springApp-1.0.jar

After looking at all the suggestions here, I've discovered a few things which I hope will be useful to others in my position:

1. hop is right to point me back at /etc/init.d/functions: the daemon function already allows you to set an alternate user:

   daemon --user=my_user my_cmd &>/dev/null &
   

   This is implemented by wrapping the process invocation with runuser - more on this later.

2. Jonathan Leffler is right: there is setuid in Python:

   import os
   os.setuid(501) # UID of my_user is 501
   

   I still don't think you can setuid from inside a JVM, however.

3. Neither su nor runuser gracefully handle the case where you ask to run a command as the user you already are. E.g.:

   [my_user@my_host]$ id
   uid=500(my_user) gid=500(my_user) groups=500(my_user)
   [my_user@my_host]$ su my_user -c "id"
   Password: # don't want to be prompted!
   uid=500(my_user) gid=500(my_user) groups=500(my_user)
   

To workaround that behaviour of su and runuser, I've changed my init script to something like:

if [[ "$USER" == "my_user" ]]
then
    daemon my_cmd &>/dev/null &
else
    daemon --user=my_user my_cmd &>/dev/null &
fi

Thanks all for your help!

Why not try the following in the init script:

setuid $USER application_name

It worked for me.