Como usar as regras do udev para o gerenciamento / dev / xxx ao executar no container

Question

Primeiramente eu quero dizer, eu não estou realmente quer modificar o acesso do / dev / random no produto, este é apenas um teste para verificar quando o systemd está rodando em moby, as regras do udev em / etc / udev / rules. o comportamento de d / xxxx

Question1: por que somente quando usar o container --priviledged, as regras de gerenciamento do udev do container em /etc/udev/rules.d/xxx são válidas?

qual a autoridade que o sistema precisa se o sistema precisar usar o udev para gerenciar / dev / xxx por /etc/udev/rules.d/xxx?

Question2: quando eu inicio um container use --priviledged, por que reiniciar o container irá modificar o acesso / dev / xxx do phycalhost e usar as regras do /etc/udev/rules.d/xxx do physicalhost? Acho que isso não é razoável

Distribuição usada

redhat 7.2

Em caso de relatório de bug: passos para reproduzir o problema

inicie um container A sem --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

modifique as regras do udev no container A:

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

reinicie este containerA:

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

containerA's / dev / random ainda 0666, mas não 0665

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

Neste momento, eu não sei porque as regras do /etc/udev/rules.d/xxx são inválidas em um container no -priviledges?

inicie um containerB com --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

Agora o acesso padrão / dev / random do containerB também é 0666, mas eu quero modificar o acesso / dev / random do containerB para 0660, então eu preciso usar as regras do udev em /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"

Agora o acesso padrão / dev / random do físico também é 0666, mas modifico o acesso / dev / random de physical para 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

reinicie o contêinerB:

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

o acesso / dev / do containerB's / dev / random e do physicalhost foi alterado!

[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

Minhas visões:

1. Acho que isso está relacionado ao systemd sendo executado no docker priv
2. ao executar com --priviledges, o systemd em execução no docker não deve modificar o acesso / dev / xxx do físico por /etc/udev/rules.d/xxx
3. ao executar com nenhum --priviledges, o systemd em execução no docker deve poder modificar o acesso do / dev / xxx do contêiner por /etc/udev/rules.d/xxx

Answer 1

Eu obtive minha solução, quando um container Um criado por --privileged, este containerA tem acesso / sys rw, e o service systemd-udev-trigger.serivce pode ser obtido com sucesso. isto significa que o udevadm pode disparar uevent para / sys / devices / / / uevent e o host físico também pode obter este uevent, então o uso físico é /etc/udev/rules.d/xxx

o ponto do trigger do udevadm é dizer ao kernel para enviar eventos para todos os dispositivos que estão presentes. Isso é feito escrevendo para / sys / devices / / / uevent. Isto requer que o sysfs seja montado como read-write em / sys。