Saltar para o conteúdo

Permissões de sistema de arquivos

Origem: Wikipédia, a enciclopédia livre.

A maioria dos sistemas de arquivos inclui atributos de arquivos e diretórios que controlam a capacidade dos usuários de ler, alterar, navegar e executar o conteúdo do sistema de arquivos. Em alguns casos, opções de menu ou funções podem ser tornadas visíveis ou ocultas dependendo do nível de permissão do usuário; esse tipo de interface de usuário é chamado de orientada por permissão.

Dois tipos de permissões estão amplamente disponíveis: as permissões do sistema de arquivos da POSIX e as listas de controle de acessos (ACLs), que são capazes de controle mais específico.

Variações de sistemas de arquivos

[editar | editar código-fonte]

O sistema de arquivos da Tabela de Alocação de Arquivos (FAT) original tem um atributo "somente leitura" para todos os usuários por arquivo.

O Sistema de Arquivos de Nova Tecnologia (NTFS) implementado no Microsoft Windows NT e seus derivados usa Listas de Controle de Acessos (ACLs)[1] para fornecer um conjunto complexo de permissões.

O OpenVMS usa um esquema de permissões semelhante ao do Unix. Existem quatro categorias (sistema, proprietário, grupo, e mundo) e quatro tipos de permissões de acesso (leitura, gravação, execução, e exclusão). As categorias não são mutuamente disjuntas: Mundo inclui Grupo, que por sua vez inclui Proprietário. A categoria Sistema inclui usuários do sistema independentemente.[2]

O Sistema de Arquivos Hierárquico (HFS) e seu sucessor o HFS+, conforme implementado nos sistemas operacionais Macintosh clássicos, não oferecem suporte a permissões.

O macOS usa permissões compatíveis com a POSIX e oferece suporte a elas tanto no HFS+ quanto no Sistema de Arquivos da Apple (APFS). A partir da versão 10.4 ("Tiger"), ele também oferece suporte ao uso de Listas de Controle de Acessos (ACLs) da versão 4 do Sistema de Arquivos de Redes (NFSv4), além de permissões compatíveis com a POSIX. O Manual de Administração de Serviços de Arquivos do Apple Mac OS X Server versão 10.4+ recomenda usar somente permissões do Unix tradicionais, se possível. O macOS também ainda oferece suporte ao atributo "Protegido" do Mac OS clássico.

O suporte a Listas de Controle de Acessos (ACLs) do Solaris depende do sistema de arquivos que está sendo usado; o Sistema de Arquivos do Unix (UFS) mais antigo suporta Listas de Controle de Acessos (ACLs) da POSIX.1e, enquanto o ZFS suporta apenas Listas de Controle de Acessos (ACLs) da versão 4 do Sistema de Arquivos de Redes (NFSv4).[3]

O Linux suporta ext2, ext3, ext4, Btrfs e outros sistemas de arquivos, muitos dos quais incluem Listas de Controle de Acessos (ACLs) da POSIX.1e. Há suporte experimental para Listas de Controle de Acessos (ACLs) da versão 4 do Sistema de Arquivos de Redes (NFSv4) para os sistemas de arquivos ext3[4] e ext4.

O FreeBSD suporta Listas de Controle de Acessos (ACLs) da POSIX.1e no Sistema de Arquivos do Unix (UFS), e Listas de Controle de Acessos (ACLs) da versão 4 do Sistema de Arquivos de Redes (NFSv4) no Sistema de Arquivos do Unix (UFS) e no ZFS.[5][6]

O IBM z/OS implementa segurança de arquivos usando a Instalação de Controle de Acessos a Recursos (RACF).[7]

O Sistema de arquivos do AmigaOS (no AmigaDOS) suporta um sistema de permissões relativamente avançado para um sistema operacional de usuário único. Nas versões 1.x do AmigaOS, os arquivos tinham permissões/sinalizadores para Arquivar, Ler, Escrever, Executar e Excluir (coletivamente conhecidos como ARWED). Nas versões 2.x e superiores do AmigaOS, permissões/sinalizadores para Hold, Script, e Pure (HSP) foram adicionados.

