Permissões no Linux (chown, chmod, SUID, GUID, sticky bit, ACL, umask)

Olá a todos. Esta é a tradução de um artigo do livro RedHat RHCSA RHCE 7 RedHat Enterprise Linux 7 EX200 e EX300.

Pessoalmente: Espero que o artigo seja útil não apenas para iniciantes, mas também ajude administradores mais experientes a organizar seus conhecimentos.

Então, vamos lá.

Permissões no Linux (chown, chmod, SUID, GUID, sticky bit, ACL, umask)

Para acessar arquivos no Linux, são utilizadas permissões. Essas permissões são atribuídas a três entidades: o proprietário do arquivo, o proprietário do grupo e um outro objeto (ou seja, todos os outros). Neste artigo, você aprenderá como aplicar permissões.

O artigo começa com uma visão geral dos conceitos básicos, seguida da discussão sobre permissões especiais (Special permissions) e listas de controle de acesso (ACL). No final deste artigo, será abordada a configuração de permissões padrão através do umask, bem como a gestão de atributos estendidos do usuário.

Gerenciamento de propriedade de arquivos

Antes de discutir permissões, você deve entender o papel do proprietário de arquivos e diretórios. A propriedade de arquivos e diretórios é crucial para trabalhar com permissões. Nesta seção, você primeiro aprenderá como visualizar o proprietário. Em seguida, você aprenderá como alterar o proprietário do grupo e do usuário de arquivos e diretórios.

Visualizando o proprietário de um arquivo ou diretório

No Linux, cada arquivo e cada diretório possuem dois proprietários: um usuário e um grupo proprietário.

Esses proprietários são estabelecidos no momento da criação do arquivo ou diretório. O usuário que cria um arquivo se torna o proprietário desse arquivo, e o grupo primário do qual esse mesmo usuário faz parte também se torna o proprietário desse arquivo. Para determinar se você, como usuário, possui acesso a um arquivo ou diretório, o shell verifica a propriedade deles.

Isso acontece na seguinte ordem:

  1. O shell verifica se você é o proprietário do arquivo ao qual deseja acessar. Se você for esse proprietário, você obtém as permissões e o shell para a verificação.
  2. Se você não for o proprietário do arquivo, o shell verificará se você é um membro do grupo que possui permissões sobre esse arquivo. Se você for membro desse grupo, você obterá acesso ao arquivo com as permissões configuradas para o grupo, e o shell interromperá a verificação.
  3. Se você não for nem um usuário nem o proprietário do grupo, você obterá os direitos de outros usuários (Other).

Para ver as atuais atribuições do proprietário, você pode usar o comando ls -l. Este comando mostra o usuário e o proprietário do grupo. Abaixo você pode ver as configurações do proprietário para diretórios no diretório /home.

[root@server1 home]# ls -l
total 8
drwx------. 3  bob            bob            74     Feb   6   10:13 bob
drwx------. 3  caroline       caroline       74     Feb   6   10:13 caroline
drwx------. 3  fozia          fozia          74     Feb   6   10:13 fozia
drwx------. 3  lara           lara           74     Feb   6   10:13 lara
drwx------. 5  lisa           lisa           4096   Feb   6   10:12 lisa
drwx------. 14 user           user           4096   Feb   5   10:35 user

Com o comando ls você pode mostrar o proprietário dos arquivos neste diretório. Às vezes, pode ser útil obter uma lista de todos os arquivos no sistema cujo proprietário é este usuário ou grupo. Para isso, você pode usar find. O argumento find -user pode ser usado para esse fim. Por exemplo, o seguinte comando mostra todos os arquivos cujo proprietário é o usuário linda:

find / -user linda

Você também pode usar find para encontrar arquivos cujo determinado grupo seja seu proprietário.

Por exemplo, o seguinte comando procura todos os arquivos pertencentes ao grupo tinham endereços de e-mail em domínios:

find / -group users

Mudando o proprietário

Para aplicar as permissões apropriadas, a primeira coisa a considerar é a propriedade. Para isso, existe o comando chown. A sintaxe deste comando não é difícil de entender:

chown quem o quê

Por exemplo, o seguinte comando muda o proprietário do diretório /home/account para o usuário linda:

chown linda /home/account

Time chown tem várias opções, uma das quais é especialmente útil: -R. Você pode imaginar o que ele faz, pois esta opção também está disponível para muitos outros comandos. Isso permite que você defina recursivamente o proprietário, o que permite que você defina o proprietário do diretório atual e de tudo que está abaixo dele. O seguinte comando muda o proprietário para o diretório /home e tudo que está abaixo dele para o usuário linda:

Agora os proprietários parecem assim:

