☰

systemd - "DynamicUser"オプションはユーザー単位で機能しますか？それではどうですか？

tag-icon • tag-icon systemd documentation systemd-unit
systemd - "DynamicUser"オプションはユーザー単位で機能しますか？それではどうですか？

systemdのシステムデバイス（ユーザーが動作するデバイス（デフォルト））の場合、systemdはユーザーとグループをサービスに動的に割り当ててサンドボックスを実装するようにsystemctl --system指定できます。DynamicUser=yes

しかし、読むとき手動ユーザー単位（）で動作しているかどうか、および方法についての言及が見つかりませんsystemctl --user。だから私の質問は次のようになります

  • DynamicUserユーザー単位で使用できますか？
  • それでは、どのように正確に処理されますか（つまり、システムデバイスで使用されるものと比較して違い/特異点は何ですか）。

公式または評判の良いソースの文書が望ましいが、使用できない場合も理解できます。よろしくお願いします。

答え1

DynamicUser=yes私はユーザー単位にあまり意味がないという点で@Iarsksのコメントに同意します。

明らかにユーザーを作成または切り替えることはできません。組織がユーザー組織である必要がある場合でも、これは望ましくありません。

では、なぜユニットDynamicUser=に追加するのですか--user？当然の答えは「セキュリティに良いと聞いたからだ」だろう。このような場合は、何かを考えてDynamicUser=意味のある部分を選択してください。

決定に役立つ2つのリソースは次のとおりです。

DynamicUser=--userバスに適したさまざまな機能を有効にします。次の機能をオンにすることを検討できます。

  • RemoveIPC=yes。デバイスが停止すると、そのユーザー/グループに属するすべてのIPCが破棄されます。--userそのバスで他のサービスを実行しない限り、これはおそらく良いことです。
  • NoNewPrivileges=yesパスワードのない設定や機能をRestrictSUIDSGID=yes悪用するスクリプトを防ぎます。この設定は、sudoユーザーモードまたはシステムモードで実行されたときに暗黙的に適用されます。User=RestrictSUIDSGID=yesNoNewPrivileges=yes
  • ProtectSystem=strictProtectHome=read-onlyサービスが任意のファイルシステムの場所に書き込むのを防ぎます。サービスが特定のコンテンツにアクセスできるようにするには、そのパスを指定しますReadWritePaths=。または、次のいくつかのオプションを使用して、このような一時パスを作成します。この機能は、ProjectHome=権限のないユーザーネームスペースが使用可能な場合にのみユーザーバスで使用できます。
  • PrivateTmp=yes：/tmp他のサービスでは使用できないプライベートアカウントを作成します。一時ファイルも自動的にクリーンアップされます。これは、権限のないユーザー名前空間が使用可能な場合は、ユーザーバスにのみ使用できます。
  • RuntimeDirectory=：ユーザー/グループが所有し、デバイスがシャットダウンすると自動的に削除される書き込み可能なランタイムディレクトリを作成します。
  • StateDirectory=、CacheDirectory= LogsDirectory=これらの特定の目的に書き込み可能なディレクトリを割り当てます。

関連情報