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, posteriormente codificada pelo POSIX e é utilizada no Linux. 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).

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. Arquivos podem ser compartilhados entre usuários no mesmo projeto; arquivos compartilhados são atribuídos ao número de programador zero. 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.

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.

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

TENEX

Um usuário no TENEX pertence a um conjunto de grupos.

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.

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.

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. Não havia noção de grupos. Isso continuou até a terceira edição (v3); 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; 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.

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 e ext4.

O FreeBSD suporta ACLs POSIX.1e em UFS, e ACLs NFSv4 em UFS e ZFS.

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.

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. ACLs são suportadas no VMS 4.0 e posteriores.

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.

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

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.

Permissões POSIX tradicionais

Tradicionalmente, permissões de arquivos em um sistema de arquivos baseado em Unix são definidas pelo POSIX.1. 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.