Ferramentas de desenvolvedor · Calculadora Chmod
Como umask decide as permissões padrão de novos arquivos e pastas
· Como funciona
chmod unix fluxo de trabalho do desenvolvedor
Novos arquivos não começam em 777; uma máscara é aplicada primeiro. Esta postagem mostra a operação bit a bit exata, por que arquivos e diretórios acabam diferentes e como raciocinar sobre umask 022, 027 e 077.
Arquivos que o servidor web não pode ler - um cron job grava arquivos 600 em um diretório que o nginx serve e ninguém executou chmod em nada
Um modo de arquivo recentemente observado pode ser decodificado aqui mesmo quando o processo que o produziu é desconhecido. Digite 600 e a calculadora mostra rw-------: proprietário lê e escreve, sem permissões para grupo ou outro. Isso explica os bits do resultado fornecido. Ele não estabelece por que um trabalho agendado produziu esse valor ou se um processo da Web pode ler o arquivo.
O artigo 501 fornece a restrição diagnóstica necessária. Um modo válido pode coexistir com propriedade incorreta ou com um bit de execução ausente em um diretório pai. Esta página não recebe identidade de processo nem informações de caminho. Ele pode comparar 600 com um 640 proposto e expor o bit de leitura de grupo adicionado, mas não pode atribuir o modo original a umask, um serviço, um shell ou um sistema de arquivos.
De onde vêm as novas permissões - o modo solicitado (geralmente 666 para arquivos, 777 para diretórios) e umask do processo
Os modos de criação solicitados e umask são entradas em segundo plano, não controles da calculadora. Não há campo umask e nenhuma operação que crie um arquivo ou diretório. Qualquer exemplo de modo de criação deve, portanto, chegar como um resultado computado externamente. Uma vez fornecida, a calculadora pode traduzir esse resultado entre as formas octal, simbólica, matricial, resumida e em inglês simples, sem afirmar como o valor foi obtido.
Esse escopo corrigido é importante porque a saída sincronizada pode parecer mais confiável do que realmente é. Inserir 640 produz rw-r----- e identifica o proprietário read/write mais a leitura do grupo. A página pode verificar essa representação. Ele não pode prever padrões para um processo de login, tarefa agendada, serviço, contêiner ou sistema de armazenamento, porque nenhum desses contextos aparece entre suas entradas ou implementação.
Os modos de criação solicitados e umask são entradas em segundo plano não implementadas aqui
A aritmética AND-NOT deve ser realizada fora desta calculadora. Seu núcleo aceita um número inteiro completo e o explode em sinalizadores nomeados; não possui segundo operando para uma máscara de criação. Conseqüentemente, a página não pode demonstrar uma fórmula de máscara, comparar a subtração com operações bit a bit ou decidir se um cálculo externo foi executado corretamente antes de seu modo resultante ser inserido.
O que ele pode verificar é o padrão de bits final. Se outra fonte confiável fornecer 640, a matriz mostrará leitura e gravação do proprietário, leitura do grupo e nenhuma outra permissão. Alterar reconstruções de leitura de grupo 600, enquanto altera outras reconstruções de leitura 644. Essas transições verificam o modo aritmético dentro do conversor sem apresentá-las como cálculos de máscara de criação ou evidências sobre um processo invisível.
AND-NOT a aritmética deve ser realizada fora da calculadora
A calculadora pode comparar os modos de arquivo e diretório resultantes, mas não cria nenhum deles. Com 644 selecionado, a explicação do arquivo regular descreve a leitura e alteração de um arquivo; mudar o destino para diretório altera esses verbos para listar, modificar entradas e alcançar nomes. O número inteiro permanece 644. Esse contraste demonstra por que o tipo de destino é importante sem afirmar qual criação padroniza qualquer solicitação do programa.
Um resultado 755 fornecido separadamente pode ser inspecionado da mesma maneira. Seu display é rwxr-xr-x, com execução ativa para todas as classes; 644 é rw-r--r--, com execução ausente por toda parte. A página expõe claramente essa diferença. Ele não deriva nenhum valor de 666, 777, 022 ou qualquer outra entrada em segundo plano, porque esses cálculos não são implementados em CHMOD_SOURCES.
A calculadora pode comparar os modos de arquivo e diretório resultantes, mas não cria nenhum
Para um exemplo de máscara restritiva, mantenha a computação externa e decodifique apenas os resultados declarados. Se um arquivo regular observado for 640, a calculadora renderiza rw-r-----; se um diretório observado for 750, ele renderizará rwxr-x---. O proprietário mantém acesso mais amplo em ambos, o grupo recebe um conjunto mais restrito e o outro não recebe nenhum. Essas declarações decorrem diretamente dos modos concluídos.
Outro par fornecido externamente, 600 e 700, torna o mesmo método de revisão visível sem reivindicar sua origem. O modo 600 fornece apenas leitura e gravação do proprietário em um arquivo. O modo 700 fornece apenas leitura, gravação e execução do proprietário em um diretório. O conversor pode confirmar cada classe e bit, mas não pode corresponder nenhum dos resultados a uma configuração umask específica a partir de sua própria evidência.
Exemplo resolvido: decodificar resultados computados externamente para máscaras restritivas
Onde um processo obtém umask está fora da evidência do repositório. A calculadora não contém integração com shells, agendadores, gerenciadores de serviços, contêineres ou ambientes de processos. Nomear um desses sistemas como a causa de um modo excederia, portanto, o que a página observa. Comece com um modo confiável reunido em outro lugar e, em seguida, use essa rota apenas para tornar legíveis seu proprietário, grupo e outros bits.
A visualização do comando não fecha essa lacuna de evidências. Ele pode citar um caminho fornecido e, opcionalmente, exibir -R, mas nunca abre o caminho ou lê as configurações do processo. Da mesma forma, o seletor de destino altera a linguagem explicativa em vez de descobrir um tipo de objeto. Uma conversão consistente restringe a questão das permissões; não revela qual componente selecionou o modo ou se a seleção foi intencional.
Onde um processo obtém umask está fora da evidência do repositório
ACLs padrão e modos de criação explícitos estão fora desta ferramenta. Seu modelo de dados possui uma classe proprietária, uma classe de grupo, todas as demais e três bits especiais. Não há entradas ACL nomeadas, máscaras ACL, chamadas de criação ou argumentos de programa. A calculadora, portanto, não pode decidir se um modo concluído surgiu de outra camada de controle de acesso ou de uma aplicação que fornece uma solicitação específica.
Um modo ainda pode ser verificado sem reunir esses mecanismos. Insira o valor octal observado, confirme as nove posições simbólicas e compare a matriz com o resumo de quatro dígitos. Se concordarem, o modo tradicional foi decodificado corretamente. Qualquer reclamação sobre padrões, efeitos ACL ou comportamento do programa requer evidências do criador e do sistema de arquivos, e não outra interpretação do mesmo número inteiro.
ACLs padrão e modos abertos explícitos estão fora desta ferramenta
O fluxo de trabalho corrigido é computado em outro lugar e, em seguida, inspecione o modo resultante aqui. Forneça a string completa no estilo octal ou ls e deixe os campos sincronizados exporem cada bit. A validação detecta dígitos e letras octais malformados em posições simbólicas incorretas. Ele não valida uma expressão umask, descobre um contexto de criação ou prevê o que um arquivo ou diretório futuro receberá.
Trate o resultado como uma camada de diagnóstico. Um 640 ou 750 decodificado pode revelar uma concessão inesperada ou um bit de execução ausente, enquanto o artigo 501 nos lembra de verificar a propriedade e a travessia do diretório pai separadamente. Pare antes de atribuir uma causa. A calculadora prova como um valor fornecido é mapeado para permissões; ele não oferece base para reivindicações sobre padrões de shell, serviço, contêiner, ACL ou sistema de arquivos.