[root@localhost ~]# ls -l /home
total 0
drwx------. 2 account account 62 Sep 25 21:41 account
drwx------. 2 lisa    lisa    62 Sep 25 21:42 lisa

Vamos executar:

[root@localhost ~]# chown -R lisa /home/account
[root@localhost ~]#

Agora o usuário lisa se tornou o proprietário do diretório account:

[root@localhost ~]# ls -l /home
total 0
drwx------. 2 lisa account 62 Sep 25 21:41 account
drwx------. 2 lisa lisa    62 Sep 25 21:42 lisa

Mudando o proprietário do grupo

Existem duas maneiras de mudar a propriedade do grupo. Você pode fazer isso usando chown, mas existe um comando especial chamado chgrp, que executa essa tarefa. Se você quiser usar o comando chown, use . ou : antes do nome do grupo.

O próximo comando altera o proprietário de um grupo /home/account para o grupo account:

chown .account /home/account

Você pode usar chown para alterar o proprietário do usuário e/ou do grupo de várias maneiras. Aqui estão alguns exemplos:

  • chown lisa myfile1 define o usuário lisa como proprietário do arquivo myfile1.
  • chown lisa.sales myfile define o usuário lisa como proprietário do arquivo myfile, assim como define o grupo sales como proprietário desse mesmo arquivo.
  • chown lisa:sales myfile o mesmo que o comando anterior.
  • chown .sales myfile define o grupo sales como proprietário do arquivo myfile sem alterar o proprietário do usuário.
  • chown :sales myfile o mesmo que o comando anterior.

Você pode usar o comando chgrp, para mudar o proprietário do grupo. Vamos considerar o seguinte exemplo, onde você pode usar chgrp para definir o proprietário do diretório account como o grupo sales:

chgrp .sales /home/account

Assim como no caso do chown, você pode usar a opção -R com chgrp, além de mudar recursivamente o proprietário do grupo.

Entendendo o proprietário padrão

Você pode ter notado que quando um usuário cria um arquivo, a propriedade padrão é aplicada.
O usuário que cria o arquivo automaticamente se torna o proprietário desse arquivo, e o grupo primário desse usuário automaticamente se torna o proprietário desse arquivo. Geralmente, esse é o grupo que está indicado no arquivo /etc/passwd como o grupo primário do usuário. No entanto, se o usuário for membro de vários grupos, ele pode alterar seu grupo primário efetivo.

Para mostrar o grupo primário efetivo atual, o usuário pode usar o comando grupos:

[root@server1 ~]# groups lisa
lisa : lisa account sales

Se o usuário atual linda quiser alterar seu grupo primário efetivo, ele usará o comando newgrp, seguido pelo nome do grupo que deseja estabelecer como seu novo grupo primário efetivo. Após usar o comando newgrp o grupo primário ficará ativo até que o usuário digite o comando sigreturn ou faça logout.

Abaixo está como o usuário linda usa esse comando, tornando o grupo sales seu grupo primário:

lisa@server1 ~]$ groups
lisa account sales
[lisa@server1 ~]$ newgrp sales
[lisa@server1 ~]$ groups
sales lisa account
[lisa@server1 ~]$ touch file1
[lisa@server1 ~]$ ls -l
total 0
-rw-r--r--. 1 lisa sales 0 Feb 6 10:06 file1

Após alterar o grupo primário ativo, todos os novos arquivos criados pelo usuário terão este grupo como proprietário. Para retornar à configuração original do grupo primário, utilize sigreturn.

Para poder usar o comando newgrp, o usuário deve ser membro do grupo que deseja usar como primário. Além disso, a senha do grupo pode ser usada para o grupo com o comando gpasswd. Se o usuário usar o comando newgrp, mas não for membro do grupo alvo, o shell solicitará a senha do grupo. Após digitar a senha correta do grupo, o novo grupo primário efetivo será estabelecido.

Gerenciamento de direitos primários

O sistema de permissões do Linux foi criado na década de 1970. Como as necessidades computacionais eram limitadas naquela época, o sistema básico de permissões era bastante restrito. Este sistema de permissões utiliza três permissões que podem ser aplicadas a arquivos e diretórios. Nesta seção, você aprenderá como usar e alterar essas permissões.

Entendendo os direitos de leitura, gravação e execução

As três permissões principais permitem que você leia, escreva e execute arquivos. O efeito dessas permissões varia ao serem aplicadas a arquivos ou diretórios. Relativo a um arquivo, a permissão de leitura dá a você o direito de abrir o arquivo para leitura. Portanto, você pode ler seu conteúdo, mas isso significa que seu computador pode abrir o arquivo para realizar ações com ele.

Um arquivo de programa que precisa acessar uma biblioteca, por exemplo, deve ter acesso de leitura a essa biblioteca. Isso implica que a permissão de leitura é a permissão mais básica que você precisa para trabalhar com arquivos.

