script appelant script comme autre utilisateur

En utilisant CentOs, je souhaite exécuter un script en tant que "formation" d’utilisateur en tant que service système. J'utilise daemontools pour surveiller le processus, ce qui nécessite un script de lancement exécuté en tant que root:

1. :

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

   Cette dernière ligne n'est pas suffisante car pour training_command, nous avons besoin d'un environnement permettant de définir l'utilisateur de la formation.

2. :

   su - training -c 'training_command' 
   

   donne ' standard in must be tty' as su en s'assurant que tty est présent pour potentiellement accepter le mot de passe. Je sais que je pourrais le faire disparaître en modifiant / etc / sudoers à la Bash et en écrivant le script 'su' en donnant une erreur "le standard doit être un tty" mais je suis réticent et incertain des conséquences.

3. :

   runuser - training -c 'training_command' 
   

   donne runuser: cannot set groups: Connection refused. Je n'ai trouvé aucun sens ou résolution à ce message.

4. :

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

Je reçois Host key verification failed.(la clé de l'hôte IS est dans known_hosts, etc.).

Remarque: tous les 2,3,4 fonctionnent comme ils le devraient si j'exécute le script d'emballage à partir d'un shell root. des problèmes ne surviennent que si le moniteur de maintenance du système (daemontools) le lance (pas de terminal tty, je suppose).

Je suis coincé. Est-ce si difficile à réaliser?

J'apprécie toutes les idées et tous les conseils relatifs aux meilleures pratiques.

Source l'environnement dans votre script de démarrage si la solution de mugen kenichi n'est pas une option. J'ai des scripts de démarrage qui utilisent l'approche de mugen et d'autres qui source l'environnement directement dans le script. C'est souvent simplement une question de préférence. La recherche de l'environnement directement dans le script de démarrage est plus transparente pour les autres utilisateurs susceptibles de l'éditer (ou dans 6 mois à compter de maintenant).

Comme mon environnement est composé de beaucoup de conditionnels, il est plus facile d’être implicite. Voici les premières lignes d'un de mes scripts de démarrage:

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

Une fois que cela est fait, utilisez su comme d'habitude pour lancer le processus en tant qu'utilisateur en question.

Voici un exemple de la façon dont je commence des processus similaires en utilisant su.

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

En option, vous pouvez également consulter le paquet daemonize . Je l'utilise aussi un peu.

Finalement...

À partir de votre question, il semble que vous souhaitiez peut-être exécuter le script en tant qu'utilisateur privilégié. Vous devrez peut-être définir le bit setuid sur le script pour lui permettre de s'exécuter en tant que root par une utilisation normale. Cela peut avoir un impact sur la sécurité, alors sachez ce que vous faites quand vous le faites.

Vous devrez désactiver le requirettyparamètre /etc/sudoerspour root. Ajoutez la ligne suivante via visudo:

Defaults:root !requiretty

Vous aurez également besoin de la ligne suivante /etc/sudoerspour rootpouvoir tout faire (ceci doit être activé par défaut, mais vérifiez bien):

root ALL=(ALL) ALL

Ensuite, vous pouvez faire ce qui suit:

sudo -u training /path/to/training_command