Best practice to run Linux service as a different user

Question

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  amp  gt  dev null  amp     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

User · Answer

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

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

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!

User · Answer

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

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

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!

User · Answer

On Debian we use the start-stop-daemon utility  which handles pid-files  changing the user  putting the daemon into background and much more   I m not familiar with RedHat  but the daemon utility that you are already using  which is defined in  etc init d functions  btw   is mentioned everywhere as the equivalent to start-stop-daemon  so either it can also change the uid of your program  or the way you do it is already the correct one   If you look around the net  there are several ready-made wrappers that you can use  Some may even be already packaged in RedHat  Have a look at daemonize  for example

User · Answer

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

User · Answer

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

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

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!

User · Answer

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

User · Answer

On Debian we use the start-stop-daemon utility  which handles pid-files  changing the user  putting the daemon into background and much more   I m not familiar with RedHat  but the daemon utility that you are already using  which is defined in  etc init d functions  btw   is mentioned everywhere as the equivalent to start-stop-daemon  so either it can also change the uid of your program  or the way you do it is already the correct one   If you look around the net  there are several ready-made wrappers that you can use  Some may even be already packaged in RedHat  Have a look at daemonize  for example

User · Answer

Why not try the following in the init script   setuid  USER application name   It worked for me

User · Answer

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

User · Answer

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

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

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!

User · Answer

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

User · Answer

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   Make use of its root privileges  e g  open log files  create pid files   Drop its root privileges at a certain point during startup

User · Answer

On Debian we use the start-stop-daemon utility  which handles pid-files  changing the user  putting the daemon into background and much more   I m not familiar with RedHat  but the daemon utility that you are already using  which is defined in  etc init d functions  btw   is mentioned everywhere as the equivalent to start-stop-daemon  so either it can also change the uid of your program  or the way you do it is already the correct one   If you look around the net  there are several ready-made wrappers that you can use  Some may even be already packaged in RedHat  Have a look at daemonize  for example

User · Answer

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   Make use of its root privileges  e g  open log files  create pid files   Drop its root privileges at a certain point during startup

User · Answer

Why not try the following in the init script   setuid  USER application name   It worked for me

User · Answer

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   Make use of its root privileges  e g  open log files  create pid files   Drop its root privileges at a certain point during startup

User · Answer

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

User · Answer

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   Make use of its root privileges  e g  open log files  create pid files   Drop its root privileges at a certain point during startup

User · Answer

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

User · Answer

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

User · Answer

On Debian we use the start-stop-daemon utility  which handles pid-files  changing the user  putting the daemon into background and much more   I m not familiar with RedHat  but the daemon utility that you are already using  which is defined in  etc init d functions  btw   is mentioned everywhere as the equivalent to start-stop-daemon  so either it can also change the uid of your program  or the way you do it is already the correct one   If you look around the net  there are several ready-made wrappers that you can use  Some may even be already packaged in RedHat  Have a look at daemonize  for example

User · Answer

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

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

Examples related to linux

Examples related to sysadmin

Examples related to rhel

Examples related to init.d