Relativo a um diretório, a leitura permite visualizar o conteúdo desse diretório. Você deve saber que essa permissão não permite que você leia os arquivos dentro do diretório. O sistema de permissões do Linux não reconhece herança, e a única maneira de ler um arquivo é usando permissões de leitura para esse arquivo.

Como você provavelmente pode adivinhar, a permissão de escrita, se aplicada a um arquivo, permite escrever no arquivo. Em outras palavras, permite modificar o conteúdo de arquivos existentes. Contudo, ela não permite criar ou excluir novos arquivos ou alterar as permissões de acesso ao arquivo. Para isso, você precisa conceder a permissão de escrita ao diretório onde deseja criar o arquivo. Nos diretórios, essa permissão também permite criar e excluir novas subpastas.

A permissão de execução é o que você precisa para executar um arquivo. Ela nunca será definida por padrão, tornando o Linux praticamente impermeável a vírus. Apenas alguém com permissões de escrita no diretório pode aplicar a permissão de execução.

Abaixo, resumimos a utilização das permissões básicas:

Permissões no Linux (chown, chmod, SUID, GUID, sticky bit, ACL, umask)

Uso do chmod

Para gerenciar permissões, usa-se o comando chmod. Ao usar chmod , você pode definir permissões para o usuário (user), grupo (group) e outros (other). Você pode usar esse comando em dois modos: modo relativo e modo absoluto. No modo absoluto, três dígitos são usados para definir as permissões básicas.

Permissões no Linux (chown, chmod, SUID, GUID, sticky bit, ACL, umask)

Ao configurar permissões, calcule o valor necessário. Se você deseja estabelecer leitura, escrita e execução para o usuário, leitura e execução para o grupo, bem como leitura e execução para outros no arquivo /somefile, então você utiliza o seguinte comando chmod:

chmod 755 /somefile

Quando você usa chmod dessa forma, todas as permissões atuais são substituídas pelas permissões que você definiu.

Se você deseja alterar as permissões em relação às permissões atuais, pode usar chmod no modo relativo. Ao usar chmod no modo relativo, você trabalha com três indicadores para indicar o que deseja fazer:

  1. Primeiro, você especifica para quem deseja alterar as permissões. Para isso, você pode escolher entre usuário (u), grupo ((para particionar o disco em MBR ou GPT).) e outros (o).
  2. . Em seguida, você usa um operador para adicionar ou remover permissões do modo atual ou defini-las absolutamente.
  3. Por fim, você usa r, w e x, para especificar quais permissões você deseja definir.

Ao alterar permissões em modo relativo, você pode omitir a parte 'quem' para adicionar ou remover permissões para todos os objetos. Por exemplo, este comando concede permissão de execução a todos os usuários:

chmod +x somefile

Ao trabalhar em modo relativo, você também pode usar comandos mais complexos. Por exemplo, este comando adiciona permissão de gravação ao grupo e remove a leitura para outros:

chmod g+w,o-r somefile

Ao usar chmod -R o+rx /data você está concedendo permissão de execução para todos os diretórios, bem como para os arquivos no diretório /data. Para conceder permissão de execução apenas para diretórios e não para arquivos, use chmod -R o+ rX /data.

A letra maiúscula X garante que arquivos não obtenham permissão de execução, a menos que o arquivo já tenha concedido permissão de execução a alguns objetos. Isso torna X uma forma mais inteligente de lidar com permissões de execução; isso evitará a concessão dessa permissão a arquivos onde não é necessária.

Permissões avançadas

Além das permissões básicas que você acabou de ler, o Linux também possui um conjunto de permissões avançadas. Essas não são as permissões que você define por padrão, mas às vezes elas fornecem um complemento útil. Nesta seção, você aprenderá o que elas são e como configurá-las.

Entendendo as permissões avançadas SUID, GUID e sticky bit

Existem três permissões avançadas. A primeira delas é a permissão de definir o identificador de usuário (SUID). Em algumas situações especiais, você pode aplicar essa permissão a arquivos executáveis. Por padrão, o usuário que executa um arquivo executável o faz com suas próprias permissões.

Para usuários comuns, isso geralmente significa que o uso do programa é limitado. No entanto, em alguns casos, o usuário necessita de permissões especiais, apenas para realizar uma determinada tarefa.

Vamos considerar, por exemplo, a situação em que um usuário precisa alterar sua senha. Para isso, o usuário deve gravar sua nova senha no arquivo /etc/shadow. No entanto, esse arquivo não está acessível para escrita a usuários que não têm acesso root:

root@hnl ~]# ls -l /etc/shadow
----------. 1 root root 1184 Apr 30 16:54 /etc/shadow

