非特権ユーザーとしてupstartジョブを実行する

upstartジョブでユーザーIDを変更し、非特権ユーザーとしてスクリプトを実行する標準的な方法は何ですか？

明らかに、suまたはを使用できますsudoが、これはハックのようです（そして、不必要なログ行を生成する可能性があります）。

upstart v1.4では、setuidおよびsetgidが構成ファイルでネイティブにサポートされます。

freenodeの#upstartチャンネルで質問すると、公式の問題は次のとおりです。

Upstartの将来のリリースでは、ネイティブサポートが提供されますが、現時点では、次のようなものを使用できます。

exec su -s /bin/sh -c 'exec "$0" "$@"' username -- /path/to/command [parameters...]

start-stop-daemonを使用してはどうですか？

exec start-stop-daemon --start --chuid daemonuser --exec /bin/server_cmd

Upstartクックブックから：

DebianおよびUbuntuシステムで推奨される方法は、ヘルパーユーティリティを使用することですstart-stop-daemon。[…] start-stop-daemon開始するプロセスにPAM（「プラグ可能認証モジュール」）の制限を課しません。

注：start-stop-daemonRHELではサポートされていません。

いくつかの方法がありますが、特にグループメンバーシップに関連するセマンティクスが少しずつ異なります。

• setuidgid 指定したグループに入れられます。

  • 元のdaemontools setuidgidは、あなたをそのグループにのみ配置するので、あなたがメンバーになっている他のグループに属するファイルにアクセスすることはできません。
  • setuidgiddaemontools-アンコールからとsetuidgid間食ツールセットから両方持っている-s（別名--supplementaryのすべてに、そのグループにあなたを置く、ともあなたを配置します）オプション補助グループ指定したユーザーのために。

• 使用してnewgrpあなたがになった後、以下の特権ユーザは、自分のグループセットに単一のグループを追加するだけでなく、スクリプト内で使用することがトリッキー作り、新しいサブシェルを作成します。

• start-stop-daemon グループメンバーシップを保持し、setuid / setgid以外にも多くのことを行います。

• chpst -u username:group1:group2:group3... commandname採用するグループメンバーシップを正確に指定できますが、（Ubuntuでは）runitパッケージにのみ付属し、これはの代替upstartです。

• su -c commandname usernameと同様に、ユーザー名のすべてのグループメンバーシップを取得するsudo -u username commandnameため、これらはおそらく最も驚いたことになります。

setuidgidパッケージから使用しますdaemontools。

ここのドキュメント：http : //cr.yp.to/daemontools/setuidgid.html

Amazon EC2上のUbuntu 10.10インスタンスでは、このstart-stop-daemonコマンドのほうが幸運でした。

他の新興スタンザにも苦労しました。私はvirtualenv、実行したプログラムに特定のパラメーターを指定してpythonアプリケーションを呼び出しています。

以下は私のために働いたものです。

script
  export PYTHONPATH=.:/home/ubuntu/.local/lib/python2.7/site-packages/:/home/ubuntu/python/lib/python2.7/site-packages/
  exec start-stop-daemon --start  --chuid ubuntu --exec /home/ubuntu/python_envs/MyProj/bin/python /home/ubuntu/www/MyProj/MyProj.py -- --config-file-dir=/home/ubuntu/www/MyProj/config/ >> /home/ubuntu/startup.log 2>&1 &
end script

これPYTHONPATHは、このアップスタートジョブの実行時に、ソースからPYTHONモジュールパスにインストールされたいくつかのパッケージを取得することです。chdirスタンザは機能していないようでしたので、絶対パスですべてを行わなければなりませんでした。

私はCentOS 6を使用していましたが、推奨されるハック（Upstart 0.6.5用）を得ることができませんでした。また、関与するフォークの数（4と思う）が「期待するフォーク」によって追跡されなかったため、「su」トリックを取得できませんでした'または'デーモンを期待する '。

最終的にやった

chown user:group executable
chmod +s executable

（つまり、setuidビットを設定し、所有権を変更します）。

これは最も安全な方法ではないかもしれませんが、社内のR＆Dプロジェクトにとっては、このケースでは重要ではありませんでした。

あなたが達成しようとしているものに応じて、第三の可能性があります。問題のファイル/デバイスのアクセス制御を緩めることができる場合があります。これにより、権限のないユーザーは、通常は許可されないアイテムをマウントまたはアクセスできます。その過程で王国の鍵を渡さないようにしてください。

sudoパスワードキャッシュのタイムアウトを変更することもできます。しかし、あなたのマシンが物理的に安全でなければ（つまり、通行人がsudoアクセスを取得しようとする可能性は低いと思われる場合）、お勧めしません。

特権アクションを実行する方法がほとんどなく、不 必要な必要なロギングを実行するという正当な理由があります。緩い制限はシステムのセキュリティ上の危険であり、ログの欠如は、侵害されたときに何が起こったかを知る方法がないことを意味します。

場合はサイズログファイルのが懸念される、その後、何かはおそらく間違っています。通常の状態では、sudoは使用ごとに1行のみを生成します。

CentOS 6 upstart 0.6.5では、次のことがうまくいきました。

script

    exec su user_name << EOF
        exec /path/to/command [parameters...]
EOF

end script

または ：

script

    exec su user_name << EOF
       ..... what you want to do ....
EOF

end script

使用するとき

exec su -s /bin/sh -c 'exec "$0" "$@"' username -- /path/to/command [parameters...]

でジョブプロセスを停止することはできませんinitclt stop。その理由は次のとおりだと思います。

1. the job forked and the main process is not tracked.
2. the main process changed its process group,because of `su -c`