A melhor prática para executar serviço Linux como um usuário diferente

Question

Serviços padrão para iniciar como root no momento da inicialização na minha caixa RHEL. Se bem me lembro, o mesmo é verdadeiro para outras distros Linux que usam os scripts de inicialização em /etc/init.d.

O que você acha que é a melhor maneira de vez têm os processos executados como um usuário (estático) da minha escolha?

O único método que eu tinha chegado a era usar algo como:

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

Mas isso parece um pouco desarrumado ...

Existe algum pouco de magia escondido que fornece um mecanismo fácil para iniciar automaticamente serviços como usuários outro, não raiz?

EDIT: Eu deveria ter dito que os processos que eu estou começando neste caso são ou scripts Python ou programas Java. Eu prefiro não escrever um wrapper nativa em torno deles, por isso, infelizmente, eu sou incapaz de chamar setuid () como preto sugere.

Answer 1

No Debian usamos o utilitário start-stop-daemon, que alças, mudando o usuário, colocando o daemon em segundo plano e muito mais-arquivos PID.

Eu não estou familiarizado com RedHat, mas o utilitário daemon que você já está usando (que é definido no /etc/init.d/functions, btw.) É mencionado em todos os lugares como o equivalente a start-stop-daemon, por isso ou ele também pode mudar o uid do seu programa , ou a maneira como você faz isso já é o correto.

Se você olhar em torno da rede, existem vários invólucros prontos que você pode usar. Alguns podem até já estar embalados em RedHat. Ter um olhar para daemonize , por exemplo.

Answer 2

Depois de olhar para todas as sugestões aqui, eu descobri algumas coisas que eu espero que seja útil para os outros na minha posição:

1. hop é direito de apontar-me de volta em /etc/init.d/functions: o função daemon já permite para definir um usuário alternativo:

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

   Esta é implementado por envolver o invocação processo com runuser - mais sobre isso mais tarde.

2. Jonathan Leffler está certo: não é setuid em Python:

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

   Eu ainda não acho que você pode setuid de dentro de um JVM, no entanto.

3. Nem su nem runuser graciosamente lidar com o caso onde você pedir para executar um comando como o usuário que você já estão. Por exemplo:.

   [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)
   

Para solucionar esse comportamento de su e runuser, eu mudei meu script de inicialização para algo como:

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

Obrigado a todos por sua ajuda!

Answer 3

• Alguns daemons (por exemplo apache) fazer isso por si mesmos, chamando setuid ()
• Você pode usar a bandeira setuid-file para executar o processo como um usuário diferente.
• É claro que a solução que você mencionou obras também.

Se você pretende escrever seu próprio daemon, então eu recomendo chamar setuid (). Desta forma, o processo pode

1. Fazer uso de seus privilégios de root (por exemplo, arquivos de log abertos, criar arquivos PID).
2. Solte seus privilégios de root em um determinado ponto durante a inicialização.

Answer 4

Apenas para adicionar algumas outras coisas que atente para:

• Sudo em um script init.d não é bom, uma vez que necessita de um tty ( "sudo: desculpe, você deve ter um tty para executar sudo")
• Se você está daemonizing uma aplicação java, você pode querer considerar Java Serviço Wrapper (que fornece um mecanismo para definir o ID de usuário)
• Outra alternativa poderia ser su --session-command = [cmd] [usuário]

Answer 5

em uma CENTOS (Red Hat) máquina virtual para o servidor svn: /etc/init.d/svnserver editado para mudar o pid a algo que svn pode escrever:

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

e acrescentou opção --user=svn:

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

O pidfile original /var/run/svnserve.pid. O daemon não começou becaseu somente o root pode escrever lá.

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

Answer 6

Algumas coisas que atente para:

• Como você mencionou, su irá solicitar uma senha se você já é usuário-alvo
• Da mesma forma, setuid (2) falhará se você já é usuário-alvo (em alguns OSs)
• setuid (2) não instala privilégios ou controles de recursos definidos no /etc/limits.conf (Linux) ou / etc / user_attr (Solaris)
• Se você for a setgid (2) / setuid (2) rota, não se esqueça de chamar initgroups (3) - mais sobre isso aqui

Eu geralmente uso / sbin / su para mudar para o usuário apropriado antes de iniciar daemons.

Answer 7

Por que não tentar o seguinte no script de inicialização:

setuid $USER application_name

Ela trabalhou para mim.

Answer 8

eu precisava para executar o aplicativo uma mola .jar como um serviço, e encontrou uma maneira simples de executar este como um usuário específico:

Eu mudei o proprietário eo grupo do meu arquivo jar para o usuário Eu queria correr como. Em seguida, simbolicamente este frasco em init.d e começou o serviço.

Assim:

#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