A permissão SUID oferece uma solução para esse problema. No utilitário /usr/bin/passwd, essa permissão é aplicada por padrão. Isso significa que, ao alterar a senha, o usuário temporariamente recebe privilégios de root, o que permite que ele escreva no arquivo /etc/shadow. Você pode visualizar a permissão SUID em ls -l como s na posição onde você normalmente esperaria ver x para permissões de usuários:

[root@hnl ~]# ls -l /usr/bin/passwd
-rwsr-xr-x. 1 root root 32680 Jan 28 2010 /usr/bin/passwd

A permissão SUID pode parecer útil (e em alguns casos realmente é), mas ao mesmo tempo é potencialmente perigosa. Se aplicada incorretamente, você pode acidentalmente conceder privilégios de root. Portanto, recomendo usá-la apenas com a máxima cautela.

A maioria dos administradores nunca precisará usá-la; você a verá apenas em alguns arquivos onde o sistema operacional deve configurá-la por padrão.

A segunda permissão especial é o identificador de grupo (SGID). Essa permissão tem dois efeitos. Quando aplicada a um arquivo executável, ela concede ao usuário que executa o arquivo as permissões do proprietário do grupo desse arquivo. Assim, o SGID pode fazer mais ou menos o mesmo que o SUID. No entanto, para esse propósito, o SGID é praticamente não utilizado.

Assim como no caso da permissão SUID, o SGID é aplicado a alguns arquivos do sistema como configuração padrão.

Quando aplicada a um diretório, o SGID pode ser útil, pois você pode usá-lo para definir o proprietário do grupo padrão para arquivos e subdiretórios criados dentro desse diretório. Por padrão, quando um usuário cria um arquivo, seu grupo primário efetivo é definido como o proprietário do grupo desse arquivo.

Isso nem sempre é muito útil, especialmente porque os usuários do Red Hat/CentOS têm como grupo primário um grupo com o mesmo nome que o usuário, do qual o usuário é o único membro. Assim, por padrão, os arquivos que o usuário cria serão grupais para acesso geral.

Imagine a situação em que os usuários linda e lori trabalham no setor de contabilidade e são membros do grupo accountPor padrão, esses usuários são membros de um grupo privado, do qual são os únicos integrantes. No entanto, ambos os usuários são membros do grupo account, mas também como um parâmetro do grupo secundário.

A situação padrão é que, quando qualquer um desses usuários cria um arquivo, o grupo principal se torna o proprietário. Portanto, por padrão, linda não pode acessar os arquivos criados por lori, e vice-versa. Porém, se você criar um diretório compartilhado do grupo (digamos, /groups/account) e garantir que a permissão SGID seja aplicada a esse diretório e que a conta do grupo seja definida como proprietário do grupo desse diretório, todos os arquivos criados nesse diretório e em todos os seus subdiretórios também terão o grupo account como o proprietário do grupo por padrão.

Por essa razão, a permissão SGID é uma permissão muito útil para configurar em diretórios de grupos compartilhados.

A permissão SGID é exibida na saída ls -l como s na posição onde você normalmente encontra a permissão de execução do grupo:

[root@hnl data]# ls -ld account
drwxr-sr-x. 2 root account 4096 Abr 30 21:28 account

O terceiro das permissões especiais é o sticky bit. Essa permissão é útil para proteger arquivos contra exclusão acidental em um ambiente onde vários usuários têm permissões de gravação em um mesmo diretório. Se o sticky bit estiver aplicado, um usuário pode deletar um arquivo apenas se for o proprietário do arquivo ou do diretório onde o arquivo está contido. Por essa razão, ele é aplicado como permissão padrão para o diretório /tmp e pode ser útil também para diretórios de grupos compartilhados.

Sem o sticky bit, se um usuário pode criar arquivos em um diretório, ele também pode excluir arquivos desse diretório. Em um ambiente de grupo público, isso pode ser irritante. Imagine usuários como linda e lori, que ambos têm permissões para gravação no diretório /data/account e obtêm essas permissões devido à sua participação no grupo account. Portanto, linda pode excluir arquivos criados por lori, e vice-versa.

Quando você aplica o sticky bit, um usuário pode excluir arquivos apenas se uma das seguintes condições for atendida:

  • O usuário é o proprietário do arquivo;
  • O usuário é o proprietário do diretório onde o arquivo está localizado.

Ao usar ls -l, você pode ver o sticky bit como t na posição onde você geralmente vê permissões de execução para outros:

[root@hnl data]# ls -ld account/
drwxr-sr-t. 2 root account 4096 Abr 30 21:28 account/

Aplicação de permissões avançadas

Para aplicar SUID, SGID e sticky bit, você também pode usar chmod. SUID tem um valor numérico de 4, SGID tem um valor numérico de 2, e sticky bit tem um valor numérico de 1.