O sistema operacional OpenHarmony juntamente com seu ecossistema do lado para clientes no Oniro OS e no HarmonyOS com versões HarmonyOS NEXT e também o sistema operacional para servidores OpenEuler baseado em Linux usam nativamente seu Sistema de Arquivos Distribuídos do Harmony (HMDFS) que suporta o gerenciador de tokens de acessos (controle de acesso baseado em funções) e, baseado na capacidade da Interface de Programação de Aplicações (API) do Core File Kit, com gerenciamento granular de permissões, com exceção do openEuler.[8]

Permissões da POSIX

[editar | editar código-fonte]

As permissões em sistemas de arquivos do tipo Unix são definidas no padrão da POSIX.1-2017,[9] que usa três escopos ou classes conhecidos como proprietário, grupo e outros. Quando um arquivo é criado, suas permissões são restritas pela umask do processo que o criou.

Arquivos e diretórios são de propriedade de um usuário. O proprietário determina a classe de usuário do arquivo. Permissões distintas se aplicam ao proprietário.

Arquivos e diretórios são atribuídos a um grupo, que define a classe de grupo do arquivo. Permissões distintas aplicam-se aos membros do grupo do arquivo. O proprietário pode ser um membro do grupo do arquivo.

Usuários que não são o proprietário, nem um membro do grupo, compõem a classe de outros de um arquivo. Permissões distintas aplicam-se a outros.

As permissões efetivas são determinadas com base na primeira classe em que o usuário se enquadra na ordem de usuário, grupo e, em seguida, outros. Por exemplo, o usuário que é o proprietário do arquivo terá as permissões dadas à classe de usuário independentemente das permissões atribuídas à classe de grupo ou à classe de outros.

Sistemas do tipo Unix implementam três permissões específicas que aplicam-se a cada classe:

  • A permissão de leitura concede a habilidade de ler um arquivo. Quando definida para um diretório, essa permissão concede a habilidade de ler os nomes dos arquivos no diretório, mas não de descobrir mais informações sobre eles, como conteúdo, tipo, tamanho, propriedade, e permissões do arquivo.
  • A permissão de gravação concede a habilidade de modificar um arquivo. Quando definida para um diretório, essa permissão concede a habilidade de modificar entradas no diretório, o que inclui criar arquivos, excluir arquivos e renomear arquivos. Isso requer que a permissão de executar também esteja definida; sem ela, a permissão de gravação não tem sentido para diretórios.
  • A permissão de executar concede a habilidade de executar um arquivo. Essa permissão deve ser definida para programas executáveis, a fim de permitir que o sistema operacional os execute. Quando definida para um diretório, a permissão de executar é interpretada como a permissão de pesquisar: ela concede a habilidade de acessar o conteúdo e meta-informações do arquivo se seu nome for conhecido, mas não listar arquivos dentro do diretório, a menos que a permissão de leitura também esteja definida.

O efeito de definir as permissões em um diretório, em vez de em um arquivo, é "um dos problemas de permissões de arquivos mais frequentemente mal compreendidos".[10]

Quando uma permissão não é definida, os direitos correspondentes são negados. Ao contrário dos sistemas baseados em Listas de Controle de Acessos (ACLs), as permissões em sistemas do tipo Unix não são herdadas. Arquivos criados dentro de um diretório não têm necessariamente as mesmas permissões que esse diretório.

Alterando o comportamento dad permissões com bits de setuid, setgid e sticky

[editar | editar código-fonte]

Sistemas do tipo Unix geralmente empregam três modos adicionais. Na verdade, esses são atributos, mas são chamados de permissões ou modos. Esses modos especiais são para um arquivo ou diretório em geral, não por uma classe, embora na notação simbólica (veja abaixo) o bit setuid seja definido na tríade para o usuário, o bit setgid seja definido na tríade para o grupo e o bit sticky seja definido na tríade para os outros.

  • O modo de set user ID, setuid, ou SUID. Quando um arquivo com setuid é executado, o processo resultante assumirá o identificador do usuário efetivo dado à classe do proprietário. Isso permite que os usuários sejam tratados temporariamente como root (ou outro usuário).
  • A permissão de set group ID, setgid, ou SGID. Quando um arquivo com setgid é executado, o processo resultante assumirá o identificador do grupo fornecido à classe do grupo. Quando o setgid é aplicado a um diretório, novos arquivos e diretórios criados sob esse diretório herdarão seu grupo desse diretório. (O comportamento padrão é usar o grupo primário do usuário efetivo ao definir o grupo de novos arquivos e diretórios, exceto em sistemas derivados do BSD que se comportam como se o bit setgid estivesse sempre definido em todos os diretórios [veja Setuid].)
  • O modo de sticky (também conhecido como modo de Texto). O comportamento clássico do bit de sticky em arquivos executáveis tem sido o de encorajar o núcleo a reter a imagem do processo resultante na memória além do término; no entanto, esse uso do bit de sticky agora está restrito a apenas uma minoria de sistemas operacionais do tipo Unix (HP-UX e UnixWare). Em um diretório, a permissão de sticky impede que os usuários renomeiem, movam, ou excluam os arquivos contidos que são de propriedade de usuários que não sejam eles mesmos, mesmo que tenham permissão de gravação no diretório. Apenas o proprietário do diretório e o superusuário estão isentos disso.

