Permissões de sistema de arquivos

Normalmente, um sistema de arquivos mantém configurações de permissão para cada item armazenado – comumente arquivos e diretórios – que concedem ou negam a capacidade de manipular itens do sistema de arquivos. Frequentemente, as configurações permitem controlar o acesso com base na função, como ler, alterar, navegar e executar, e para diferentes usuários e grupos de usuários.

Uma tecnologia bem estabelecida foi desenvolvida para Unix e posteriormente codificada pelo POSIX. Outra tecnologia comum é uma lista de controle de acesso (ACL) com múltiplas variantes implementadas em sistemas de arquivos e uma codificada pelo POSIX. Como o POSIX define tanto a tecnologia mais antiga baseada em Unix quanto as ACLs, a primeira é chamada de permissões POSIX tradicionais para clareza, embora não seja um termo muito conhecido.

Uma interface de usuário orientada a permissões adapta a funcionalidade disponível ao usuário com base nas permissões dos itens do sistema de arquivos. Por exemplo, a interface pode ocultar opções de menu que não são permitidas com base nas permissões armazenadas para um item.

História

CTSS

Um sistema de compartilhamento de tempo antigo, o Compatible Time-Sharing System (CTSS), suportava múltiplos usuários; cada conta de usuário tinha um "número de problema" (problem number) e um "número de programador" (programmer number).[1]

A primeira versão do sistema de arquivos CTSS suportava apenas dois modos de arquivo de "somente leitura", um dos quais pode ser desmarcado pelo usuário e o outro só pode ser desmarcado com cartões de edição enviados ao centro de computação.[1](45–46) Arquivos podem ser compartilhados entre usuários no mesmo projeto; arquivos compartilhados são atribuídos ao número de programador zero.[1](p24) Não há proteção além daquela fornecida pelos bits de somente leitura.

A segunda versão do sistema de arquivos possui bits de permissão separados para "somente leitura" (read-only) e "somente escrita" (write-only); este último permite apenas anexar (append) ao arquivo. Também possui um bit "privado", permitindo que apenas o autor do arquivo o acesse, e um bit "protegido", permitindo que apenas o autor do arquivo altere as permissões do arquivo.[2]

Multics

Usuários no sistema de compartilhamento de tempo Multics possuem um "Person_id", e projetos possuem um "Project_id"; um usuário faz logon no sistema com seu Person_id e um Project_id. Um arquivo possui uma lista de controle de acesso (ACL), com entradas contendo um Person_id or um "*", um Project_id ou um "*", e uma "etiqueta de instância" (instance tag) ou um "*". Uma etiqueta de instância representa um tipo de processo; um "a", por exemplo, representa um processo de uma sessão interativa regular. As entradas em uma ACL são comparadas com o Person_id, Project_id e etiqueta de instância do processo; um "*" é um curinga que corresponde a todos os Person_ids, Project_ids ou etiquetas de instância. A entrada da ACL que corresponde com o menor número de curingas é a que é utilizada.[3](6-2,6-4­6-8)

Uma ACL para um arquivo possui permissões de acesso de "leitura" (read), "escrita" (write) e "execução" (execute); uma ACL para um diretório possui permissões de acesso de "status" (permite ler atributos de arquivos e diretórios no diretório), "modificação" (permite a modificação de atributos de arquivos e diretórios no diretório e a remoção de itens do diretório) e "anexação" (append - permite adicionar novos itens ao diretório).[3](p6-3)

TENEX

Um usuário no TENEX pertence a um conjunto de grupos.[4](p44)

Um arquivo ou diretório possui um conjunto de bits de permissão, com seis bits para permissões para o proprietário do arquivo ou diretório, seis bits para permissões para outros usuários no grupo do arquivo ou diretório, e seis bits para outros usuários. Para um arquivo, os bits de permissão são "leitura", "escrita", "execução", "anexação" (append) e "cada página do arquivo possui suas próprias permissões", com o sexto bit não sendo utilizado. Para um diretório, os bits de permissão são "acesso permitido" (se não definido, nenhum acesso ao diretório é permitido), "arquivos no diretório podem ser abertos" (sujeito aos bits de permissão do arquivo), "funções do tipo proprietário podem ser executadas sem a senha do arquivo" e "arquivos podem ser adicionados ao diretório", com o quinto e sexto bits não sendo utilizados.[4](42–44)

TOPS-10

Uma conta de usuário no TOPS-10 possui um número de programador e um número de projeto.