Se você deseja aplicar essas permissões, precisará adicionar um argumento de quatro dígitos em chmod, o primeiro dígito se refere às permissões especiais. A linha seguinte, por exemplo, adicionará a permissão SGID ao diretório e definirá rwx para o usuário e rx para o grupo e outros:

chmod 2755 /somedir

Isso é bastante impraticável se você precisar ver as permissões atuais definidas antes de trabalhar com chmod em modo absoluto. (Você corre o risco de sobrescrever as permissões se não fizer isso.) Portanto, recomendo trabalhar em modo relativo se precisar aplicar qualquer uma das permissões especiais:

  1. Para SUID, use chmod u+s.
  2. Para SGID, use chmod g+s.
  3. Para sticky bit, use chmod +t, e então o nome do arquivo ou diretório para o qual você deseja definir as permissões.

A tabela resume tudo o que é importante saber sobre a gestão de permissões especiais.

Permissões no Linux (chown, chmod, SUID, GUID, sticky bit, ACL, umask)

Exemplo de trabalho com permissões especiais

Neste exemplo, você usará permissões especiais para facilitar o compartilhamento de arquivos entre membros do grupo em um diretório compartilhado. Você atribui o bit de ID do grupo e também o sticky bit, e verá que após sua aplicação são adicionadas funcionalidades que facilitam a colaboração entre os membros do grupo.

  1. Abra o terminal como o usuário linda. Você pode criar um usuário com o comando useradd linda, adicione uma senha passwd linda.
  2. Crie o diretório /data e o subdiretório /data/sales com o comando mkdir -p /data/sales. Execute cd /data/sales, para mudar para o diretório sales. Execute touch linda1 e touch linda2, para criar dois arquivos vazios, cuja proprietária é linda.
  3. Execute su — lisa para trocar o usuário atual para o usuário lisa, que também é membro do grupo sales.
  4. Execute cd /data/sales e a partir deste diretório execute ls -l. Você verá os dois arquivos que foram criados pela usuária linda e pertencem ao grupo linda. Execute rm -f linda*. Isso removerá os dois arquivos.
  5. Execute touch lisa1 e touch lisa2, para criar dois arquivos que pertencem ao usuário lisa.
  6. Execute su — para elevar seus privilégios ao nível root.
  7. Execute chmod g+s,o+t /data/sales, para definir o bit do identificador de grupo (GUID) e também o sticky bit no diretório do grupo compartilhado.
  8. Execute su — linda. Em seguida, execute touch linda3 e touch linda4. Agora você deve ver que os dois arquivos que você criou pertencem ao grupo sales, que é o proprietário do diretório /data/sales.
  9. Execute rm -rf lisa*. O sticky bit impede a remoção desses arquivos pelo usuário linda, uma vez que você não é o proprietário desses arquivos. Note que, se o usuário linda for o proprietário do diretório /data/sales, ele ainda poderá remover esses arquivos!

Gerenciamento de ACL (setfacl, getfacl) no Linux

Mesmo que as permissões estendidas discutidas acima adicionem funcionalidades úteis ao modo como o Linux trabalha com permissões, isso não permite que você conceda permissões a mais de um usuário ou grupo em um único arquivo.

As listas de controle de acesso oferecem essa funcionalidade. Além disso, permitem que os administradores definam permissões padrão de maneira complexa, em que as permissões definidas podem variar em diferentes diretórios.

Entendendo ACL

Embora a subsistema ACL adicione excelentes funcionalidades ao seu servidor, ele possui uma desvantagem: nem todas as utilidades o suportam. Como resultado, você pode perder as configurações de ACL ao copiar ou mover arquivos, e o software de backup pode não fazer backup das configurações de ACL.

A utilidade tar não suporta ACL. Para garantir que as configurações de ACL não sejam perdidas durante a criação do backup, use star em vez de tar. star funciona com os mesmos parâmetros que o tar; ele simplesmente adiciona suporte para configurações de ACL.

Você também pode fazer backup das ACL usando getfacl, que pode ser restaurado com o comando setfacl. Para fazer um backup, use getfacl -R /directory > file.acls. Para restaurar as configurações a partir do arquivo de backup, use setfacl —restore=file.acl.

A falta de suporte por algumas ferramentas não deve ser um problema. As listas ACL geralmente são aplicadas a diretórios como uma medida estrutural, e não a arquivos individuais.
Portanto, haverá poucos deles, apenas alguns aplicados em locais inteligentes do sistema de arquivos. Assim, restaurar as listas ACL originais com as quais você trabalhou é relativamente fácil, mesmo que seu software de backup não as suporte.

Preparando o sistema de arquivos para ACL