Esses modos adicionais também são chamados de bit de setuid, bit de setgid, e bit de sticky, devido ao fato de que cada um ocupa apenas um bit.

Notação das permissões do Unix tradicionais

[editar | editar código-fonte]

Notação simbólica

[editar | editar código-fonte]

As permissões do Unix são representadas em notação simbólica ou em notação octal.

A forma mais comum, como usada pelo comando ls -l, é a notação simbólica.

Três tríades de permissões
primeira tríade o que o proprietário pode fazer
segunda tríade o que os membros do grupo podem fazer
terceira tríade o que outros usuários podem fazer
Cada tríade
primeiro caractere r: legível
segundo caractere w: gravável
terceiro caractere x: executável
s ou t: setuid/setgid ou sticky (também executável)
S ou T: setuid/setgid ou sticky (que não é executável)

O primeiro caractere da exibição do ls indica o tipo de arquivo e não está relacionado a permissões. Os nove caracteres restantes estão em três conjuntos, cada um representando uma classe de permissões como três caracteres. O primeiro conjunto representa a classe do usuário. O segundo conjunto representa a classe do grupo. O terceiro conjunto representa a classe dos outros.

Cada um dos três caracteres representa as permissões de leitura, gravação e execução:

  • r se ler for permitido, - se não for.
  • w se gravar for permitido, - se não for.
  • x se executar for permitido, - se não for.

A seguir estão alguns exemplos da notação simbólica:

  • -rwxr-xr-x: um arquivo regular cuja classe de usuário tem permissões totais e cuja as classes grupo e outros têm apenas permissões de leitura e execução.
  • crw-rw-r--: um arquivo especial de caracteres cujas classes de usuário e grupo têm permissões de leitura e gravação e cuja classe de outros tem apenas permissão de leitura.
  • dr-x------: um diretório cuja classe de usuário tem permissões de leitura e execução e cuja as classes grupo e outros não têm permissões.

Em alguns sistemas de permissões, símbolos adicionais na exibição do ls -l representam recursos de permissão adicionais:

  • o sufixo + (mais) indica uma lista de controle de acesso que pode controlar permissões adicionais.
  • o sufixo . (ponto) indica que um contexto do SELinux está presente. Os detalhes podem ser listados com o comando ls -Z.
  • o sufixo @ indica que atributos de arquivo estendidos estão presentes.

Para representar os atributos de setuid, setgid e sticky ou texto, o caractere de executável (x ou -) é modificado. Embora esses atributos afetem o arquivo geral, não apenas os usuários em uma classe, o atributo de setuid modifica o caractere de executável na tríade para o usuário, o atributo de setgid modifica o caractere de executável na tríade para o grupo e o atributo de sticky ou texto modifica o caractere de executável na tríade para outros. Para os atributos de setuid ou setgid, na primeira ou segunda tríade, o x se torna s e o - se torna S. Para o atributo de sticky ou texto, na terceira tríade, o x se torna t e o - se torna T. Aqui está um exemplo:

  • -rwsr-Sr-t: um arquivo cuja classe do usuário tem permissões de leitura, gravação e execução; cuja classe do grupo tem permissão de leitura; cuja classe dos outros tem permissões de leitura e execução; e que tem os atributos de setuid, setgid e sticky ou texto definidos.

Notação numérica

[editar | editar código-fonte]

Outro método para representar permissões do Unix é uma notação octal (de base 8) como mostrado por stat -c %a. Essa notação consiste em pelo menos três dígitos. Cada um dos três dígitos mais à direita representa um componente diferente das permissões: proprietário, grupo e outros. (Se um quarto dígito estiver presente, o dígito mais à esquerda (de ordem superior) aborda três atributos adicionais, o bit de setuid, o bit de setgid e o bit de sticky.)