Um arquivo possui um conjunto de bits de permissão, com três bits para permissões para o proprietário do arquivo, três bits para permissões para outros usuários com o mesmo número de projeto que o proprietário, e três bits para todos os outros usuários. O sistema operacional pode ser configurado para tratar qualquer conta com um número de programador que seja igual ao número de programador do diretório pai como o proprietário, ou para tratar apenas uma conta com o mesmo número de programador e número de projeto que os do diretório pai como o proprietário. Os valores para os bits de permissão são:

  • 7 - sem privilégios de acesso, exceto que o proprietário pode procurar o arquivo para alterar suas permissões;
  • 6 - apenas execução (execute-only);
  • 5 - leitura e execução;
  • 4 - anexação, leitura e execução;
  • 3 - atualização, anexação, leitura e execução;
  • 2 - escrita, atualização, anexação, leitura e execução;
  • 1 - renomeação, escrita, atualização, anexação, leitura e execução;
  • 0 - alterar permissões, renomeação, escrita, atualização, anexação, leitura e execução.

O proprietário sempre tem permissão para alterar as permissões.[5]

UNIX e sistemas do tipo Unix

Arquivos na primeira edição do Unix (v1) tinham cinco bits de permissão:

  • escrita, não proprietário;
  • leitura, não proprietário;
  • escrita, proprietário;
  • leitura, proprietário;
  • executável;

e um bit set-UID.[6] Não havia noção de grupos. Isso continuou até a terceira edição (v3);[7] a quarta edição (v4) introduziu grupos, e arquivos na v4 tinham nove bits de permissão:

  • leitura, proprietário;
  • escrita, proprietário;
  • execução, proprietário;
  • leitura, grupo;
  • escrita, grupo;
  • execução, grupo;
  • leitura, outros;
  • escrita, outros;
  • execução, outros;

assim como um bit set-UID e um bit set-GID;[8] Este é o mesmo conjunto de permissões que são especificadas no POSIX e que são fornecidas pelos sistemas Unix atuais e tipo Unix.

Exemplos

As permissões do sistema de arquivos foram implementadas de muitas maneiras. Alguns exemplos notáveis são descritos aqui.(ordenados um pouco por popularidade, mas com o Mac OS clássico mencionado antes do macOS para fornecer algum contexto)

O NTFS, que está em muitas versões do Microsoft Windows incluindo a atual, utiliza ACLs para fornecer controle de acesso baseado em permissões; as ACLs do NTFS são consideradas poderosas, porém complexas.[9]

Sistemas de arquivos do Linux, como ext2, ext3, ext4, Btrfs, suportam tanto permissões POSIX quanto ACLs POSIX.1e. Existe suporte experimental para ACLs NFSv4 para os sistemas de arquivos ext3[10] e ext4.

O FreeBSD suporta ACLs POSIX.1e em UFS, e ACLs NFSv4 em UFS e ZFS.[11][12]

O HFS, e seu sucessor HFS+, como implementados nos sistemas operacionais Classic Mac OS, não suportam permissões.

O macOS suporta permissões compatíveis com POSIX, e as suporta tanto em HFS+ quanto em APFS. Começando com a versão 10.4 ("Tiger"), ele também suporta o uso de ACLs NFSv4 além das permissões compatíveis com POSIX. O manual Apple Mac OS X Server version 10.4+ File Services Administration Manual recomenda o uso apenas de permissões Unix tradicionais, se possível. O macOS também ainda suporta o atributo "Protegido"/"Bloqueado" (Protected/Locked) do Mac OS Clássico como a flag "imutável pelo usuário" (user immutable) no campo de flags do 4.4BSD.[13]

A Tabela de Alocação de Arquivos (File Allocation Table - versão original) possui um atributo de somente leitura por arquivo que se aplica a todos os usuários.

O OpenVMS define quatro funções de acesso: leitura (read), escrita (write), execução (execute) e exclusão (delete) e seleções de usuário: sistema (system), proprietário (owner), grupo (group) e mundo (world), onde mundo inclui o grupo, que por sua vez inclui o proprietário, e sistema seleciona os usuários do sistema. Este design é semelhante ao do Unix com extensões notáveis: função adicional: exclusão, e seleção de usuário adicional: sistema.[14] ACLs são suportadas no VMS 4.0 e posteriores.[15]

O suporte a ACL no Solaris depende do sistema de arquivos sendo utilizado; o sistema de arquivos UFS mais antigo suporta ACLs POSIX.1e, enquanto o ZFS suporta apenas ACLs NFSv4.[16]

O IBM z/OS implementa segurança de arquivos usando RACF (Resource Access Control Facility)[17]

