他のユーザーとしてスクリプトを呼び出すスクリプト

CentOsを使用して、システムサービスとしてユーザー「トレーニング」としてスクリプトを実行します。daemontoolsを使用してプロセスを監視します。これには、rootとして実行されるランチャースクリプトが必要です。

1. ：

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

   training_commandには、ユーザーをトレーニングするための環境を設定する必要があるため、この最後の行は十分ではありません。

2. ：

   su - training -c 'training_command' 
   

   standard in must be tty潜在的にパスワードを受け入れるためにttyが存在することを確認してsuとして' 'を指定します。/ etc / sudoersをla Bash＆ 'su'スクリプトに変更して "standard in must be a tty"というエラーを出すことでこれをなくすことができることは知っ ていますが、結果に自信がありません。

3. ：

   runuser - training -c 'training_command' 
   

   与えるrunuser: cannot set groups: Connection refused。このメッセージに意味も解決もありませんでした。

4. ：

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

取得しますHost key verification failed.（ホストキーはknown_hostsなどにあります）。

注：ルートシェルからラッパースクリプトを実行すると、2,3,4のすべてが正常に機能します。問題は、システムサービスモニター（daemontools）が起動した場合にのみ発生します（tty端末はありません）。

ハマった。これを達成するのは難しいですか？

ベストプラクティスに対するすべての洞察とガイダンスに感謝します。

mugen kenichiのソリューションがオプションではない場合、起動スクリプトで環境を取得します。mugenのアプローチを使用するスタートアップスクリプトと、スクリプトで直接環境をソースするスタートアップスクリプトがあります。多くの場合、単に好みの問題です。スタートアップスクリプトで直接環境を調達することは、スクリプトを編集する可能性のある他のユーザー（または6か月後）に対してより透過的です。

私の環境は多くの条件で構成されているので、暗黙的にするほうが簡単です。スタートアップスクリプトの1つからの最初の数行は次のとおりです。

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

これが完了したら、通常どおりsuを使用して、問題のユーザーとしてプロセスを開始します。

を使用して同様のプロセスを開始する方法のサンプルを次に示しますsu。

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

オプションとして、daemonizeパッケージも見ることができます。私もかなり使います。

最後に...

あなたの質問から、特権ユーザーとしてスクリプトを実行したいように見えますが、実際にはスクリプトにsetuidビットを設定して、通常の使用でrootとして実行できるようにする必要があります。これはセキュリティに影響する可能性があるため、これを実行するときに何をしているかを把握してください。

あなたは無効にする必要がありますrequirettyに設定を/etc/sudoersためroot。次の行を追加しますvisudo：

Defaults:root !requiretty

また、すべてを実行できる/etc/sudoersように次の行も必要ですroot（これはデフォルトで有効になっているはずですが、確認してください）。

root ALL=(ALL) ALL

その後、次のことができます。

sudo -u training /path/to/training_command