Cada um desses dígitos é a soma de seus bits de componentes no sistema numérico binário. Como resultado, bits específicos são adicionados à soma, pois ela é representada por um numeral:

  • o bit de leitura adiciona 4 ao seu total (em binário 1002);
  • o bit de gravação adiciona 2 ao seu total (em binário 0102), e
  • o bit de execução adiciona 1 ao seu total (em binário 0012).

Esses valores nunca produzem combinações ambíguas; cada soma representa um conjunto específico de permissões. Mais tecnicamente, esta é uma representação octal de um campo de bits – cada bit faz referência a uma permissão separada, e agrupar 3 bits por vez em octal corresponde a agrupar essas permissões por usuário, grupo e outros.

Estes são os exemplos da seção da notação simbólica:

Notação
simbólica
Notação
numérica
Significado
---------- 0000 sem permissões
-rwx------ 0700 ler, gravar, e executar (somente para proprietário)
-rwxrwx--- 0770 ler, gravar, e executar (para proprietário e grupo)
-rwxrwxrwx 0777 ler, gravar, e executar (para proprietário, grupo, e outros)
---x--x--x 0111 executar (para proprietário, grupo, e outros)
--w--w--w- 0222 gravar (para proprietário, grupo, e outros)
--wx-wx-wx 0333 gravare executar (para proprietário, grupo, e outros)
-r--r--r-- 0444 ler (para proprietário, grupo, e outros)
-r-xr-xr-x 0555 ler e executar (para proprietário, grupo, e outros)
-rw-rw-rw- 0666 ler e gravar (para proprietário, grupo, e outros)
-rwxr----- 0740 ler, escrever e executar (para proprietário); ler (para grupo); sem permissões (para outros)

Grupo particular do usuário

[editar | editar código-fonte]

Alguns sistemas divergem do modelo da POSIX tradicional de usuários e grupos ao criar um novo grupo – um "grupo particular do usuário" – para cada usuário. Assumindo que cada usuário é o único membro de seu respectivo grupo particular de usuário, esse esquema permite que uma umask de 002 seja usada sem permitir que outros usuários gravem em arquivos recém-criados em diretórios normais porque tais arquivos são atribuídos ao grupo particular do usuário criador. No entanto, quando compartilhar arquivos é desejável, o administrador pode criar um grupo contendo os usuários desejados, criar um diretório gravável por grupo atribuído ao novo grupo e, mais importante, tornar o diretório setgid. Torná-lo setgid fará com que os arquivos criados nele sejam atribuídos ao mesmo grupo que o diretório e a umask 002 (habilitada pelo uso de grupos particulares de usuários) garantirá que outros membros do grupo possam gravar nesses arquivos.[11][12]

Referências

  1. «File and Folder Permissions». Microsoft. 9 de dezembro de 2009 
  2. «OpenVMS documentation». Consultado em 6 de junho de 2009. Arquivado do original em 5 de março de 2012 
  3. «Oracle Solaris ZFS Administration Guide» (PDF). Setembro de 2010 
  4. «Native NFSv4 ACLs on Linux». Consultado em 4 de maio de 2010. Arquivado do original em 12 de outubro de 2008 
  5. «NFSv4_ACLs – FreeBSD Wiki» 
  6. «FreeNAS 9.1.1 Users Guide» (PDF). 2013. Arquivado do original (PDF) em 24 de setembro de 2015 
  7. «IBM Knowledge Center». Arquivado do original em 29 de junho de 2013 
  8. «HarmonyOS Distributed File System Development Guide». Substack. LivingInHarmony Blog. 13 de março de 2024. Consultado em 13 de março de 2024 
  9. «Definitions, 3.175 File Permission Bits». pubs.opengroup.org. 22 de julho de 2018. Consultado em 24 de junho de 2023 
  10. Hatch, Bri. "Linux File Permission Confusion pt 2", "Hacking Linux Exposed", 24 de abril de 2003, acessado em 6 de julho de 2011.
  11. Epstein, Brian. «The How and Why of User Private Groups in Unix». security.ias.edu. Institute for Advanced Study Network Security. Consultado em 5 de agosto de 2014. Arquivado do original em 8 de agosto de 2014 
  12. «Red Hat Enterprise Linux 7 System Administrator's Guide, 4.3.4 Creating Group Directories». Red Hat Customer Portal. Red Hat