Antes de começar a trabalhar com ACL, pode ser necessário preparar o sistema de arquivos para suportar ACL. Como os metadados do sistema de arquivos precisam ser expandidos, nem sempre há suporte por padrão para ACL no sistema de arquivos. Se, ao configurar listas ACL para o sistema de arquivos, você receber a mensagem "operação não suportada", pode ser que seu sistema de arquivos não tenha suporte a ACL.

Para corrigir isso, você precisa adicionar a opção acl mount no arquivo /etc/fstab, para que o sistema de arquivos seja montado com suporte a ACL por padrão.

Alterando e visualizando configurações de ACL com setfacl e getfacl

Para definir ACL, você precisa do comando setfacl. Para ver as configurações atuais de ACL, você precisa do getfacl. O comando ls -l não exibe quaisquer ACL existentes; simplesmente mostra + após a lista de permissões, que indica que listas ACL estão sendo aplicadas ao arquivo.

Antes de configurar listas ACL, é sempre útil mostrar as configurações atuais de ACL com getfacl. Abaixo, no exemplo, você pode ver as permissões atuais, conforme mostrado com ls -l, bem como mostrado com getfacl. Se você olhar de perto, verá que as informações mostradas são exatamente as mesmas.

[root@server1 \/]# ls -ld \/dir\ndrwxr-xr-x. 2 root root 6 Fev 6 11:28 \/dir
[root@server1 \/]# getfacl \/dir
getfacl: Removendo o ' \/' inicial dos nomes de caminho absoluto
# arquivo: dir
# proprietário: root
# grupo: root
user::rwx
group::r-x
other::r-x

Como resultado da execução do comando getfacl abaixo, é visível que as permissões são exibidas para três objetos diferentes: usuário, grupo e outros. Agora, vamos adicionar um ACL para conceder permissões de leitura e execução ao grupo sales. O comando para isso é setfacl -m g:sales:rx \/dir. Neste comando, -m indica que as configurações atuais de ACL precisam ser alteradas. Depois disso, g:sales:rx informa ao comando para definir ACL para leitura e execução (rx) para o grupo ((para particionar o disco em MBR ou GPT).) sales. Abaixo você pode ver como o comando se parece, bem como a saída do comando getfacl após a alteração das configurações atuais de ACL.

[root@server1 \/]# setfacl -m g:sales:rx \/dir
[root@server1 \/]# getfacl \/dir
getfacl: Removendo o ' \/' inicial dos nomes de caminho absoluto
# arquivo: dir
# proprietário: root
# grupo: root
user::rwx
group::r-x
group:sales:r-x
mask::r-x
other::r-x

Agora que você entende como configurar um ACL em grupo, é fácil entender o ACL para usuários e outros usuários. Por exemplo, o comando setfacl -m u:linda:rwx /data concede permissões ao usuário linda no diretório /data, sem torná-lo proprietário e sem alterar a designação do proprietário atual.

Time setfacl possui muitas funcionalidades e opções. Uma opção em particular é especialmente importante, o parâmetro -R. Se usado, essa opção aplica a configuração do ACL a todos os arquivos e subdiretórios que atualmente existem no diretório onde você está configurando o ACL. Recomenda-se sempre usar essa opção ao modificar listas de ACL para diretórios existentes.

Trabalhando com ACL padrão

Uma das vantagens de usar listas de ACL é que você pode conceder permissões a múltiplos usuários ou grupos em um diretório. Outra vantagem é que você pode habilitar a herança ao trabalhar com ACL padrão.

Ao definir um ACL padrão, você determinará as permissões que serão aplicadas a todos os novos itens criados no diretório. Lembre-se de que o ACL padrão não altera as permissões para arquivos e subdiretórios existentes. Para alterá-los, você precisa adicionar um ACL normal!

É importante saber disso. Se você deseja usar ACL para configurar o acesso de múltiplos usuários ou grupos a um mesmo diretório, deve definir o ACL duas vezes. Primeiro, use setfacl -R -m, para alterar o ACL dos arquivos atuais. Em seguida, use setfacl -m d:, para cuidar de todos os novos itens que também serão criados.

Para definir um ACL padrão, você só precisa adicionar a opção d após a opção -m (! a ordem é importante!). Portanto, use setfacl -m d:g:sales:rx /data, se você quiser que o grupo de vendas leia e execute tudo que for criado no diretório /data.

Ao usar listas de ACL padrão, pode ser útil também definir ACL para outros. Normalmente, isso não faz muito sentido, pois você também pode alterar as permissões para outros usando chmod. No entanto, o que você não pode fazer com ajuda de chmod, isso indica as permissões que devem ser concedidas a outros usuários para cada novo arquivo que for criado. Se você não quiser que outros tenham permissões em qualquer coisa criada em /data, por exemplo, use setfacl -m d:o::- /data.

