起動スクリプトで「Sudo」または「su」を使用する必要がありますか？
サーバー/クライアント設計のパーソナルプログラムがあります。
その一部のサーバーデーモンは、独自の制限付きユーザーとして実行する必要があり、プログラムは、一部のLinuxプログラムのように（rootとして起動した場合）root権限を削除するようには設計されていません。
だから私の質問は、/etc/init.d/、Sudoまたはsuを使用してこのデーモンを別のユーザーとして実行する必要がありますか？違いはありますか？ 2つのうちどちらでも機能しますか？他に何か？
オペレーティングシステムはカスタムのGNU/Linuxであり、「Linux From Scratch」の指示を使用して構築されており、両方のプログラムが正しく実行されています。
プログラムを簡単に変更して特権を削除できる場合は、これが最善の方法です。起動スクリプトでユーザーIDを切り替えることは、「機能する」場合でも、厄介で、柔軟性がありません。
2つのうち、私はこの目的のためにsuを使用します。これは、構成が少なく予測可能であるためです。 initスクリプトでSudoを使用していて、（偶然または意図的に）_/etc/sudoers_のroot ALL=(ALL) ALLエントリを削除すると、initスクリプトが不思議なことに壊れます。
さらに、次のフォームを使用して、構成フットプリントをさらに削減します。
_su -s /bin/sh -c "my_program my_args etc" my_user
__-s_オプションは、スクリプトを中断することなく、ユーザーのデフォルトのシェルを/ bin/falseまたは/ sbin/nologinなどに変更できることを意味します。プログラムがそれ自体をまだ処理していない場合は、標準I/Oを_/dev/null_または他の適切な場所にリダイレクトすることもできます。
便宜上、runitスーパーバイザスタックの chpst プログラムを確認することをお勧めします。これは非常に便利であり、コマンドラインパラメータのエスケープなどで混乱させることを防ぎます。これはSudo/suの問題です。
別のユーザーとしてプログラムを実行したい場合は、次のように呼び出します。
chpst -u my_user /path/to/program
これは、プログラムでsetsid、setgid、execveを実行します。それだけです（他にも多くの素晴らしい機能があります）。
ディストリビューションに busybox が含まれている場合は、chpstアプレットがコンパイルされているかどうかを確認することもできます。すでに持っている可能性があり、個別のパッケージは必要ありません。
技術的には、どちらも問題なく機能するはずですが、おそらくここでの慣例に従ってください。通常、sudoはrootに昇格して単一のコマンドを実行するために使用されますが、suは通常、新しいユーザーに変更してから、その新しいユーザーとしてコマンドを実行するために使用されます。
とはいえ、Googleで簡単に検索すると、Sudoとsuにはいくつかの見方があります。