roteiro de chamada de script como outro usuário

Question

Usando o CentOs, quero executar um script como 'treinamento' do usuário como um serviço do sistema. Eu uso daemontools para monitorar o processo, que precisa de um script de inicialização que é executado como root:

1. :

   #!/bin/bash
   exec >> /var/log/training_service.log 2>&1
   setuidgid training training_command
   

   Esta última linha não é boa o suficiente, pois para o training_command, precisamos que o ambiente para o treinamento do usuário seja definido.

2. :

   su - training -c 'training_command' 
   

   fornece ' standard in must be tty ' como su, certificando-se de que tty está presente para potencialmente aceitar a senha. Eu sei que poderia fazer isso desaparecer modificando o / etc / sudoers a la Bash & 'su' script dando um erro "padrão deve ser um tty" , mas estou relutante e inseguro de consequências.

3. :

   runuser - training -c 'training_command' 
   

   dá runuser: cannot set groups: Connection refused . Não encontrei nenhum sentido ou resolução para esta mensagem.

4. :

   ssh -p100 training @ localhost 'source $ HOME / .bashrc; training_command '

Eu recebo Host key verification failed. (a chave do host IS em known_hosts, etc).

Nota: todo o 2,3,4 funciona como deveria se eu executar o script wrapper a partir de um shell de raiz. os problemas só ocorrerão se o monitor de serviço do sistema (daemontools) o iniciar (no tty terminal eu acho).

Estou preso. Isso é algo tão difícil de alcançar?

Eu aprecio toda a visão e orientação para as melhores práticas.

    

Answer 1

Crie o ambiente em seu script de inicialização se a solução do Mugen kenichi não for uma opção. Eu tenho alguns scripts de inicialização que usam a abordagem do Mugen e outros que originam o ambiente diretamente no script. Muitas vezes é simplesmente uma questão de preferência. Fornecer o ambiente diretamente no script de inicialização é mais transparente para outros usuários que podem editar o script (ou daqui a 6 meses).

Como meu ambiente é composto de muitas condicionais, é mais fácil ser implícito. Aqui estão as primeiras linhas de um dos meus scripts de inicialização:

#!/bin/bash
. /my/tools/environment/apps/apps_rc
. /my/tools/environment/functions/common.bash 

Quando isso for feito, use su normalmente para iniciar o processo como o usuário em questão.

Aqui está uma amostra de como eu inicio processos similares usando su .

su -l $USER -c "nohup $APP_PATH" >> $LOG_FILE 2>&1 < /dev/null &

Como opção, você também pode ver o pacote daemonize . Eu uso bastante também.

Finalmente ...

A partir da sua pergunta, parece que você pode querer executar o script como um usuário privilegiado, você pode realmente precisar definir o bit setuid no script para permitir que ele seja executado como root por um uso normal. Isso pode ter uma implicação de segurança, então saiba o que você está fazendo quando faz isso.

    

Answer 2

Você precisará desativar a configuração requiretty em /etc/sudoers para root . Adicione a seguinte linha via visudo :

Defaults:root !requiretty

Você também precisará da seguinte linha em /etc/sudoers , então root pode fazer tudo (isso deve ser ativado por padrão, mas verifique se):

root ALL=(ALL) ALL

Então você pode fazer o seguinte:

sudo -u training /path/to/training_command