go-ethereum（geth）を起動し、コンソールを提供するUnixソケットを作成するsystemdサービスがあります。私の問題は、私のユーザーとサービスユーザーの両方が同じグループ内にあり、生成されたファイルが自動的にサービスユーザーとグループによって所有されていますが、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メカニズムを介してそのファイル記述子に関する情報を渡します（おそらく接続要求を受け入れるリスニングソケットであるため）。その後、ソケットを作成してバインドし、その権限を設定するサービス管理があります。する取っ手があります。
Accept=No次に、適切なListenStream設定（制御インターフェイスがストリームソケットであると仮定）と設定を含むソケットを記述するシステムソケットデバイスを設定しますSocketMode=0660。