As ACL e as permissões normais nem sempre são integradas de maneira eficaz. Problemas podem surgir se você aplicou uma ACL padrão ao diretório e, em seguida, elementos foram adicionados a esse diretório, e depois você tenta alterar as permissões normais. As alterações aplicadas às permissões normais não serão bem refletidas na revisão da ACL. Para evitar problemas, primeiro defina as permissões normais e, em seguida, estabeleça a ACL padrão (e, depois disso, evite alterá-las novamente).

Exemplo de gerenciamento de permissões avançadas usando ACL

Neste exemplo, você continuará trabalhando com os diretórios /data/account e /data/sales, que você criou anteriormente. Nos exemplos anteriores, você garantiu que o grupo sales tinha permissões em /data/sales e o grupo account tinha permissões em /data/account.

Primeiro, certifique-se de que o grupo account recebe permissões de leitura no diretório /data/sales, enquanto o grupo sales obtém permissões de leitura no diretório /data/account.

Em seguida, você define listas ACL padrão para garantir que todas as novas permissões para todos os novos arquivos sejam configuradas corretamente.

  1. Abra o terminal.
  2. Execute setfacl -m g:account:rx /data/sales e setfacl -m g:sales:rx /data/account.
  3. Execute getfacl, para garantir que as permissões de acesso foram configuradas como desejado.
  4. Execute setfacl -m d:g:account:rwx,g:sales:rx /data/sales, para definir ACL padrão para o diretório sales.
  5. Adicione ACL padrão para o diretório /data/account, usando setfacl -m d:g:sales:rwx,g:account:rx /data/account.
  6. Certifique-se de que as configurações de ACL estão efetivas adicionando um novo arquivo em /data/sales. Execute touch /data/sales/newfile e execute getfacl /data/sales/newfile para verificar as permissões atuais.

Definindo permissões padrão com umask

Acima, você aprendeu como trabalhar com ACL padrão. Se você não estiver usando ACL, há um parâmetro de shell que define as permissões padrão que você receberá: umask (máscara reversa). Nesta seção, você aprenderá como alterar as permissões padrão usando umask.

Você provavelmente notou que, ao criar um novo arquivo, algumas permissões padrão são atribuídas. Essas permissões são determinadas pela configuração. umask. Este parâmetro de shell é aplicado a todos os usuários ao fazer login no sistema. No parâmetro umask é utilizado um valor numérico que é subtraído das permissões máximas que podem ser automaticamente atribuídas a um arquivo; a configuração máxima para arquivos é 666, e para diretórios é 777.

No entanto, algumas exceções se aplicam a esta regra. Você pode encontrar uma visão geral completa das configurações umask na tabela abaixo.

Dos números utilizados em umask, assim como no caso de argumentos numéricos para o comando chmod, o primeiro número se refere às permissões do usuário, o segundo número se refere às permissões do grupo, e o último se refere às permissões padrão definidas para outros. O valor umask padrão 022 fornece 644 para todos os novos arquivos e 755 para todos os novos diretórios criados no seu servidor.

Uma visão geral completa de todos os valores numéricos umask e seus resultados está na tabela abaixo.

Permissões no Linux (chown, chmod, SUID, GUID, sticky bit, ACL, umask)

Uma maneira simples de ver como o parâmetro umask funciona é a seguinte: comece com as permissões padrão para arquivo definidas em 666 e subtraia o umask para obter as permissões efetivas. Faça o mesmo para o diretório e suas permissões padrão 777.

Existem duas maneiras de alterar a configuração umask: para todos os usuários e para usuários individuais. Se você quiser definir o umask para todos os usuários, deve garantir que o parâmetro umask seja considerado ao executar arquivos de ambiente de shell, conforme indicado em /etc/profile. A abordagem correta é criar um script de shell chamado umask.sh no diretório /etc/profile.d e indicar o umask que você deseja usar neste script de shell. Se o umask for alterado neste arquivo, ele se aplica a todos os usuários após o login no servidor.

Uma alternativa para configurar o umask via /etc/profile e arquivos relacionados, onde ele é aplicado a todos os usuários que fazem login, é alterar as configurações do umask em um arquivo chamado .profile, que é criado no diretório home de cada usuário.

As configurações aplicadas neste arquivo se aplicam apenas a um usuário individual; portanto, este é um bom método se você precisar de mais detalhamento. Pessoalmente, gosto dessa funcionalidade para mudar o valor padrão do umask para o usuário root para 027, enquanto os usuários comuns trabalham com umask padrão 022.

Trabalhando com atributos estendidos do usuário

Esta é a seção final sobre permissões no Linux.

