Ferramentas de desenvolvedor · Calculadora Chmod
Corrigindo nginx 403 Proibido: as permissões de arquivo e diretório que importam
· Por que é importante
chmod unix controle de acesso
Um 403 do nginx geralmente é um problema no sistema de arquivos, não um problema de configuração. Esta postagem mostra como verificar qual usuário o nginx é executado e quais bits ele precisa em cada diretório no caminho.
403 em um site estático que funcionava localmente — os arquivos vieram de /home/deploy e o nginx diz proibido para cada URL
Um nginx 403 pode envolver bits de modo, mas esta rota não pode identificar sua causa. A calculadora não possui integração nginx, logs, analisador de configuração, pesquisa de processo ou path walker. Ele responde a questões mais restritas: se uma classe de diretório foi executada e se uma classe de arquivo regular foi lida, ajudando a interpretar evidências coletadas em outros lugares.
Comece com os modos exatos observados em cada componente do caminho, em vez de assumir os padrões. Entre em cada modo e escolha seu tipo de alvo. Texto simbólico, caixas de seleção e prosa expõem permissões de classe e confirmam a conversão, mas não podem mostrar que o nginx tentou acessar, qual identidade ele usou ou se as permissões do sistema de arquivos produziram a resposta.
Um 403 pode envolver bits de modo, mas esta rota não pode identificar sua causa
A calculadora não consegue descobrir uma identidade de trabalhador nginx. Ele modela proprietário, grupo e outras classes, mas sem nomes de usuários, processos ou associações. Um modo como rwxr-xr-x, portanto, não diz nada sobre se um trabalhador possui o objeto, pertence ao seu grupo ou se enquadra em outro. A inspeção externa deve estabelecer essa classificação.
A descoberta de identidade deve preceder as declarações sobre bits relevantes. Uma vez que a evidência estabeleça a classe aplicável, a matriz mostra lida como 4, escrita como 2 e executada como 1. Antes disso, editar grupo ou outro é uma adivinhação. A rota não lê nenhum estado do processo; ele traduz os modos fornecidos em vez de inferir a arquitetura do servidor.
A calculadora não descobre uma identidade de trabalhador nginx
Inspecione cada componente do diretório como um modo fornecido separadamente. Para diretórios, execute permite entrada e acesso baseado em nome, read permite listagem e write permite criar, renomear e excluir entradas. A explicação específica do alvo ajuda os revisores a determinar se a classe estabelecida externamente foi executada em um componente específico sem reivindicar a inspeção do caminho em si.
O navegador não anda de raiz para raiz da web. Ele não consegue localizar um componente de bloqueio, confirmar a existência ou inspecionar ACLs. Forneça cada modo de diretório observado separadamente e, em seguida, verifique o objeto final como um arquivo normal, onde a leitura diz respeito ao conteúdo e não às listagens. Isso interpreta as evidências coletadas em vez de substituir a inspeção do sistema de arquivos.
Os arquivos precisam de r e nada mais - por que 644 é suficiente para arquivos estáticos e por que 755 em arquivos não é a solução
Para um arquivo estático, 644 renderiza rw-r--r--. O proprietário recebe leitura e gravação, enquanto o grupo e outros recebem leitura; ninguém recebe execução. Esta conversão mostra que a leitura e a execução do arquivo são bits separados. A página não tem base para decidir se um determinado servidor precisa ser executado, porque a política do servidor está ausente.
Mantenha as explicações de arquivos e diretórios distintas. A execução de diretório significa acessibilidade baseada em entrada e nome, enquanto a execução de arquivo regular significa executar um programa. A mesma caixa de seleção, portanto, possui prosa específica para o alvo. Comparar 644 com 755 esclarece os bits, mas não pode diagnosticar um 403 ou prescrever um modo universal sem configuração, identidade, ACL e contexto de política.
Exemplo resolvido: rastreamento /home/deploy/site/index.html — namei -l no caminho e a linha ls -l que revela o bloqueador
Um exemplo apoiado começa depois que as evidências do caminho são coletadas em outro lugar. Suponha que os componentes do diretório sejam 755 e o arquivo final seja 644. A calculadora renderiza diretórios como rwxr-xr-x, explicando grupo e outras execuções como entrada e acessibilidade. Ele renderiza o arquivo como rw-r--r--, explicando grupo e outros acessos de leitura como conteúdo.
Se um componente for 750, seu outro triplo será ---, enquanto o grupo permanecerá rx. Essa diferença pode ser importante, mas não prova que o nginx usa outro. A rota não pode executar namei ou ls, portanto, evidências externas devem fornecer caminhos e modos. Em seguida, sincroniza todas as representações para reduzir erros de transcrição durante a revisão.
Exemplo resolvido: inspecionar modos fornecidos para cada componente de um caminho
As decisões de propriedade permanecem fora da conversão do modo. O painel não lê nenhum proprietário ou grupo e não oferece operação chown ou chgrp. Ele não pode escolher entre implantação, serviço ou propriedade de grupo compartilhado, nem avaliar a movimentação de conteúdo. Essas decisões exigem evidências do sistema e da carga de trabalho ausentes das fontes; nenhum modo gerado pode substituir esse contexto.
Uma vez resolvida a propriedade noutro local, compare como os modos dividem o acesso. O modo 750 dá permissões completas de proprietário, leitura e execução de grupo e nada para outro; 755 adiciona outra leitura e execução. Isto permanece condicionado ao conhecimento da classe operária. A visualização do comando inerte não altera a propriedade nem confirma o acesso ao servidor.
As escolhas de propriedade permanecem externas à conversão de modo
Configuração, seleção de índice, controle de acesso obrigatório e comportamento upstream não são diagnosticados aqui. Nenhuma fonte carrega a configuração do nginx, verifica um URI ou índice, lê logs, entra em contato com um upstream ou observa SELinux ou AppArmor. A conversão correta de um modo fornecido, portanto, não pode estabelecer por que o nginx retornou 403; a evidência do servidor deve responder a essa pergunta.
Preserve esta distinção quando um modo parecer suspeito. O painel pode mostrar que falta execução em uma classe de diretório ou falta leitura em uma classe de arquivo, mas a relevância depende da identidade e da evidência do caminho. Os bits permissivos também não podem excluir outras causas. Indique exatamente o que o modo permite e retorne aos diagnósticos específicos do servidor.
Configuração, índice, MAC e causas upstream não são diagnosticadas
O acesso ao caminho pode depender de cada componente, mas a calculadora vê um valor fornecido por vez. Seu ponto forte é a decodificação precisa: texto octal, simbólico e caixas de seleção permanecem sincronizados, enquanto a prosa do diretório distingue listagem, modificação e entrada. Ele simplifica a revisão sem pretender descobrir os componentes ou o processo de tentativa de acesso.
Estabeleça a identidade do servidor e colete modos de caminho fora desta rota. Decodifique cada diretório como um diretório e o objeto final como um arquivo normal, concentrando-se na classe verificada externamente. Investigue a configuração, as ACLs e a política obrigatória separadamente. A calculadora valida a aritmética, mas não consegue identificar a causa de 403 ou verificar uma correção.