O sistema de arquivos do AmigaOS, AmigaDOS, suporta um sistema de permissões relativamente avançado para um SO de usuário único. No AmigaOS 1.x, os arquivos tinham permissões/flags de Arquivo (Archive), Leitura (Read), Escrita (Write), Execução (Execute) e Exclusão (Delete) (coletivamente conhecidas como ARWED). No AmigaOS 2.x e superior, permissões/flags adicionais de Retenção (Hold), Script e Puro (Pure) foram adicionadas.

O sistema operacional OpenHarmony, juntamente com seu ecossistema de cliente no Oniro OS e HarmonyOS com versões HarmonyOS NEXT, e também o SO de servidor baseado em Linux openEuler, utiliza nativamente seu Harmony Distributed File System (HMDFS), que suporta gerenciador de tokens de acesso (controle de acesso baseado em função) e capacidade da API Core File Kit baseada em recursos com gerenciamento de permissão granular, com exceção do openEuler que é de granularidade fina.[18]

Permissões POSIX tradicionais

Tradicionalmente, permissões de arquivos em um sistema de arquivos baseado em Unix são definidas pelo POSIX.1.[19] Ele especifica três classes (usuário, grupo e outros) que permitem o mapeamento de permissões para usuários e três operações (leitura, escrita, execução) que podem ser concedidas ou negadas para cada classe. Quando um arquivo é criado, suas permissões padrão são aquelas acessíveis através do comando umask.

Em um sistema de arquivos baseado em Unix, tudo é um arquivo, até mesmo diretórios e outros arquivos especiais.

Classes

As classes determinam como as permissões se mapeiam para um usuário. As permissões da classe de usuário (user class) se aplicam ao usuário que é proprietário do arquivo. As permissões da classe de grupo se aplicam aos usuários do grupo proprietário do arquivo. A classe de outros se aplica a outros usuários.

As permissões efetivas são as permissões da classe na qual o usuário se enquadra primeiro, dada a ordem: usuário, grupo e depois outros. Por exemplo, o usuário proprietário tem permissões efetivas da classe de usuário, mesmo que esteja no grupo proprietário.

Permissões

As seguintes permissões concedem as operações correspondentes em arquivos e diretórios:

Leitura (r)

  • Para arquivos: concede a capacidade de ler o conteúdo do arquivo (não seu nome ou metadados, que são determinados pelas permissões de seu diretório pai).
  • Para diretórios: concede a capacidade de ler os nomes das entradas de diretório de seus arquivos e diretórios contidos, mas não de acessar seus metados (inode) e, portanto, seu conteúdo, o que é determinado pela permissão de execução do diretório.

Escrita (w)

  • Para arquivos: concede a capacidade de modificar o conteúdo do arquivo.
  • Para diretórios: concede a capacidade de modificar entradas no diretório, o que permite criar, excluir e renomear seus arquivos ou diretórios.
    • Fazer isso também requer a permissão de execução para acessar os metadados (inode) de todos os seus arquivos e diretórios contidos. Portanto, sem a permissão de execução, a permissão de escrita é efetivamente sem sentido.

Execução (x)

  • Para arquivos: concede a capacidade de executar um arquivo. Esta permissão deve estar definida para programas executáveis para permitir sua execução.
    • Fazer isso também requer a permissão de leitura.
  • Para diretórios: concede a capacidade de ler os metadados de seus arquivos e diretórios contidos se seus nomes forem conhecidos, mas não de ler seus nomes. Um diretório sem permissão de execução bloqueia efetivamente a leitura e a escrita do conteúdo de seus arquivos e diretórios contidos.
    • Um diretório com permissão de execução, mas sem permissão de leitura, torna o acesso ao conteúdo de seus arquivos e diretórios efetivamente um jogo de adivinhação de nomes.

Requisito geral de acesso dentro de diretórios

Acessar o conteúdo de um arquivo ou diretório dentro de um diretório requer:

  1. Saber seu nome, que é detectável se a permissão de leitura do diretório pai estiver definida (ou adivinhando seu nome).
  2. A permissão de execução do diretório pai para acessar o inode do arquivo ou diretório.
  3. Suas permissões correspondentes de leitura, escrita ou execução.

Resumo dos requisitos de permissão para operações de arquivo

Para ler de um arquivo, você precisa de:

  • A permissão de leitura do arquivo.
  • Permissão de execução em seu diretório pai.

Para escrever em um arquivo, você precisa de:

  • A permissão de escrita do arquivo.
  • Permissão de execução em seu diretório pai.

Para executar um arquivo, você precisa de:

  • A permissão de leitura e execução do arquivo.
  • Permissão de execução em seu diretório pai.