Ao trabalhar com permissões, sempre existe uma relação entre o objeto do usuário ou do grupo e as permissões que esses objetos de usuário ou grupo possuem para um arquivo ou diretório. Um método alternativo de proteger arquivos em um servidor Linux é trabalhar com atributos.
Os atributos funcionam independentemente do usuário que acessa o arquivo.

Assim como no caso do ACL, pode ser necessário ativar a opção mount.

user_xattr . Se você receber a mensagem "operation not supported" ao trabalhar com atributos estendidos do usuário, certifique-se de definir a opçãono arquivo /etc/fstab. mount Muitos atributos estão documentados. Alguns atributos estão disponíveis, mas ainda não implementados. Não os utilize; eles não trarão benefícios.

Abaixo estão os atributos mais úteis que você pode aplicar:

Este atributo garante que o tempo de acesso ao arquivo não seja alterado.

A Normalmente, cada vez que um arquivo é aberto, o tempo de acesso deve ser registrado nos metadados do arquivo. Isso impacta negativamente a performance; portanto, para arquivos que são acessados regularmente, o atributo
pode ser usado para desativar essa funcionalidade. A Este atributo permite adicionar, mas não excluir um arquivo.

a Se você estiver usando um sistema de arquivos que suporta compressão a nível de volume, este atributo garante que o arquivo seja comprimido na primeira vez que o mecanismo de compressão for ativado.

c Este atributo garante que as alterações nos arquivos sejam gravadas no disco imediatamente, em vez de ser armazenadas primeiro em cache. Este é um atributo útil para arquivos de banco de dados importantes, garantindo que não sejam perdidos entre o cache de arquivos e o disco rígido.

D Este atributo garante que o arquivo não seja salvo em backups onde a ferramenta de backup é utilizada.

d Este atributo ativa a indexação para o diretório em que está habilitado. Isso fornece acesso mais rápido aos arquivos para sistemas de arquivos primitivos, como o Ext3, que não utilizam um banco de dados B-tree para acesso rápido aos arquivos.

I Este atributo inclui a indexação para o diretório em que está ativado. Isso proporciona acesso mais rápido aos arquivos para sistemas de arquivos primitivos, como o Ext3, que não usam um banco de dados B-tree para acesso rápido aos arquivos.

i Este atributo torna o arquivo imutável. Consequentemente, não é possível fazer alterações no arquivo, o que é útil para arquivos que precisam de proteção adicional.

j Este atributo garante que, no sistema de arquivos ext3, o arquivo é primeiro gravado no log e depois nos blocos de dados do disco rígido.

s Sobrescrever blocos onde o arquivo foi salvo com 0 após a exclusão do arquivo. Isso garante que a recuperação do arquivo não seja possível depois que ele tenha sido excluído.

u Este atributo mantém informações sobre a exclusão. Isso permite o desenvolvimento de uma utilidade que trabalha com essas informações para recuperar arquivos excluídos.

Se você quiser aplicar atributos, pode usar o comando chattr. Por exemplo, use chattr +s somefile, para aplicar os atributos ao somefile. Precisa remover o atributo? Então use chattr -s somefile, e ele será removido. Para obter uma visão geral de todos os atributos atualmente aplicados, use o comando lsattr.

Resumo

Neste artigo, você aprendeu a trabalhar com permissões. Você leu sobre as três permissões básicas, permissões estendidas e como aplicar listas ACL no sistema de arquivos. Você também aprendeu como usar o parâmetro umask para aplicar permissões padrão. No final deste artigo, você aprendeu a usar atributos estendidos do usuário para aplicar um nível adicional de segurança ao sistema de arquivos.

Se você gostou desta tradução, por favor, deixe um comentário. Isso me dará mais motivação para fazer traduções úteis.

No artigo, corrigi alguns erros de digitação e gramaticais. Reduzi alguns parágrafos longos em partes menores para facilitar a leitura.

Em vez de "Apenas alguém com privilégios administrativos no diretório pode aplicar a permissão de execução.", eu corrigi para "Apenas alguém com permissão de gravação no diretório pode aplicar a permissão de execução.", o que é mais correto.

Obrigado pelos comentários berez.

Substituí:
Se você não é o proprietário do usuário, o shell irá verificar se você é um membro do grupo que também é chamado de grupo do arquivo.

Para:
Se você não for o proprietário do arquivo, o shell verificará se você é um membro do grupo que possui permissões sobre esse arquivo. Se você for membro desse grupo, você obterá acesso ao arquivo com as permissões configuradas para o grupo, e o shell interromperá a verificação.

Obrigado pela observação CryptoPirate

Fonte: habr.com

Compre hospedagem confiável para sites com proteção contra DDoS, servidores VPS VDS 🔥 Compre hospedagem confiável para sites com proteção contra DDoS, servidores VPS VDS | ProHoster