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

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。

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.