Diretório Raiz GLPI: O Que Significa o Aviso “Não é Seguro”

Se apareceu no seu sistema o aviso sobre o diretório raiz GLPI, é normal sentir um friozinho na barriga — mas antes de qualquer decisão, vale entender exatamente o que essa mensagem significa e se você está realmente exposto.

Resumo em linguagem simples: se você é dono da empresa e só quer saber se precisa se preocupar agora: na maioria dos casos, não é uma emergência. É um aviso preventivo do próprio sistema, e o risco real depende de como o servidor está configurado — dá pra confirmar isso em poucos minutos, sem desligar nada. Se você é o responsável técnico, siga a leitura: aqui está o passo a passo completo para testar e corrigir com segurança.

O que o aviso de diretório raiz GLPI quer dizer

A partir da versão 10.0.7, o GLPI passou a recomendar que o diretório raiz do servidor web (o famoso DocumentRoot) aponte para a pasta public/ dentro da instalação, e não para a raiz completa do sistema. Quando isso não está configurado dessa forma, o painel central exibe o aviso: “A configuração do diretório raiz do servidor da Web não é segura, pois permite acesso a arquivos não públicos.”

É comum ver essa mensagem logo após uma atualização de versão, mesmo em instalações que já estavam funcionando perfeitamente há anos — porque a checagem é nova, não porque o servidor mudou de repente.

Por que o GLPI passa a exigir isso

A pasta public/ existe para isolar, do alcance direto de qualquer URL, as pastas que deveriam ficar privadas: config/ (credenciais de banco de dados), files/ (anexos de chamados e backups) e vendor/ (bibliotecas internas do sistema).

Hoje essa configuração ainda é uma recomendação opcional nas versões 10.x, mas deixará de ser opcional na próxima versão principal, o GLPI 11 — ou seja, quem adia essa migração vai precisar fazê-la de qualquer forma mais cedo ou mais tarde.

O desafio aparece principalmente em hospedagem compartilhada (Hostinger, KingHost e similares), onde você não controla diretamente o arquivo de configuração do Apache ou Nginx — mudar o DocumentRoot exige um caminho diferente do que em um servidor próprio.

O erro que quase todo tutorial comete: tratar como “tudo ou nada”

A maioria dos guias que você encontra por aí pula direto para “reconfigure o DocumentRoot” — sem nunca responder à pergunta que realmente importa: você está exposto agora, hoje, com a configuração atual?

O que a maioria não menciona é que o GLPI distribui, desde muito antes dessa recomendação existir, um arquivo .htaccess com bloqueio total dentro das pastas files/ e config/. Essa regra legada bloqueia qualquer requisição a esses caminhos, independentemente de onde o DocumentRoot esteja apontando — e continua funcionando hoje na maioria das instalações via Apache ou LiteSpeed.

Ou seja: o aviso trata qualquer instalação fora do padrão novo como insegura, mesmo quando essa proteção legada ainda está de pé. A pergunta certa não é “como faço o aviso sumir”, é “estou realmente exposto”.

Como testar se você está exposto agora (antes de mexer em qualquer coisa)

O teste é rápido e não exige nenhuma alteração no servidor. Basta requisitar qualquer caminho inexistente dentro de files/ e config/ e observar o código de resposta HTTP:

• curl -I https://seudominio.com/files/teste123
• curl -I https://seudominio.com/config/teste123

Interprete o resultado assim:

• 403 Forbidden — a proteção legada está ativa. O risco real hoje é baixo, mesmo com o DocumentRoot na configuração antiga.
• 404 Not Found — não há bloqueio por diretório. Se alguém souber ou descobrir o nome exato de um arquivo real (um backup, por exemplo), o servidor vai entregá-lo. Isso muda a prioridade de “hardening futuro” para “corrigir agora”.

Se deu 403 (protegido): o que fazer

Pode tratar a migração completa para public/ como um projeto de hardening sem urgência — vale planejar, já que será obrigatória na próxima versão principal, mas não precisa ser feita sob pressão.

Se o aviso incomodar visualmente enquanto isso, existe uma forma conhecida na comunidade de suprimir apenas a exibição, editando o arquivo src/System/Requirement/SafeDocumentRoot.php. Via SSH:

