3.4. Permissões

No FreeBSD, todo arquivo e diretório tem um conjunto associado de permissões e vários utilitários estão disponíveis para visualizar e modificar essas permissões. É necessário entender como as permissões funcionam para garantir que os usuários consigam acessar os arquivos que precisam e não consigam acessar os arquivos usados pelo sistema operacional ou de propriedade de outros usuários.

Esta seção discute as permissões UNIX® tradicionais usadas no FreeBSD. Para um controle de acesso ao sistema de arquivos mais refinado, consulte Seção 13.9, “Listas de Controle de Acesso”.

No UNIX®, as permissões básicas são atribuídas usando três tipos de acesso: ler, escrever e executar. Esses tipos de acesso são usados para determinar o acesso do arquivo ao proprietário, ao grupo e a outros usuários do arquivo (todos os outros). As permissões de leitura, gravação e execução podem ser representadas como as letras r, w e x. Elas também podem ser representados como números binários, pois cada permissão está ativada ou desativada (0). Quando representada como um número, a ordem é sempre lida como rwx, onde r é ativado com o valor 4, w é ativado com o valor 2 e x é ativado com o valor 1.

A Tabela 4.1 resume as possíveis possibilidades numéricas e alfabéticas. Ao ler a coluna Listagem do Diretório, um - é usado para representar uma permissão que está desativada.

Tabela 3.2. Permissões UNIX®
ValorPermissãoListagem de diretório
0Sem leitura, sem escrita, sem execução---
1Sem leitura, sem escrita, execução--x
2Sem leitura, escrita, sem execução-w-
3Sem leitura, escrita, execução-wx
4Leitura, sem escrita, sem execuçãor--
5Leitura, sem escrita, execuçãor-x
6Leitura, escrita, sem execuçãorw-
7Leitura, escrita, execuçãorwx

Use o argumento -l com o ls(1) para exibir uma lista longa de diretórios que inclua uma coluna de informações sobre um permissões do arquivo para o proprietário, grupo e outros. Por exemplo, um ls -l em um diretório arbitrário pode mostrar:

% ls -l
total 530
-rw-r--r--  1 root  wheel     512 Sep  5 12:31 myfile
-rw-r--r--  1 root  wheel     512 Sep  5 12:31 otherfile
-rw-r--r--  1 root  wheel    7680 Sep  5 12:31 email.txt

O primeiro caractere (mais à esquerda) da primeira coluna indica se esse arquivo é um arquivo normal, um diretório, um dispositivo de caractere especial, um soquete ou qualquer outro dispositivo especial de pseudo-arquivo. Neste exemplo, o - indica um arquivo regular. Os próximos três caracteres, rw- neste exemplo, fornecem as permissões para o proprietário do arquivo. Os próximos três caracteres, r--, fornecem as permissões para o grupo ao qual o arquivo pertence. Os três últimos caracteres, r--, dão as permissões para o resto do mundo. Um traço significa que a permissão está desativada. Neste exemplo, as permissões são definidas para que o proprietário possa ler e gravar no arquivo, o grupo possa ler o arquivo e o resto do mundo só possa ler o arquivo. De acordo com a tabela acima, as permissões para este arquivo seriam 644, onde cada dígito representa uma das três partes da permissão do arquivo.

Como o sistema controla as permissões nos dispositivos? O FreeBSD trata a maioria dos dispositivos de hardware como um arquivo nos quais os programas podem abrir, ler e gravar dados. Esses arquivos de dispositivos especiais são armazenados em /dev/.

Diretórios também são tratados como arquivos. Eles tem permissões de leitura, gravação e execução. O bit executável de um diretório tem um significado ligeiramente diferente que nos arquivos. Quando um diretório é marcado como executável, isso significa que é possível mudar para esse diretório usando cd(1). Isso também significa que é possível acessar os arquivos dentro desse diretório, sujeito às permissões dos próprios arquivos.

Para executar uma listagem de diretórios, a permissão de leitura deve estar ativada no diretório. Para deletar um arquivo que se conhece o nome, é necessário ter permissões de escrita e execução no diretório que contém o arquivo.

Há mais bits de permissão, mas eles são usados principalmente em circunstâncias especiais, como binários setuid e diretórios fixos. Para obter mais informações sobre permissões de arquivos e como configurá-las, consulte chmod(1).

3.4.1. Permissões simbólicas

Contribuído por Tom Rhodes.

Permissões simbólicas usam caracteres em vez de valores octais para atribuir permissões a arquivos ou diretórios. Permissões simbólicas usam a sintaxe de (quem) (ação) (permissões), onde os seguintes valores estão disponíveis:

OpçãoLetraRepresenta
(quem)uUsuário
(quem)gGrupo
(quem)oOutros
(quem)aTodos (resto do mundo)
(açao)+Adiciona permissões
(açao)-Remove permissões
(açao)=Permissões definidas explicitamente
(permissões)rLeitura
(permissões)wEscrita
(permissões)xExecução
(permissões)tbit fixador
(permissões)sSet UID ou GID

Esses valores são usados com o chmod(1), mas com letras em vez de números. Por exemplo, o comando a seguir impediria que outros usuários acessassem FILE:

% chmod go= FILE

Uma lista separada por vírgula pode ser fornecida quando mais de um conjunto de alterações em um arquivo precisar ser feito. Por exemplo, o comando a seguir remove as permissões de gravação do grupo e resto do mundo no FILE e adiciona as permissões de execução para todos:

