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 [en] o conteúdo do sistema de arquivos. Em alguns casos, as opções ou funções do menu podem ficar visíveis ou ocultas (dependendo do nível de permissão do usuário). Esse tipo de interface de usuário é conhecida como orientada por permissão.

Dois tipos de permissões estão amplamente disponíveis: permissões do sistema de arquivos POSIX e listas de controle de acessos (L.C.A.)^[a] que são capazes de um controle mais específico.

O sistema de arquivos original Tabela de alocação de arquivos (T.A.A.)^[b] possui um atributo somente leitura para todos os usuários por arquivo.

O NTFS implementado no Windows NT da Microsoft e seus derivados, usa listas de controle de acessos (L.C.A.)^[a][1] para fornecer um conjunto complexo de permissões.

O OpenVMS usa um esquema de permissão semelhante ao do Unix. Existem quatro categorias (sistema, proprietário, grupo e mundo) e quatro tipos de permissões de acesso (ler, gravar, executar e excluir). As categorias não são mutuamente separadas: "mundo" inclui "grupo", que por sua vez inclui "proprietário". A categoria "Sistema" inclui, independentemente, os usuários do sistema.^[2]

O HFS, e seu sucessor o HFS+, implementado nos sistemas operacionais Mac OS Classic, não oferece suporte à permissões.

O macOS usa permissões compatíveis com POSIX. A partir da versão 10.4 ("Tiger"), ele também oferece suporte ao uso de listas de controle de acessos (L.C.A.)^[a] NFSv4 além de permissões compatíveis com POSIX. O Apple Mac OS X Server versão 10.4+ recomenda o uso de, apenas, permissões Unix tradicionais, se possível. O macOS também suporta, ainda, o atributo "protected" do Mac OS Classic.

O suporte do Solaris à listas de controle de acessos (L.C.A.)^[a] depende do sistema de arquivos que está sendo usado. O sistema de arquivos UFS mais antigo oferece suporte à listas de controle de acessos (L.C.A.)^[a] POSIX.1e, enquanto o ZFS oferece suporte apenas à listas de controle de acessos (L.C.A.)^[a] NFSv4.^[3]

O Linux suporta ext2, ext3, ext4, Btrfs e outros sistemas de arquivos, muitos dos quais incluem listas de controle de acessos (L.C.A.)^[a] POSIX.1e. Há suporte experimental para listas de controle de acessos (L.C.A.)^[a] NFSv4 para sistemas de arquivos ext3^[4] e ext4.

O FreeBSD suporta listas de controle de acessos (L.C.A.)^[a] POSIX.1e em UFS e listas de controle de acessos (L.C.A.)^[a] NFSv4 em UFS e ZFS.^[5][6]

z /OS da IBM implementa segurança de arquivos usando a instalação de controle de acesso a recursos^[c].^[7]

O sistema de arquivos do AmigaOS, o AmigaDOS [en], suporta um sistema de permissões relativamente avançado para um sistema operacional monousuário. No AmigaOS 1.x, os arquivos tinham permissões / sinalizadores de arquivar, ler, gravar, executar e excluir (coletivamente conhecidos como ARWED). No AmigaOS 2.x e superior, permissões / sinalizadores adicionais hold, script e pure foram adicionados.

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

Os arquivos e diretórios são 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 à um grupo [en], que define a classe de grupo do arquivo. Permissões distintas se aplicam aos membros do grupo do arquivo. O proprietário pode ser um membro do grupo do arquivo.

Os 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 se aplicam à outras pessoas.

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, então, outros). Por exemplo, o usuário que é o proprietário do arquivo terá as permissões concedidas à classe de usuário, independentemente das permissões atribuídas à classe de grupo ou à classe de outros.

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

• A permissão de leitura concede a capacidade de ler um arquivo. Quando definida para um diretório, essa permissão concede a capacidade de ler os nomes dos arquivos no diretório, mas não de descobrir mais informações sobre eles, como conteúdo, tipo de arquivo, tamanho, propriedade e permissões.