Para saber o nome do arquivo, você precisa de:

  • Permissão de leitura de seu diretório pai.

Para adicionar, remover ou renomear um arquivo, você precisa de:

  • Permissões de escrita e execução em seu diretório pai.

Notas

Os metadados de um arquivo ou diretório normalmente incluem o id do inode, tipo de arquivo, tamanho, propriedade (GUI e UID) e bits de permissão.

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

Ao contrário dos sistemas baseados em ACL, essas permissões não são herdadas. Arquivos criados dentro de um diretório não têm necessariamente as mesmas permissões que o diretório que os contém.

Alterando o comportamento das permissões com os bits setuid, setgid e sticky

Três atributos adicionais de um único bit se aplicam a cada arquivo, os quais estão relacionados a permissões e armazenados no modo de arquivo junto com as permissões.

  • O definir ID de usuário, setuid, ou modo SUID. Executar um arquivo com este bit definido resulta em um processo com o ID de usuário definido para o usuário proprietário do arquivo. Isso permite que os usuários sejam tratados temporariamente como root (ou outro usuário).
  • A permissão definir ID de grupo, setgid, ou SGID. Executar um arquivo com este bit definido resulta em um processo com o ID de grupo definido para o grupo proprietário do arquivo. Quando aplicado a um diretório, novos arquivos e diretórios criados sob esse diretório herdam seu grupo daquele 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 de BSD que se comportam como se o bit setgid estivesse sempre definido em todos os diretórios (veja Setuid).)
  • O modo sticky (também conhecido como modo Texto). O comportamento clássico do sticky bit em arquivos executáveis era encorajar o kernel a reter a imagem resultante do processo na memória além do término; no entanto, tal uso do sticky bit agora está restrito a apenas uma minoria de sistemas operacionais do tipo Unix (HP-UX e UnixWare). Em um diretório, a permissão sticky impede que os usuários renomeiem, movam ou excluam arquivos contidos que pertencem a usuários que não sejam eles próprios, mesmo que tenham permissão de escrita no diretório. Apenas o proprietário do diretório e o superusuário estão isentos disso.

Representação

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

Notação simbólica

A notação simbólica é usada no formato de saída longo do comando ls -l.

O primeiro caractere da saída indica o tipo de arquivo Unix, que não é uma permissão, embora esteja próximo à informação de permissões. Os nove caracteres restantes representam as concessões para as classes usuário, grupo e outros como grupos de concessões de operação para leitura, escrita e execução. Uma operação é negada quando mostrada como um traço ou concedida quando mostrada como r para leitura, w para escrita ou x para execução.

Exemplos:

  • -rwxr-xr-x: o - inicial indica um arquivo regular, os próximos três rwx indicam que a classe de usuário tem todas as permissões e as classes de grupo e outros (ambas r-x) têm apenas leitura e execução.
  • crw-rw-r--: o c inicial indica um arquivo especial de caractere, as classes de usuário e grupo (ambas rw-) têm permissões de leitura e escrita e a classe de outros (r--) tem apenas permissão de leitura.
  • dr-x------: o d inicial indica um diretório, a classe de usuário (r-x) tem permissões de leitura e execução e as classes de grupo e outros (ambas ---) não têm permissões.

Para representar os atributos setuid, setgid e sticky/text, o caractere na terceira posição de uma classe é modificado, embora esta posição seja normalmente apenas para execução e embora esses atributos afetem o arquivo independentemente da classe. O atributo setuid modifica o caractere de execução para a classe de usuário, o atributo setgid modifica o caractere de execução para a classe de grupo, e o atributo sticky ou texto modifica o caractere de execução para a classe de outros. Para setuid ou setgid, x torna-se s e - torna-se S. Para o atributo sticky ou texto, x torna-se t e - torna-se T. Por exemplo, -rwsr-Sr-t indica um arquivo regular, onde a classe de usuário tem permissões de leitura, escrita e execução; a classe de grupo tem permissão de leitura; a classe de outros tem permissões de leitura e execução; e o qual possui os atributos setuid, setgid e sticky definidos.

Alguns sistemas mostram recursos de permissão adicionais:

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

Notação octal

As permissões são frequentemente mostradas em notação octal, por exemplo, através do comando stat -c %a. A notação consiste em pelo menos três dígitos. Os últimos três dígitos representam a permissão por classe: usuário, grupo e outros. Se um quarto dígito estiver presente, o mais à esquerda representa os três atributos especiais: setuid, setgid e sticky.

