☰

在容器中运行时如何使用udev规则来管理/dev/xxx

tag-icon • tag-icon systemd udev docker
在容器中运行时如何使用udev规则来管理/dev/xxx

首先我想说，我并不是真的想修改/dev/random在产品中的访问权限，这只是一个测试来验证systemd何时在moby中运行，udev的规则在/etc/udev/rules.d/xxxx中的行为

问题1：为什么只有使用--priviledged容器时，/etc/udev/rules.d/xxx中容器的udev管理规则才有效？

如果systemd需要通过/etc/udev/rules.d/xxx使用udev来管理/dev/xxx，systemd需要什么权限？

问题2：当我使用--privilegedged启动容器时，为什么容器重新启动会修改phycalhost的/dev/xxx访问权限并使用physicalhost的/etc/udev/rules.d/xxx规则？我认为这是不合理的

使用过的分布

红帽7.2

如果出现错误报告：重现问题的步骤

启动一个没有 --privilegedged 的​​容器A

[root@physicalhost /home/ahao.mah]
#docker run -d --net host reg.docker.xxxxx.com/mybase/centos7u2:latest
36cc8f6759294b2b2900b313c4f978737b11671b7ab2cc185e69fba3f6a9d10c

[root@containerA /home/ahao.mah]
#docker exec -it 36cc8f6759294b2b2900b313c4f978737b11671b7ab2cc185e69fba3f6a9d10c bash

修改containerA中的udev规则：

[root@containerA /]
#cat  /etc/udev/rules.d/70-test_random.rules
KERNEL=="random",  GROUP="root", MODE="0665", OPTIONS="last_rule"

重启这个容器A：

[root@physicalhost /home/ahao.mah]
#docker restart 36cc8f675929
36cc8f675929

containerA 的 /dev/random 仍然是 0666，但不是 0665

[root@containerA /]
#ll /dev/random
crw-rw-rw- 1 root root 1, 8 Aug  8 11:34 /dev/random

目前我不知道为什么 /etc/udev/rules.d/xxx 规则在没有 --privileges 的容器中无效？

使用--privilege启动一个containerB

[root@physicalhost /home/ahao.mah]
#docker run -d --net host --privileged reg.docker.xxxxx.com/mybase/centos7u2:latest

[root@containerB /home/ahao.mah]
#docker exec -it 1853437e8d2ea7018475b2328a10f1625da8b0c667941d69d912598325dc830d bash

现在containerB的/dev/random默认访问权限也是0666，但是我想修改containerB的/dev/random访问权限为0660，那么我需要在/etc/udev/rules.d/xxx中使用udev规则

[root@containerB /]
#ll /dev/random
crw-rw-rw- 1 root root 1, 8 Aug  8 11:40 /dev/random

[root@containerB /]
#vim /etc/udev/rules.d/70-test_random.rules
KERNEL=="random",  GROUP="root", MODE="0660", OPTIONS="last_rule"

现在physicalhost的/dev/random默认访问权限也是0666，但我将physical的/dev/random访问权限修改为0777

[root@physicalhost /]
#cat /etc/udev/rules.d/70-test_random.rules
#KERNEL=="random",  GROUP="root", MODE="0777", OPTIONS="last_rule"

[root@physicalhost /]
#ll /dev/random
#crw-rw-rw- 1 root root 1, 8 Aug  8 11:40 /dev/random

重启容器B：

[root@physicalhost /home/ahao.mah]
#docker restart 1853437e8d2e
1853437e8d2e

容器B的/dev/random和物理主机的/dev/access都改变了！

[root@containerB /]
#ll /dev/random
crw-rw---- 1 root root 1, 8 Aug  8 11:41 /dev/random

[root@physicalhost /home/ahao.mah]
#ll /dev/random
crwxrwxrwx 1 root root 1, 8 Aug  8 11:43 /dev/random

我的看法：

  1. 我认为这与在 docker priv 中运行的 systemd 有关
  2. 当使用 --privileges 运行时，在 docker 中运行的 systemd 不应通过 /etc/udev/rules.d/xxx 修改物理主机的 /dev/xxx 访问权限
  3. 当没有 --privileges 运行时，在 docker 中运行的 systemd 应该可以通过 /etc/udev/rules.d/xxx 修改容器的 /dev/xxx 访问权限

答案1

我得到了我的解决方案，当通过--privileged创建一个containerA时，该containerA具有/sys rw访问权限，并且服务systemd-udev-trigger.serivce可以成功执行。这意味着 udevadm 可以触发 uevent 到 /sys/devices///uevent和物理主机也可以获取这个uevent，然后物理使用它的/etc/udev/rules.d/xxx

udevadm 触发器的目的是告诉内核为所有存在的设备发送事件。它通过写入 /sys/devices/ 来实现这一点//uevent。这需要将sysfs以读写方式挂载在/sys上。

相关内容