% chmod go-w,a+x FILE

3.4.2. Flags de arquivos no FreeBSD

Contribuído por Tom Rhodes.

Além das permissões de arquivo, o FreeBSD suporta o uso de flags de arquivo. Esses sinalizadores adicionam um nível a mais de segurança e controle sobre os arquivos, mas não nos diretórios. Com flags de arquivos, mesmo o root pode ser impedido de remover ou alterar arquivos.

Os sinalizadores de arquivo são modificados usando o chflags(1). Por exemplo, para ativar o sinalizador undeletable do sistema no arquivo file1, use o seguinte comando:

# chflags sunlink file1

Para desabilitar o sinalizador undeletable do sistema, coloque um no na frente do sunlink:

# chflags nosunlink file1

Para visualizar os sinalizadores de um arquivo, use -lo com o ls(1):

# ls -lo file1
-rw-r--r-- 1 trhodes trhodes sunlnk 0 Mar 1 05:54 file1

Vários flags de arquivo só podem ser adicionados ou removidos pelo usuário root. Em outros casos, o proprietário do arquivo pode definir seus sinalizadores. Consulte chflags(1) e chflags(2) para maiores informações.

3.4.3. As permissões setuid, setgid e sticky

Contribuído por Tom Rhodes.

Além das permissões já discutidas, existem três outras configurações específicas que todos os administradores devem conhecer. Eles são as permissões setuid, setgid e sticky.

Essas configurações são importantes para algumas operações UNIX®, pois fornecem funcionalidades normalmente não concedidas a usuários normais. Para compreendê-los, a diferença entre o ID real de usuário e o ID efetivo de usuário deve ser explicada.

O ID de usuário real é o UID que inicia ou é o dono do processo. O ID de usuário efetivo é o UID do usuário com o qual o processo é executado. Por exemplo, o passwd(1) é executado com o ID do usuário real quando um usuário altera sua senha. No entanto, para atualizar o banco de dados de senhas, o comando é executado como o ID efetivo do usuário root. Isso permite que os usuários alterem suas senhas sem ver um erro Permission Denied.

A permissão setuid pode ser definida prefixando um conjunto de permissões com o número quatro (4), conforme mostrado no exemplo a seguir:

# chmod 4755 suidexample.sh

As permissões em suidexample.sh agora se parecem com o seguinte:

-rwsr-xr-x   1 trhodes  trhodes    63 Aug 29 06:36 suidexample.sh

Observe que um s agora faz parte do conjunto de permissões designado para o proprietário do arquivo, substituindo o bit executável. Isso viabiliza utilitários que precisam de permissões elevadas, como o passwd(1).

Nota:

A opção nosuid mount(8) fará com que esses binários falhem silenciosamente sem alertar o usuário. Essa opção não é totalmente confiável, já que um wrapper nosuid pode contorná-la.

Para ver isso em tempo real, abra dois terminais. Em um deles, digite passwd como um usuário normal. Enquanto aguarda uma nova senha, verifique a tabela de processos e observe as informações de usuário do passwd(1):

No terminal A:

Changing local password for trhodes
Old Password:

No terminal B:

# ps aux | grep passwd
trhodes  5232  0.0  0.2  3420  1608   0  R+    2:10AM   0:00.00 grep passwd
root     5211  0.0  0.2  3620  1724   2  I+    2:09AM   0:00.01 passwd

Embora passwd(1) seja executado como um usuário normal, ele está usando o UID do root.

A permissão setgid executa a mesma função que a permissão setuid; exceto que altera as configurações do grupo. Quando um aplicativo ou utilitário é executado com essa configuração, ele recebe as permissões com base no grupo do arquivo, não no usuário que iniciou o processo.

Para definir a permissão setgid em um arquivo, execute o chmod(1) com dois (2) no início:

# chmod 2755 sgidexample.sh

Na listagem a seguir, observe que o s está agora no campo designado para as configurações de permissão do grupo:

-rwxr-sr-x   1 trhodes  trhodes    44 Aug 31 01:49 sgidexample.sh

Nota:

Nestes exemplos, mesmo que o shell script em questão seja um arquivo executável, ele não será executado com um EUID diferente ou um ID de usuário efetivo. Isso ocorre porque os shell scripts podem não acessar as chamadas de sistema setuid(2).

Os bits de permissão setuid e setgid podem diminuir a segurança do sistema, permitindo permissões elevadas. A terceira permissão especial, o sticky bit, pode fortalecer a segurança de um sistema.

Quando o sticky bit é definido em um diretório, ele permite a exclusão de arquivos apenas pelo proprietário do arquivo. Isso é útil para impedir a exclusão de arquivos em diretórios públicos, como /tmp, por usuários que não possuem o arquivo. Para utilizar essa permissão, use o um (1) no início das permissões:

# chmod 1777 /tmp

A permissão sticky bit será exibida como um t no final do conjunto de permissões:

# ls -al / | grep tmp
drwxrwxrwt  10 root  wheel         512 Aug 31 01:49 tmp

All FreeBSD documents are available for download at https://download.freebsd.org/ftp/doc/

Questions that are not answered by the documentation may be sent to <freebsd-questions@FreeBSD.org>.
Send questions about this document to <freebsd-doc@FreeBSD.org>.