go-ethereum (geth) を起動する systemd サービスがあり、これが制御コンソールを提供するために使用される Unix ソケットを作成します。問題は、ユーザーとサービスのユーザーが両方とも同じグループに属し、作成されたファイルはサービス ユーザーとグループの両方によって自動的に所有されるにもかかわらず、geth プロセスがグループに rw 権限を自動的に付与しないため、ユーザーが Unix ソケットに接続できないことです。コンソールをsudo chmod 660 /path/to/socket使用する前にターミナルから実行することで自分でこれを修正できますが、可能であればこれを自動的に実行したいと思います。
[Service]私が試したのは、サービス ファイルのセクションに次のようなルールを追加することですExecStartPost=/bin/chmod 660 /path/to/socket。ただし、これは機能しません。サービス プロセスの開始とソケットの作成の間に遅延があるためだと思います。ExecStartPostその後、コマンドが失敗し、サービスがシャットダウンする原因になるようです。
これを修正するための 1 つのオプションは、ファイルの存在を繰り返し確認し、ファイルが検出されるとファイルの権限を変更するスクリプトを作成することです。その後、ルールを に変更できますExecStartPost=/path/to/script。同様のよりシンプルで堅牢性が低い解決策は、ルールを にすることですExecStartPost=/bin/bash -c "sleep 5 && /bin/chmod 660 /path/to/socket"。
この種のソリューションは最善の選択肢でしょうか、それとも systemd は私の目的に使用できる他の/よりシンプルなメカニズムを提供しているのでしょうか?
答え1
ここでの基本的な指針はソケットをバインドするものは何でも、AF_LOCALその権限を設定する必要がありますそうでなければ、ヒース・ロビンソンの不安定な仕掛けと同じことになる。
デーモン サービス プログラムがソケットを作成してバインドする場合は、ソケットの権限を指定できる構成オプションを探します。残念ながら、プログラムの作成者は、ユーザーがこれを行う必要があるとは考えていなかった可能性があります。
デーモンサービスプログラムにそのような設定メカニズムがない場合は、デーモンサービスプログラムを作成する必要があります。受け取る起動時に制御ソケットを既に開いているファイル記述子として設定し、LISTEN_FDSメカニズムを介してこのファイル記述子に関する情報を渡します（おそらく、接続要求を受け入れるリスニングソケットであるため）。次に、ソケットの作成とバインド、および権限の設定を担当するのはサービス管理であり、systemdするノブが付いています。
Accept=No次に、適切なListenStream設定 (おそらく制御インターフェースはストリーム ソケットのもの) と設定を含めて、そのソケットを記述する systemd ソケット ユニットを設定しますSocketMode=0660。