O chroot (abreviação de change root) é uma chamada de sistema Unix criada em 1979 no Unix Version 7, posteriormente popularizada por Bill Joy durante o desenvolvimento do BSD. Essa funcionalidade altera o diretório raiz aparente de um processo e seus filhos, criando um ambiente isolado conhecido como chroot jail. Por mais de quatro décadas, o chroot foi usado como ferramenta de sandboxing, recovery de sistemas e isolamento de serviços — mas sua reputação como mecanismo de segurança é, na verdade, um mal-entendido histórico. Segundo o Linux man-pages chroot(2) (2024), o chroot foi projetado para alterar a visão do sistema de arquivos, não para fornecer segurança contra processos maliciosos com privilégios elevados.
TL;DR
- chroot é uma syscall Unix que redefine o diretório raiz de um processo, criando um ambiente contido conhecido como chroot jail.
- Útil para recovery de Linux, SFTP jail, build environments e sandboxing simples — mas não oferece isolamento de PID, rede ou mount namespaces.
- Para segurança real em produção, use containers (Docker, Podman) ou namespaces Linux modernos.
Como funciona o chroot?
chroot é uma syscall que redefine o diretório ‘/’ para um processo e todos os seus descendentes.
Após a chamada, o processo passa a enxergar o diretório designado como se fosse a raiz do sistema de arquivos. Comandos como ls / mostrarão apenas o conteúdo do jail. Essa alteração afeta apenas o processo filho — o sistema host continua intocado. A sintaxe básica é chroot [novo-root] [comando], e a execução requer privilégios de root (capability CAP_SYS_CHROOT concedida por padrão apenas ao superusuário).
Casos de uso do chroot
chroot é usado em recovery, SFTP jail, build environments e sandboxing simples.
Os cenários mais comuns incluem:
- Jail/sandbox simples: isolar processos legados ou aplicações com dependências antigas sem contaminar o sistema host.
- Recovery de Linux: administradores usam chroot via live USB para reinstalar bootloaders, resetar senhas e corrigir sistemas que não bootam.
- Build environments: compilar pacotes em ambientes limpos e reprodutíveis (debootstrap, pbuilder, sbuild).
- SFTP jail: OpenSSH ChrootDirectory restringe usuários SFTP a diretórios específicos.
- Testes com diferentes bibliotecas: rodar binários em ambientes com versões específicas de glibc ou outras libs.
chroot NÃO é segurança (chroot jail escape)
chroot não foi projetado como mecanismo de segurança e processos root podem escapar trivialmente.
Processos com privilégios de root dentro de um chroot podem escapar usando técnicas conhecidas há décadas. A mais clássica envolve fork + reopen de descritores de arquivo apontando para fora do jail. Segundo a NSA no relatório Linux Security Guide (2020), o chroot não isola namespaces de PID, rede, mount ou IPC, e nunca deve ser considerado como barreira contra atacantes com acesso root. Por isso, projetos modernos como Docker (lançado em 2013), Podman e LXC combinam chroot com namespaces Linux e cgroups para fornecer isolamento real. Segundo a Docker Inc (2023), mais de 90% dos deployments em produção em empresas que adotaram contêineres usam Docker ou tecnologias OCI-compatíveis em vez de chroot bare.
chroot vs containers (Docker, Podman)
Containers oferecem isolamento muito mais abrangente que o chroot sozinho.
| Recurso | chroot | Containers |
|---|---|---|
| Isolamento de filesystem | Sim | Sim (chroot + mount namespace) |
| Isolamento de PID | Não | Sim |
| Isolamento de rede | Não | Sim |
| Isolamento de mount | Não | Sim |
| Isolamento de usuário | Não | Sim (user namespace) |
| Limite de recursos | Não | Sim (cgroups) |
| Segurança real contra root | Não | Parcial (depende de config) |
| Portabilidade de imagens | Não | Sim (OCI) |
Exemplos práticos em servidores B2B
Três cenários onde o chroot ainda é relevante em infraestrutura B2B em 2026.
SFTP jail para clientes
Agências e provedores de hospedagem configuram ChrootDirectory no OpenSSH para que cada cliente SFTP acesse apenas seu diretório, sem enxergar o restante do servidor. É solução padrão em ambientes de hospedagem compartilhada.
Build CI/CD reprodutível
Pipelines Debian e Ubuntu usam pbuilder e sbuild (ambos baseados em chroot) para garantir que pacotes sejam compilados em ambientes idênticos, evitando bugs de ‘funciona na minha máquina’.
Recovery de Linux não bootável
Quando um servidor dedicado falha ao bootar após atualização de kernel ou corrupção do GRUB, o técnico boota via live USB, monta a partição root e usa chroot para reinstalar o bootloader ou corrigir o fstab.
Como fazer chroot — passo a passo
Criar um chroot funcional requer binários, bibliotecas e, em alguns casos, dispositivos corretos.
# Criar estrutura
mkdir -p /jail/{bin,lib,lib64}
# Copiar bash e dependências
cp /bin/bash /jail/bin/
ldd /bin/bash | awk '{print $3}' | xargs -I {} cp {} /jail/lib/
cp /lib64/ld-linux-x86-64.so.2 /jail/lib64/
# Entrar no jail
chroot /jail /bin/bashSem copiar as bibliotecas listadas pelo ldd, o bash dentro do jail falhará ao iniciar.
SFTP chroot com OpenSSH
OpenSSH fornece ChrootDirectory para isolar usuários SFTP.
Segundo a documentação oficial do OpenSSH (2024), a configuração requer que o diretório raiz do jail seja propriedade do root e não writable pelo usuário. Exemplo em /etc/ssh/sshd_config:
Match Group sftpusers
ChrootDirectory /home/%u
ForceCommand internal-sftp
AllowTcpForwarding no
X11Forwarding noPermissões incorretas (diretório writable pelo usuário) resultam em erro de conexão genérico — causa comum de SFTP jail quebrado.
chroot em recovery de Linux
O recovery via chroot é técnica padrão em administração Linux.
O procedimento envolve:
- Boot via live USB ou rescue mode do provedor.
- Montar a partição root:
mount /dev/sda2 /mnt - Fazer bind mount de /dev, /proc e /sys:
mount --bind /dev /mnt/dev(repetir para /proc e /sys). - Entrar no chroot:
chroot /mnt /bin/bash - Executar comandos como
grub-install,passwdou corrigir/etc/fstab.
Esse fluxo salva servidores dedicados em cenários onde o reinstall completo seria caro ou lento.
Alternativas modernas ao chroot
Diversas tecnologias modernas superam o chroot em funcionalidade e segurança.
- Linux namespaces (unshare): isolam PID, rede, mount, user, UTS e IPC separadamente, base técnica dos containers.
- systemd-nspawn: container leve integrado ao systemd, ideal para serviços sistema isolados.
- Firejail: sandbox focado em aplicações desktop.
- bubblewrap: usado por Flatpak para isolar aplicações gráficas.
- Docker, Podman, LXC: containers completos para produção, com imagens OCI portáveis.
Erros comuns com chroot
Cinco armadilhas frequentes que comprometem o uso correto do chroot.
- Confiar em chroot como segurança contra root: processos privilegiados escapam facilmente.
- Esquecer bind mounts de /dev, /proc e /sys: muitos programas falham sem esses pseudo-filesystems.
- Dependências faltando: binários precisam das bibliotecas listadas por ldd dentro do jail.
- SFTP jail quebrado por permissões: ChrootDirectory exige dono root e diretório não writable pelo usuário.
- Usar chroot quando o caso pede container: em produção, Docker ou Podman são as escolhas corretas.
Quando usar chroot vs containers
A escolha depende do nível de isolamento e complexidade requeridos.
Use chroot para tarefas simples, recovery de sistemas e SFTP jail. Para produção, isolamento real, multi-tenant ou qualquer workload que exija segurança contra escalada de privilégios, use containers. Segundo o Red Hat State of Enterprise Open Source Report (2024), 86% das empresas enterprise usam containers em produção, e menos de 10% dependem de chroot puro para isolamento de serviços críticos. A regra prática: chroot para ferramentas, containers para serviços.
chroot e a Shiftmind
A Shiftmind aplica chroot e containers em projetos de infraestrutura há mais de 12 anos. Nossos serviços de Servidor Dedicado incluem configuração de SFTP jail, builds reprodutíveis e recovery emergencial com chroot. Em Hospedagem WordPress gerenciada, isolamos sites de clientes com containers e chroot para máxima segurança operacional.
Nosso Suporte e Manutenção WordPress inclui auditoria de permissões e configurações de jail. Em Segurança de Websites, aplicamos sandboxes para análise de arquivos suspeitos, e em Criação de Sites, usamos pipelines CI/CD isolados para builds confiáveis.
Perguntas frequentes sobre chroot
chroot é a mesma coisa que container?
Não. chroot altera apenas a visão do sistema de arquivos para um processo, enquanto containers combinam chroot com namespaces Linux (PID, rede, mount, user, UTS, IPC) e cgroups para isolamento completo. Containers oferecem isolamento real contra escapes; chroot sozinho não.
Posso escapar de um chroot jail?
Sim, se tiver privilégios de root dentro do jail. Técnicas como fork + reopen de file descriptors permitem escape trivial, documentado desde os anos 1990. Por isso, chroot nunca deve ser considerado barreira de segurança contra atacantes com acesso root ao processo preso.
chroot funciona em Windows?
Não nativamente. chroot é uma syscall Unix/Linux. No Windows, equivalentes incluem AppContainers, Windows Sandbox e isolamento Hyper-V. Em WSL2 (Linux no Windows), o chroot funciona normalmente dentro da VM Linux subjacente.
Qual a diferença entre chroot e unshare?
chroot altera apenas o diretório raiz. unshare cria novos namespaces Linux (PID, rede, mount, user, UTS, IPC) isolando o processo em múltiplas dimensões. unshare é mais poderoso e é a base técnica dos containers modernos como Docker e Podman.
chroot é obsoleto?
Não. Continua útil para recovery, SFTP jail, builds reprodutíveis e sandboxes simples. Para produção e isolamento de segurança, foi superado por containers. Debian, Ubuntu e Red Hat ainda usam chroot em suas ferramentas oficiais de build de pacotes.
Preciso ser root para usar chroot?
Sim, a syscall chroot(2) requer a capability CAP_SYS_CHROOT, concedida por padrão apenas ao root. Em ambientes com user namespaces (unprivileged containers), usuários não-root podem usar chroot dentro do próprio namespace isolado.
Termos relacionados
Conclusão
O chroot é uma ferramenta clássica do Unix que continua relevante para recovery, SFTP jail e builds reprodutíveis, mas não substitui containers em cenários que exigem isolamento real. Entender suas limitações é essencial para arquitetar infraestrutura segura e evitar falsas sensações de segurança. Em 2026, o chroot é parte da caixa de ferramentas de qualquer sysadmin Linux, mas o isolamento de produção pertence aos containers e namespaces modernos.
Última atualização: Outubro/2026.