Cada concessão de operação é atribuída a uma posição de bit que, para um dígito octal, é:

  • Leitura: esquerda, binário 100, octal 4
  • Escrita: meio, binário 010, octal 2
  • Execução: direita, binário 001, octal 1

Um valor de permissão de classe é a soma ou, alternativamente, a OU lógica das concessões.

Exemplos:

SimbólicoOctalDescrição
----------0000sem permissões
-rwx------0700leitura, escrita e execução apenas para o proprietário
-rwxrwx---0770leitura, escrita e execução para o proprietário e grupo
-rwxrwxrwx0777leitura, escrita e execução para o proprietário, grupo e outros
-rwxr-----0740o proprietário pode ler, escrever e executar; o grupo pode apenas ler; outros não têm permissões

Grupo privado do usuário

Alguns sistemas divergem do modelo POSIX tradicional de usuários e grupos criando um novo grupo – um "grupo privado do usuário" (user private group) – para cada usuário. Assumindo que cada usuário é o único membro de seu grupo privado, este esquema permite que um umask de 002 seja usado sem permitir que outros usuários escrevam em arquivos recém-criados em diretórios normais, porque tais arquivos são atribuídos ao grupo privado do usuário criador. 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 pelo 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 do diretório, e o umask 002 (ativado pelo uso de grupos privados de usuários) garantirá que outros membros do grupo possam escrever nesses arquivos.[21][22]

Ver também

  • chattr ou chflags – Alterar atributos ou flags, incluindo aqueles que restringem o acesso
  • chmod — comando para alterar permissões e sinalizações dentro de sistemas UNIX / Linux
  • lsattr – Listar atributos
  • Comparação de sistemas de arquivos § Metadados

Referências

  1. 1 2 3 The Compatible Time-Sharing System: A Programmer's Guide (PDF). [S.l.]: The MIT Press. 1963
  2. ↑ The Compatible Time-Sharing System: A Programmer's Guide (PDF) Second ed. [S.l.]: The MIT Press. 1965. Section AD.2, p. 5
  3. 1 2 Multics Programmer's Manual Reference Guide (PDF). [S.l.]: Honeywell. Dezembro de 1975
  4. 1 2 TENEX Executive Manual (PDF). [S.l.]: BBN. Abril de 1973
  5. ↑ DECsystem 10 Monitor Calls Manual (PDF). [S.l.]: DEC. Maio de 1974
  6. ↑ Unix Programmer's Manual, System calls, Part 1 (PDF). [S.l.: s.n.] 3 de novembro de 1971. SYS CHMOD (II)
  7. ↑ «Tarball of v3 man pages; see stat.2»
  8. ↑ «Tarball of v4 man pages; see stat.2»
  9. ↑ «File and Folder Permissions». Microsoft. 9 de dezembro de 2009
  10. ↑ «Native NFSv4 ACLs on Linux». Consultado em 4 de maio de 2010. Arquivado do original em 12 de outubro de 2008
  11. ↑ «NFSv4_ACLs – FreeBSD Wiki»
  12. ↑ «FreeNAS 9.1.1 Users Guide» (PDF). 2013. Arquivado do original (PDF) em 24 de setembro de 2015
  13. ↑ Gite, Vivek (3 de junho de 2010). «Apple OS X: Write Protect File From Command Line»
  14. ↑ «OpenVMS documentation». Consultado em 6 de junho de 2009. Arquivado do original em 5 de março de 2012
  15. ↑ «File Systems: Protection». CS322 Lecture Slides
  16. ↑ «Oracle Solaris ZFS Administration Guide» (PDF). Setembro de 2010
  17. ↑ «IBM Knowledge Center». Arquivado do original em 29 de junho de 2013
  18. ↑ «HarmonyOS Distributed File System Development Guide». Substack. LivingInHarmony Blog. 13 de março de 2024. Consultado em 13 de março de 2024
  19. ↑ «Definitions, 3.175 File Permission Bits». pubs.opengroup.org. 22 de julho de 2018. Consultado em 24 de junho de 2023
  20. ↑ Hatch, Bri (24 de abril de 2003). «Linux File Permission Confusion pt 2». Hacking Linux Exposed. Consultado em 6 de julho de 2011
  21. ↑ 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
  22. ↑ «Red Hat Enterprise Linux 7 System Administrator's Guide, 4.3.4 Creating Group Directories». Red Hat Customer Portal. Red Hat
Este artigo é emitido por Wikipédia. O texto é licenciado sob Creative Commons Attribution-Share Alike 4.0. Termos adicionais podem ser aplicados aos arquivos de mídia.