☰

追加読書

tag-icon • tag-icon arch-linux systemd users systemd-unit
追加読書

私のアーチサーバーでは、ホームディレクトリのユーザーに制限するように設定しました。私は走る:

useradd -m -s /bin/bash usernameそしてpasswd username

私は読んだこのWiki記事...

各ユーザーが起動時にノードサーバーを実行できるようにするには、systemdユーザーサービスを使用する必要があると思います。そのため、ユーザーアカウントにログインsu usernameし、次のファイルを作成しました~/.config/systemd/user/serve.service。

[Unit]
Description=One of the servers

[Service]
ExecStart=/usr/bin/node /home/username/server.js

[Install]
WantedBy=default.target

それから私は走り、systemctl --user enable serve.serviceその答えは次のようになります。Failed to connect to bus: Permission denied

私が理解したのは、systemctl --user ...root以外のユーザーとしてコマンドを実行することです。

それでは、この構成で私が見逃しているものは何ですか？

答え1

だからユーザーアカウントにログインしました。su username

いいえ、そうではありません。

ログインしていません。 特権を強化しています。既存のログインセッションそしてsu username。

systemctlこの--userオプションは、ユーザー固有のデスクトップバスを検索し、ユーザー固有のデスクトップバスデーモンによって管理され、このバスを介してユーザー固有のsystemdサービスを管理するユーザー固有のインスタンスと通信します。

suログインメカニズムではありません。効果がある既存対話型ログインセッション。そのセッション内で、プロセスには、ユーザーごとのランタイムディレクトリの場所（XDG_RUNTIME_DIR）、ユーザーごとのデスクトップバスの場所（）、およびXサーバーの場所（）DBUS_SESSION_BUS_ADDRESSなどの他の情報を知らせる環境変数があります。DISPLAY

特に、同じパスをDBUS_SESSION_BUS_ADDRESS暗黙的に参照するか、明示的に名前を付けることができます。XDG_RUNTIME_DIRパスは通常、/run/user/1001/busDesktop Bus Agentのアクセスソケットに似ています（たとえば、ユーザーIDが1001であると仮定）。

これらの変数は変更されませんsu。 pkexec.

その結果、suログインセッションで2番目のユーザーに接続している場合は、systemctlその2番目のユーザーとして実行すると、最初のユーザーのプライベートディレクトリにあるDesktop Bus Agentアクセスソケットに接続しようとします。ユーザー1002（たとえば、2番目のユーザーのユーザーIDの選択）は、/run/user/1001その中にあるものにはアクセスできません。 xeがディレクトリへの読み取り+実行アクセス権を持っていても、xeは/run/user/1001/busユーザー1001権限にのみアクセス権を付与するため、そのディレクトリにアクセスできません。

もちろん、これはいいえ正しいデスクトップバスブローカーに相談して始めてください。あなたとコミュニケーションしたいですか？第二ユーザーのデスクトップバスはそれを介してプロキシされ、2番目のユーザーのユーザー固有のインスタンスに到達しますsystemd。

簡単な解決策は、suこれらの環境変数を2番目のユーザーアカウントに適した環境変数に設定して、2番目のユーザーのデスクトップバスを指すことです。

DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1002/bus su ユーザー名 -c 'systemctl --user'

もちろん、この場合、便利なツールを使用して設定すると、userenvそのバスアドレスを手動で入力する必要はありません。

su ユーザー名 -c 'userenv --set-dbus systemctl --user'

追加読書

関連情報