• cd caminho/da/instalacao/src/System/Requirement/
• cp SafeDocumentRoot.php SafeDocumentRoot.php.bkp-$(date +%Y%m%d) — backup antes de qualquer edição
• grep -n "function check" SafeDocumentRoot.php — retorna o número da linha do método
• sed -n '54,65p' SafeDocumentRoot.php — confira o contexto ao redor da linha antes de editar às cegas
• sed -i 'NUMERO_DA_LINHA_DA_CHAVEa\ return;' SafeDocumentRoot.php — insere o return; logo após a chave de abertura { do método (substitua NUMERO_DA_LINHA_DA_CHAVE pelo número real, uma linha depois do function check() encontrado no grep)
• php -l SafeDocumentRoot.php — valida a sintaxe antes de confiar na edição; precisa retornar exatamente “No syntax errors detected”

Antes de fazer isso, veja os pontos de atenção:

• Sempre faça backup do arquivo original antes de editar.
• Valide a sintaxe com php -l SafeDocumentRoot.php antes de confiar na edição.
• Essa alteração será sobrescrita na próxima atualização do núcleo do GLPI — reaplicar (ou reavaliar) depois de cada upgrade.
• Isso não corrige a condição real, só a visibilidade — documente a alteração para quem for mexer no sistema depois de você.

Se deu 404 (não protegido): trate como prioridade

Antes até de pensar na migração completa, recrie uma proteção de bloqueio total dentro das pastas files/ e config/. Um .htaccess simples dentro de cada uma delas já resolve. Via SSH, dentro da pasta raiz da instalação:

cat > files/.htaccess << 'EOF'
<IfModule mod_authz_core.c>
Require all denied
</IfModule>
<IfModule !mod_authz_core.c>
Deny from all
</IfModule>
EOF
cp files/.htaccess config/.htaccess

Depois de criar, confirme que funcionou repetindo o teste com curl -I do passo anterior — a resposta deve virar 403 nas duas pastas.

Isso é uma correção de minutos, não exige mexer no DocumentRoot, e já neutraliza o risco real enquanto a migração completa para public/ é planejada com calma.

Migrando de vez para a pasta public

A migração definitiva envolve apontar o DocumentRoot do Apache ou Nginx para a subpasta public/ da instalação, habilitar o módulo de rewrite e ajustar as regras de reescrita de URL. Exemplo de configuração de VirtualHost para Apache:

<VirtualHost *:443>
ServerName seu-dominio.com.br
DocumentRoot /caminho/para/glpi/public

<Directory /caminho/para/glpi/public>
AllowOverride All
Require all granted
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ index.php [QSA,L]
</Directory>
</VirtualHost>

Depois de salvar a configuração, habilite o módulo de rewrite e reinicie o Apache:

a2enmod rewrite
systemctl restart apache2

Em hospedagem compartilhada, esse apontamento geralmente não fica acessível diretamente pelo cliente — abra um chamado com o suporte do provedor pedindo para o DocumentRoot do domínio apontar para a subpasta public/ da instalação. A documentação oficial de instalação do GLPI traz exemplos equivalentes para Nginx e IIS.

Perguntas frequentes

Esse aviso bloqueia o funcionamento do GLPI?

Não. É um alerta informativo de segurança, não um erro de sistema. O GLPI continua funcionando normalmente — login, chamados, inventário e relatórios seguem operando mesmo com o aviso visível no painel central.

Editar o arquivo do núcleo pra esconder o aviso é seguro?

Tecnicamente sim, desde que você valide a sintaxe antes e mantenha backup do original — a edição não toca banco de dados nem arquivos de cliente. Mas não resolve a causa real, e será desfeita a cada atualização do GLPI. Trate como paliativo, não como solução definitiva.

Preciso migrar pra pasta public mesmo estando protegido pelo .htaccess?

Não com urgência, mas vale planejar. A configuração via .htaccess é uma proteção legada que funciona hoje, mas o GLPI 11 vai exigir a estrutura correta com pasta public — melhor migrar num momento tranquilo do que ser forçado a fazer isso no meio de uma atualização futura.

Conclusão

Antes de seguir qualquer tutorial que manda reconfigurar o servidor por causa do aviso de diretório raiz GLPI, teste se você está realmente exposto. Na maioria das instalações antigas, a proteção legada ainda está de pé — e saber disso muda completamente a urgência da correção.

Se você administra GLPI e não tem certeza se está exposto, ou quer ajuda pra planejar a migração pra pasta public sem parar a operação, fale com a gente no WhatsApp.