systemdユーザーがユーザーグループの権限を取得できません


8

dockerグループに非rootユーザーを追加し、この非rootユーザーがdockerデーモンに接続すると、他のサービスが実行されました。しかし、サービスは機能しません。私はこれのテスト例を行います:

root@# systemctl start docker.service 
root@# gpasswd -a tiger docker

tigerでsystemdサービスを作成します。

[Service]
ExecStart=/home/tiger/connectdocker
Restart=always
StartLimitInterval=0
Delegate=true
KillMode=process
[Install]
WantedBy=default.target

この/home/tiger/connectdockerような:

docker run -itd busybox 2> connectdocker.log

このサービスを開始します。

tiger@# systemctl --user enable connectdocker.service
tiger@# systemctl --user start connectdocker.service

そして結果:

Thu Jul 21 00:59:15 CST 2016
Cannot connect to the Docker daemon. Is the docker daemon running on this host?

しかし、私はtigerでdocker.sockに接続できます:

tiger@# docker run -itd busybox
997e99f959cfd5500319935ec17677775da9d367d203a11efef8b42161c3ee64

それを証明するために、私は/var/run/docker.sockグループをdockerからtiger に変更し、connectdockerサービスはdockerデーモンに接続できます。

変更/var/run/docker.sock

ls -l /run/docker.sock
srw-rw---- 1 root docker 0 Jul 21 00:33 /run/docker.sock

に:

ls -l /run/docker.sock
srw-rw---- 1 root tiger 0 Jul 21 00:33 /run/docker.sock

1
これが機能したことはありますか?
Mark Stosberg、2017年

回答:


1

サービスでUser=ディレクティブを使用する必要がありますsystemd

ユーザー=、グループ=

プロセスが実行されるUNIXユーザーまたはグループをそれぞれ設定します。引数として単一のユーザー名またはグループ名、または数値IDを取ります。システムサービス(システムサービスマネージャーによって実行されるサービス、つまりPID 1によって管理されるサービス)およびrootユーザーのユーザーサービス(systemd --userのrootのインスタンスによって管理されるサービス)の場合、デフォルトは「root」ですが、User =は別のユーザーを指定するために使用されます。他のユーザーのユーザーサービスの場合、ユーザーIDの切り替えは許可されないため、有効な設定は、ユーザーのサービスマネージャーを実行しているのと同じユーザーのみです。グループが設定されていない場合は、ユーザーのデフォルトグループが使用されます。この設定は、コマンドラインの先頭に「+」が付いているコマンドには影響しません。

https://www.freedesktop.org/software/systemd/man/systemd.exec.html#User=

また、スクリプトをホームディレクトリから標準パスなどに移動することをお勧めします/usr/local/bin

またconnectdocker.serviceAfter=docker.serviceとを指定して、自分の順序を確認する必要がありますRequires=docker.service。書かれてconnectdocker.serviceいるように、おそらくとほぼ同時に起動しようとしています。接続する前に、起動docker.serviceするまで待つ必要がありますdocker.service

必須=

他のユニットの要件依存関係を設定します。このユニットがアクティブになると、ここにリストされているユニットもアクティブになります。他のユニットの1つが非アクティブ化されるか、そのアクティブ化が失敗した場合、このユニットは非アクティブ化されます。このオプションは複数回指定することも、1つのオプションでスペースで区切られた複数のユニットを指定することもできます。この場合、リストされたすべての名前の要件依存関係が作成されます。要件の依存関係は、サービスが開始または停止される順序には影響しないことに注意してください。これは、After =またはBefore =オプションで個別に構成する必要があります。ユニットfoo.serviceが、Requires =で構成されたユニットbar.serviceを必要とし、After =またはBefore =で構成されていない場合、foo.serviceがアクティブ化されていれば、両方のユニットが同時に開始され、それらの間で遅延は発生しません。しばしば、

この依存関係のタイプは、このユニットが実行されているとき、他のユニットが常にアクティブ状態である必要があることを意味しないことに注意してください。具体的には、条件チェックの失敗(ConditionPathExists =、ConditionPathExists =、…—以下を参照)によって、Requires =依存関係を持つユニットの開始ジョブが失敗することはありません。また、一部のユニットタイプはそれ自体で非アクティブ化される場合があります(たとえば、サービスプロセスが正常に終了することを決定したり、デバイスがユーザーによって取り外されたりする可能性があります)。これは、Requires =依存関係を持つユニットには反映されません。BindsTo =依存関係タイプをAfter =と一緒に使用して、特定の他のユニットもアクティブ状態にない限り、ユニットがアクティブ状態にならないようにします(以下を参照)。

このタイプの依存関係は、ユニット構成ファイルの外にある.requires /ディレクトリにシンボリックリンクを追加することにより、構成ファイルの外部でも構成できることに注意してください。詳細については、上記を参照してください。

https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Requires=

https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Before=

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.