Há alguma ressalva em usar o chroot?

Question

Eu uso Arch Linux como meu sistema operacional principal e trabalho em um aplicativo da Web criado para Centos . Inicialmente eu estava usando LXC Container no meu Arch para rodar um Centos , porém devido a problemas de configuração de rede em Wifi etc resolvi achar uma alternativa e alguém sugeriu que chroot ing diretamente funcionasse em seu lugar.

Atualmente, uso apenas os comandos LXC para criar um Centos e apenas chroot para ele e para o trabalho. Eu também montei o /bind , /proc e /sys no meu ambiente chroot ed. Meu aplicativo da Web funciona bem sem problemas.

Existe alguma preocupação / advertência nessa abordagem? Eu ainda não tentei coisas avançadas como Java JVM ainda. Eu sei que ele usa o Kernel do sistema host, e eu acho que System Calls é compatível com versões anteriores no Linux (é por isso que essa idéia funciona), então tudo deve funcionar tão perfeitamente quanto você esperaria.

Ainda assim, gostaria de saber se há cenários em que você poderia ter problemas ao usar chroot ? Como existem cenários onde chroot pode não funcionar como um sistema normal? Logicamente, não consigo ver nada desde que o Kernel seja compatível com versões anteriores. O único lugar em que consigo pensar é quando o Kernel do sistema Host tem uma implementação diferente em relação ao Kernel original e se há erros naquilo que geralmente é improvável.

Enquanto uso Arch , gostaria de ter uma perspectiva geral. Minha idéia principal é recomendar isso para meus colegas que não usam Centos como seu sistema operacional primário devido a várias razões. Há também casos de uso em que você precisa de uma máquina de 32 bits em um de 64 bits. Muitos deles gastaram muito tempo configurando VM's etc, mas isso é realmente necessário para um Linux em uma "virtualização" do Linux? Eu pessoalmente sinto chroot é incrível e não apenas uma ferramenta de depuração, no entanto, eu queria obter alguma opinião de especialistas.

    

Answer 1

chroot não é um contêiner e não isola completamente um processo do restante do sistema. Se você montar /proc em seu diretório chroot, um processo iniciado naquele chroot poderá ver os processos sendo executados fora do seu chroot.

Dito isso, se você não se importar, chroot é projetado para lidar exatamente com os casos que você está descrevendo. De fato, antes do suporte multiarch no Debian, a maneira recomendada de executar aplicativos de 32 bits em um sistema de 64 bits era fazer um chroot de 32 bits e instalar uma base Debian mínima de 32 bits.

    

Answer 2

O Chroot não é um contêiner, apenas altera a visão do sistema de arquivos. Rede ainda é a mesma, os dispositivos ainda são os mesmos, pids ainda são os mesmos, uids ainda são os mesmos, o root ainda é raiz.

Isso significa que ações tomadas em um chroot podem afetar o sistema mais amplo. Se você iniciar um daemon no chroot e ele for ligado a uma porta, ele ocupará essa porta em todo o sistema, não apenas no chroot. Se você (ou um script) usar o killlall em um chroot, ele matará processos fora do chroot também.

Em particular, a instalação / atualização de pacotes em um chroot pode levar a daemons iniciados inadvertidamente e / ou a processos de instalação falharem devido à incapacidade de iniciar daemons. Um script mal escrito pode até matar um daemon no sistema host antes de iniciar uma versão no chroot causando muita confusão (tenho certeza que tive pelo menos um caso há muitos anos atrás, onde emails enviados para 127.0.0.1:25 pareciam ir a lugar nenhum e eu finalmente descobri que eles estavam sendo manipulados por um MTA em um chroot que estava configurado para "somente correio local").

Algumas distros possuem mecanismos para parar as instalações de pacotes nos daemons de inicialização do chroot, mas os detalhes obviamente serão específicos da distribuição.