• A permissão de gravação/escrita concede a capacidade de modificar um arquivo. Quando definida para um diretório, essa permissão concede a capacidade de modificar entradas no diretório, o que inclui a criação de arquivos, exclusão de arquivos e renomeação de arquivos. Isso requer que a permissão executar também esteja definida. Sem ela, a permissão de gravação não tem sentido para diretórios.

• A permissão de execução concede a capacidade 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 execução é interpretada como a permissão de pesquisa: ela concede a capacidade de acessar o conteúdo do arquivo e meta-informações se seu nome for conhecido, mas não lista os arquivos dentro do diretório, a menos que a permissão leitura também seja definida.

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

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 (L.C.A.)^[a], as permissões em sistemas do tipo Unix não são herdadas. Os arquivos criados em um diretório não têm, necessariamente, as mesmas permissões desse diretório.

Os sistemas do tipo Unix, geralmente, empregam três modos adicionais. Na verdade, eles são atributos mas são chamados de permissões ou modos. Esses modos especiais são para um arquivo ou diretório 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 na tríade para o grupo e o bit sticky na tríade para outros.

• O set user ID, setuid ou modo SUID. Quando um arquivo com setuid é executado, o processo resultante assumirá o identificador de usuário efetivo fornecido à classe de proprietário. Isso permite que os usuários sejam tratados temporariamente como root (ou outro usuário).

• O set group ID, setgid ou permissão SGID. Quando um arquivo com setgid é executado, o processo resultante assumirá o identificador de grupo [en] dado à classe de grupo. Quando setgid é aplicado à um diretório, novos arquivos e diretórios criados nesse 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 da Distribuição de software da Berkeley (D.S.B.)^[d] que se comportam como se o bit setgid estivesse sempre definido em todos os diretórios (consulte setuid).

• O modo sticky (também conhecido como modo texto). O comportamento clássico do bit sticky em arquivos executáveis ​​tem sido encorajar o núcleo ​à reter a imagem do processo resultante na memória além do término. No entanto, esse uso do bit sticky agora está restrito à apenas uma minoria de sistemas operacionais do tipo Unix (HP-UX e UnixWare). Em um diretório, a permissão permanente evita que os usuários renomeiem, movam ou excluam arquivos contidos pertencentes à usuários que não sejam eles próprios, 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 setuid, bit setgid e bit sticky, devido ao fato de que cada um ocupa apenas um bit.

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

A forma mais comum, conforme 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, que pode ler-se
Segundo caractere	w: gravável
Terceiro caractere	x: executável s ou t: setuid/setgid ou sticky (executável também) S ou T: setuid/setgid ou sticky (não executável)

O primeiro caractere da exibição ls indica o tipo de arquivo e não está relacionado às 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 de usuário. O segundo conjunto representa a classe de grupo. O terceiro conjunto representa a classe de outros.

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

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

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

• -rwxr-xr-x: um arquivo regular cuja classe de usuário tem permissões totais e cuja classe de grupo e de outros têm apenas as permissões de leitura e execução.

• crw-rw-r--: um arquivo de caractere especial ​cujas classes de usuário e de grupo têm permissões de leitura e gravação e cuja classe de outros têm apenas permissão de leitura.

• dr-x------: um diretório cuja classe de usuário tem permissão de leitura e execução e cujas classes de grupo e de outros não têm permissão.

Em alguns sistemas de permissão, símbolos adicionais na saída 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 estendidos de arquivo estão presentes.

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

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

Outro método para representar as permissões do Unix é uma notação octal (base 8) conforme 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) endereça três atributos adicionais, o bit setuid, o bit setgid e o bit sticky.)

Cada um desses dígitos é a soma de seus bits componentes no sistema de numeração binário. Como resultado, bits específicos são adicionados à soma e representados por um numeral:

• o bit de leitura adiciona 4 ao seu total (no binário 100₂),
• o bit de gravação adiciona 2 ao seu total (no binário 010₂) e
• o bit de execução adiciona 1 ao seu total (no binário 001₂).

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 [en]. Cada bit faz referência à uma permissão separada e agrupar 3 bits (por vez, em octal) corresponde ao agrupamento dessas permissões por usuário, grupo e outros.

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

