# Permissões de sistema de arquivos

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

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) 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.
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).
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 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.
O IBM z/OS implementa segurança de arquivos usando a Instalação de Controle de Acessos a Recursos (RACF).
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.

## Permissões da POSIX

As permissões em sistemas de arquivos do tipo Unix são definidas no padrão da POSIX.1-2017, 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.

### Classes

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.

### Permissões

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".
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

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
### Notação simbólica

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

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 100$_2$);
* o bit de gravação adiciona 2 ao seu total (em binário 010$_2$), e
* o bit de execução adiciona 1 ao seu total (em binário 001$_2$).
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

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.