1

Firstly I want say , I am not really want to modify /dev/random 's access in product , This is just a test to verify when systemd running in moby , udev 's rules in /etc/udev/rules.d/xxxx 's behavior

Question1: why only when use --priviledged container, container's udev management rules in /etc/udev/rules.d/xxx is valid ?

what authority systemd need if systemd need to use udev to manage /dev/xxx by /etc/udev/rules.d/xxx ?

Question2: when I start a container use --priviledged, why container restart will modify phycalhost's /dev/xxx access and use physicalhost's /etc/udev/rules.d/xxx rules? I think this is not reasonable

Used distribution

redhat 7.2

In case of bug report: Steps to reproduce the problem

start a containerA with no --priviledged

[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

modify udev rules in containerA :

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

restart this containerA:

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

containerA's /dev/random still 0666 ,but not 0665

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

At this moment I do not know why /etc/udev/rules.d/xxx rules is invalid in a no --priviledges container?

start a containerB with --priviledge

[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

Now containerB's /dev/random default access is also 0666,but I want to modify containerB's /dev/random access to 0660, then I need to use udev rules in /etc/udev/rules.d/xxx

[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"

Now physicalhost's /dev/random default access is also 0666,but I modify physical's /dev/random access to 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

restart containerB:

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

both containerB's /dev/random and physicalhost's /dev/access is changed!

[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

My views:

  1. I think this relate to systemd running in docker priv
  2. when running with --priviledges , systemd running in docker should not modify physicalhost's /dev/xxx access by /etc/udev/rules.d/xxx
  3. when running with no --priviledges , systemd running in docker should can modify container's /dev/xxx access by /etc/udev/rules.d/xxx

1 Answer 1

1

I got my solution ,when a containerA created by --privileged , this containerA have /sys rw access , and service systemd-udev-trigger.serivce can be excuted success. this means udevadm can trigger uevent to /sys/devices///uevent and physical host also can get this uevent, then physical use it's /etc/udev/rules.d/xxx

the point of udevadm trigger is to tell the kernel to send events for all the devices that are present. It does that by writing to /sys/devices///uevent. This requires sysfs to be mounted read-write on /sys。

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .