먼저 프로덕션 환경에서 /dev/random의 액세스 권한을 수정하고 싶지 않다는 점을 말씀드리고 싶습니다. 이것은 단지 systemd가 moby에서 실행 중인지 확인하기 위한 테스트일 뿐이며 udev에 대한 규칙은 /etc/udev/에 있습니다. rule.d/ xxxx의 동작
질문 1: /etc/udev/rules.d/xxx의 컨테이너에 대한 udev 관리 규칙이 --privileged 컨테이너가 사용될 때만 유효한 이유는 무엇입니까?
systemd가 udev를 사용하여 /etc/udev/rules.d/xxx를 통해 /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
컨테이너A에서 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
현재 --privileges가 없는 컨테이너에서 /etc/udev/rules.d/xxx 규칙이 유효하지 않은 이유를 모르겠습니다.
--privilege를 사용하여 컨테이너B 시작
[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
내 관점 에선:
- 나는 이것이 docker priv에서 실행되는 systemd와 관련이 있다고 생각합니다.
- --privileges로 실행할 때 docker에서 실행 중인 systemd는 /etc/udev/rules.d/xxx를 통해 물리적 호스트의 /dev/xxx 액세스 권한을 수정해서는 안 됩니다.
- --privileges 없이 실행하는 경우 docker에서 실행되는 systemd는 /etc/udev/rules.d/xxx를 통해 컨테이너의 /dev/xxx 액세스 권한을 수정할 수 있어야 합니다.
답변1
--privileged를 통해 컨테이너A를 생성할 때 컨테이너A에 /sys rw 액세스 권한이 있고 systemd-udev-trigger.serivce 서비스가 성공적으로 실행될 수 있다는 솔루션을 얻었습니다. 이는 udevadm이 uevent를 /sys/devices/로 트리거할 수 있음을 의미합니다.//uevent 및 물리적 호스트도 이 uevent를 얻은 다음 /etc/udev/rules.d/xxx를 물리적으로 사용할 수 있습니다.
udevadm 트리거의 목적은 커널에 모든 기존 장치에 대한 이벤트를 보내도록 지시하는 것입니다. /sys/devices/에 기록하여 이를 수행합니다.//uevent. 이를 위해서는 읽기-쓰기 모드로 /sys에 sysfs를 마운트해야 합니다.