Notação simbólica	Notação numérica	Descrição
----------	00008	nenhuma permissão
-rwx------	07008	ler, gravar e executar apenas para o proprietário
-rwxrwx---	07708	ler, gravar e executar apenas para o proprietário e grupo
-rwxrwxrwx	07778	ler, gravar e executar apenas para o proprietário, grupo e outros
---x--x--x	01118	executar
--w--w--w-	02228	gravar
--wx-wx-wx	03338	gravar e executar
-r--r--r--	04448	ler
-r-xr-xr-x	05558	ler e executar
-rw-rw-rw-	06668	ler e gravar
-rwxr-----	07408 ​	o proprietário pode ler, gravar e executar, o grupo só pode ler e outros não têm permissões

Alguns sistemas divergem do modelo POSIX tradicional de usuários e grupos criando um novo grupo, um "grupo privado de usuários", para cada usuário. Assumindo que cada usuário seja o único membro de seu grupo privado de usuários, este esquema permite que um umask 002 seja usado sem permitir que outros usuários gravem em arquivos recém-criados em diretórios normais porque esses arquivos são atribuídos ao grupo privado do usuário que os criou. No entanto, quando o compartilhamento de arquivos é desejável, o administrador pode criar um grupo contendo os usuários desejados, criar um diretório gravável em grupo atribuído ao novo grupo e, o 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 o umask 002 (habilitado usando grupos privados de usuários) garantirá que outros membros do grupo serão capazes de gravar nesses arquivos.^[10][11]

• chattr ou chflags: altera atributos ou sinalizadores, incluindo aqueles que restringem o acesso.
• chmod: altera modos (permissões) em sistemas de arquivos do tipo Unix.
• Comparação de sistemas de arquivos § Metadados [en]
• Descrição do lsattr: lista os atributos.
• Identificador de grupo [en]
• Identificador de usuário
• POSIX
• umask

Referências

1. ↑ «File and folder permissions» [Permissões de arquivo e pasta] (em inglês). Microsoft 
2. ↑ «OpenVMS documentation» [Documentação OpenVMS] (em inglês). Consultado em 6 de setembro de 2009. Arquivado do original em 5 de março de 2012 
3. ↑ «Oracle Solaris ZFS administration guide» [Guia de administração do Oracle Solaris ZFS] (PDF) (em inglês). Setembro de 2010 
4. ↑ «Native NFSv4 ACLs on Linux» [Listas de controle de acessos NFSv4 nativas no Linux] (em inglês). Consultado em 27 de maio de 2021. Arquivado do original em 12 de outubro de 2008 
5. ↑ «NFSv4_ACLs – FreeBSD Wiki» [Listas de controle de acessos NFSv4 - Wiki FreeBSD] (em inglês) 
6. ↑ «FreeNAS 9.1.1 Users Guide» [Guia do usuário do FreeNAS 9.1.1] (PDF) (em inglês). 2013 
7. ↑ «IBM knowledge center» [Centro de conhecimento IBM] (em inglês) 
8. ↑ «Definitions, 3.175 File permission bits» [Definições, 3.175 Bits de permissão de arquivo]. pubs.opengroup.org (em inglês). 22 de julho de 2018. Consultado em 24 de junho de 2023 
9. ↑ Hatch, Bri (24 de abril de 2003). «Linux file permission confusion part 2» ["Confusão de permissão de arquivo Linux parte 2"]. Hacking Linux exposed (em inglês). Consultado em 27 de maio de 2021 
10. ↑ Epstein, Brian. «The how and why of user private groups in Unix» [O como e o porquê de grupos privados de usuários no Unix]. security.ias.edu (em inglês). Institute for advanced study network security. Consultado em 28 de maio de 2021 
11. ↑ «Red Hat Enterprise Linux 7 System administrator's guide, 4.3.4 Creating group directories». Red Hat Customer Portal (em inglês). Red Hat 

Ligações externas

[editar | editar código-fonte]

• O livro de receitas Linux: Grupos e como trabalhar neles (em inglês) por Michael Stutz 2004