Por que a remontagem de / proc / sys não é global ou não persiste no namespace da rede dentro do LXC

Question

Eu tenho o host executando o RHEL-7.2. Dentro disso, rodando o LXC. Dentro do LXC, criando namespaces de rede. Dentro do namespace, a alteração de sysctl variáveis estava falhando (como root):

$ ip netns add testns
$ ip netns exec testns bash
$ sysctl net.ipv6.conf.all.disable_ipv6=1
sysctl: setting key "net.ipv6.conf.all.disable_ipv6": Read-only file system

Se eu remontar /proc/sys para RW em um shell e, em seguida, sysctl -w dentro do mesmo shell, funcionará.

$ ip netns exec testns bash
$ mount -o remount,rw /proc/sys
$ sysctl net.ipv6.conf.all.disable_ipv6=1
net.ipv6.conf.all.disable_ipv6 = 1

Em seguida, inicio o segundo shell e insiro netns, e /proc/sys aparece como somente leitura para esse shell, mas permanece gravável no shell de 1sh. Isso me intriga. O efeito de alterar valores pelo primeiro shell é visível para o segundo shell.

Eu estava tentando adicionar remontar ao script de provisionamento, mas essa questão atrapalha.

$ ip netns exec testns sysctl net.ipv6.conf.all.disable_ipv6=1
sysctl: setting key "net.ipv6.conf.all.disable_ipv6": Read-only file system

$ ip netns exec testns sh -c \
>   'mount -o remount,rw /proc/sys && sysctl net.ipv6.conf.all.disable_ipv6=1'
net.ipv6.conf.all.disable_ipv6 = 1

$ ip netns exec testns sysctl net.ipv6.conf.all.disable_ipv6=0
sysctl: setting key "net.ipv6.conf.all.disable_ipv6": Read-only file system

Observe que posso fazer isso sysctl change no host e no namespace padrão do LXC sem problemas. Se eu criar um namespace no host diretamente, não tenho esse problema. Eu só corro em /proc/sys sendo somente leitura dentro do namespace dentro do LXC.

Minhas perguntas aqui são:

Q1 . Eu gostaria que /proc/sys dentro do namespace dentro do LXC permanecesse permanentemente montado com o RW para que eu pudesse definir sysctl vars a qualquer momento.

Q2 . Eu gostaria de entender porque isso se comporta. Parece que /proc/sys mount é de alguma forma por processo ou por setns de chamada do sistema? man ip-netns fala sobre a montagem de ligação para /etc/netns/<name>/file , mas não vejo nada sobre /proc . Eu senti falta de algo óbvio?

Atualizar

Encontrei o que provavelmente será a resposta para o meu Q2 . Primeiro experimentalmente e depois em man ip-netns :

ip netns exec automates handling of this configuration, file convention for network namespace unaware applications, by creating a mount namespace and bind mounting all of the per network namespace configure files into their traditional location in /etc.

Portanto, sempre que ip netns exec criar um novo namespace de montagem, o /proc/sys será a vítima de todas as opções de montagem de onde ele foi tirado. Meu melhor palpite é que preciso encontrar o que faz com que ip netns exec monte a ligação /proc/sys no modo somente leitura em LXC, o que provavelmente responderá à minha pergunta Q1.

    

Answer 1

Eu encontrei algo que funciona para mim. Essa solução pode ser uma má idéia para aqueles que se preocupam com segurança, como evitar que o contêiner interfira no host. Eu realmente não entendo as conseqüências completas da minha solução. Eu corro apenas meu próprio código dentro de LXCs com testes de Jenkins, então para mim não é um problema.

Encontrei aqui: link :

The following special mounts are setup by libvirt

/proc/sys the host "/proc/sys" bind-mounted read-only

Eu ainda não entendi porque dentro do namespace de rede padrão dentro do LXC eu posso definir sysctl , mas dentro de outros namespaces de rede eu não posso.

Eu adicionei o /proc/sys mount explícito no XML de configuração do container:

<devices>
...
  <filesystem type='mount' accessmode='passthrough'>
    <source dir='/proc/sys/'/>
    <target dir='/proc/sys/'/>
  </filesystem>

Isso permitiu definir sysctl dentro do namespace do contêiner LXC e namespaces adicionais. Eu temia que a configuração dentro do LXC também afetasse o host, mas isso não acontece. Agora, todos os namespaces de rede (host, LXC padrão, LXC personalizado) têm suas variáveis sysctl graváveis independentes (por raiz) sem ter que remontar todas as vezes. Ou pelo menos o que sysctl consulta relatórios.