Compreender os bits de modo nos Arquivos NetApp do Azure
As permissões de acesso a arquivos no NFS limitam o que os usuários e grupos podem fazer quando um volume NAS é montado. Os bits de modo são um recurso importante das permissões de arquivo NFS nos Arquivos NetApp do Azure.
Bits do modo NFS
As permissões de bit de modo no NFS fornecem permissões básicas para arquivos e pastas, usando uma representação numérica padrão de controles de acesso. Os bits de modo podem ser usados com NFSv3 ou NFSv4.1, mas os bits de modo são a opção padrão para proteger NFSv3, conforme definido no RFC-1813. A tabela a seguir mostra como esses valores numéricos correspondem aos controles de acesso.
| Modo de bit numérico |
|---|
| 1 – Executar (x) |
| 2 – Escrever (W) |
| 3 – Gravação/execução (wx) |
| 4 – Ler (R) |
| 5 – Ler/Executar (Rx) |
| 6 – Leitura/Escrita (RW) |
| 7 – Leitura/Gravação/Execução (RWX) |
Os valores numéricos são aplicados a diferentes segmentos de um controle de acesso: proprietário, grupo e todos os outros, o que significa que não há controles de acesso de usuário granulares para NFSv3 básico. A imagem a seguir mostra um exemplo de como um controle de acesso de bit de modo pode ser construído para uso com um objeto NFSv3.
O Azure NetApp Files não suporta ACLs POSIX. Assim, ACLs granulares só são possíveis com NFSv3 ao usar um volume de estilo de segurança NTFS com mapeamentos de nome UNIX para Windows válidos por meio de um serviço de nomes, como o LDAP do Ative Directory. Como alternativa, você pode usar NFSv4.1 com Arquivos NetApp do Azure e ACLs NFSv4.1.
A tabela a seguir compara a granularidade de permissão entre bits de modo NFSv3 e ACLs NFSv4.x.
| Bits do modo NFSv3 | NFSv4.x ACLs |
|---|---|
|
|
Para obter mais informações, consulte Compreender ACLs de listas de controle de acesso NFSv4.x.
Pedaços pegajosos, setuid e setgid
Ao usar bits de modo com montagens NFS, a propriedade de arquivos e pastas é baseada no uid e do usuário que criou os arquivos e gid pastas. Além disso, quando um processo é executado, ele é executado como o usuário que o iniciou e, portanto, teria as permissões correspondentes. Com permissões especiais (como setuid, , setgidbit pegajoso), esse comportamento pode ser controlado.
Setuid
O setuid bit é designado por um "s" na parte de execução do bit proprietário de uma permissão. O setuid bit permite que um arquivo executável seja executado como o proprietário do arquivo em vez de como o usuário tentando executar o arquivo. Por exemplo, o aplicativo tem o bit ativado por padrão, portanto, o /bin/passwd setuid aplicativo é executado como root quando um usuário tenta alterar sua senha.
# ls -la /bin/passwd
-rwsr-xr-x 1 root root 68208 Nov 29 2022 /bin/passwd
Se o setuid bit for removido, a funcionalidade de alteração de senha não funcionará corretamente.
# ls -la /bin/passwd
-rwxr-xr-x 1 root root 68208 Nov 29 2022 /bin/passwd
user2@parisi-ubuntu:/mnt$ passwd
Changing password for user2.
Current password:
New password:
Retype new password:
passwd: Authentication token manipulation error
passwd: password unchanged
Quando o bit é restaurado, o aplicativo passwd é executado como o proprietário (raiz) e funciona corretamente, mas apenas para o usuário que executa o setuid comando passwd.
# chmod u+s /bin/passwd
# ls -la /bin/passwd
-rwsr-xr-x 1 root root 68208 Nov 29 2022 /bin/passwd
# su user2
user2@parisi-ubuntu:/mnt$ passwd user1
passwd: You may not view or modify password information for user1.
user2@parisi-ubuntu:/mnt$ passwd
Changing password for user2.
Current password:
New password:
Retype new password:
passwd: password updated successfully
Setuid não tem efeito sobre diretórios.
Setgid
O setgid bit pode ser usado em arquivos e diretórios.
Com diretórios, setgid pode ser usado como uma maneira de herdar o grupo proprietário para arquivos e pastas criados abaixo do diretório pai com o bit definido. Como setuid, o bit executável é alterado para um "s" ou um "S".
Nota
Capital "S" significa que o bit executável não foi definido, como se as permissões no diretório são "6" ou "rw".
Por exemplo:
# chmod g+s testdir
# ls -la | grep testdir
drwxrwSrw- 2 user1 group1 4096 Oct 11 16:34 testdir
# who
root ttyS0 2023-10-11 16:28
# touch testdir/file
# ls -la testdir
total 8
drwxrwSrw- 2 user1 group1 4096 Oct 11 17:09 .
drwxrwxrwx 5 root root 4096 Oct 11 16:37 ..
-rw-r--r-- 1 root group1 0 Oct 11 17:09 file
Para arquivos, setgid se comporta de forma semelhante a setuid—executáveis executados usando as permissões de grupo do proprietário do grupo. Se um usuário estiver no grupo proprietário, esse usuário terá acesso para executar o executável quando setgid estiver definido. Se não estiverem no grupo, não terão acesso. Por exemplo, se um administrador quiser limitar quais usuários podem executar o mkdir comando em um cliente, ele pode usar setgid.
Normalmente, /bin/mkdir tem 755 permissões com propriedade raiz. Isso significa que qualquer pessoa pode executar mkdir em um cliente.
# ls -la /bin/mkdir
-rwxr-xr-x 1 root root 88408 Sep 5 2019 /bin/mkdir
Para modificar o comportamento para limitar quais usuários podem executar o comando, altere o grupo proprietário do mkdir aplicativo, altere as permissões para /bin/mkdir 750 e adicione o mkdir bit setgid ao mkdir.
# chgrp group1 /bin/mkdir
# chmod g+s /bin/mkdir
# chmod 750 /bin/mkdir
# ls -la /bin/mkdir
-rwxr-s--- 1 root group1 88408 Sep 5 2019 /bin/mkdir
Como resultado, o aplicativo é executado com permissões para group1. Se o usuário não for membro do group1, ele não terá acesso para executar mkdiro .
User1 é membro da group1, mas user2 não é:
# id user1
uid=1001(user1) gid=1001(group1) groups=1001(group1)
# id user2
uid=1002(user2) gid=2002(group2) groups=2002(group2)
Após essa alteração, pode ser executado, mas user2 não pode, user1 já user2 que não está em group1.mkdir
# su user1
$ mkdir test
$ ls -la | grep test
drwxr-xr-x 2 user1 group1 4096 Oct 11 18:48 test
# su user2
$ mkdir user2-test
bash: /usr/bin/mkdir: Permission denied
Bit pegajoso
O bit adesivo é usado apenas para diretórios e, quando usado, controla quais arquivos podem ser modificados nesse diretório, independentemente de suas permissões de bit de modo. Quando um bit adesivo é definido, apenas os proprietários de arquivos (e root) podem modificar arquivos, mesmo que as permissões de arquivo sejam mostradas como "777".
No exemplo a seguir, o diretório "sticky" vive em um volume do Azure NetApp Fils e tem permissões abertas amplas, mas o bit adesivo está definido.
# mkdir sticky
# chmod 777 sticky
# chmod o+t sticky
# ls -la | grep sticky
drwxrwxrwt 2 root root 4096 Oct 11 19:24 sticky
Dentro da pasta estão arquivos de propriedade de diferentes usuários. Todos têm 777 permissões.
# ls -la
total 8
drwxrwxrwt 2 root root 4096 Oct 11 19:29 .
drwxrwxrwx 8 root root 4096 Oct 11 19:24 ..
-rwxr-xr-x 1 user2 group1 0 Oct 11 19:29 4913
-rwxrwxrwx 1 UNIXuser group1 40 Oct 11 19:28 UNIX-file
-rwxrwxrwx 1 user1 group1 33 Oct 11 19:27 user1-file
-rwxrwxrwx 1 user2 group1 34 Oct 11 19:27 user2-file
Normalmente, qualquer pessoa seria capaz de modificar ou excluir esses arquivos. Mas como a pasta pai tem um bit adesivo definido, apenas os proprietários de arquivos podem fazer alterações nos arquivos.
Por exemplo, user1 não pode modificar nem excluir user2-file:
# su user1
$ vi user2-file
Only user2 can modify this file.
Hi
~
"user2-file"
"user2-file" E212: Can't open file for writing
$ rm user2-file
rm: can't remove 'user2-file': Operation not permitted
Por outro lado, não pode modificar nem excluiruser1-file, user2 pois eles não possuem o arquivo e o bit adesivo é definido no diretório pai.
# su user2
$ vi user1-file
Only user1 can modify this file.
Hi
~
"user1-file"
"user1-file" E212: Can't open file for writing
$ rm user1-file
rm: can't remove 'user1-file': Operation not permitted
Root, no entanto, ainda pode remover os arquivos.
# rm UNIX-file
Para alterar a capacidade do root de modificar arquivos, você deve esmagar root para um usuário diferente por meio de uma regra de política de exportação do Azure NetApp Files. Para obter mais informações, consulte esmagamento de raiz.
Umask
Em operações NFS, as permissões podem ser controladas por meio de bits de modo, que aproveitam atributos numéricos para determinar o acesso a arquivos e pastas. Esses bits de modo determinam atributos de leitura, gravação, execução e especiais. Numericamente, as permissões são representadas como:
- Executar = 1
- Leitura = 2
- Escrever = 4
O total de permissões é determinado adicionando ou subtraindo uma combinação das anteriores. Por exemplo:
- 4 + 2 + 1 = 7 (pode fazer tudo)
- 4 + 2 = 6 (leitura/gravação)
Para obter mais informações, consulte a Ajuda de permissões do UNIX.
Umask é uma funcionalidade que permite que um administrador restrinja o nível de permissões permitidas a um cliente. Por padrão, o umask para a maioria dos clientes é definido como 0022. 0022 significa que os arquivos criados a partir desse cliente recebem esse umask. O umask é subtraído das permissões base do objeto. Se um volume tiver permissões 0777 e for montado usando NFS para um cliente com um umask de 0022, os objetos gravados do cliente para esse volume terão acesso 0755 (0777 – 0022).
# umask
0022
# umask -S
u=rwx,g=rx,o=rx
No entanto, muitos sistemas operacionais não permitem que arquivos sejam criados com permissões de execução, mas permitem que as pastas tenham as permissões corretas. Assim, os arquivos criados com um umask de 0022 podem acabar com permissões de 0644. O exemplo a seguir usa o RHEL 6.5:
# umask
0022
# cd /cdot
# mkdir umask_dir
# ls -la | grep umask_dir
drwxr-xr-x. 2 root root 4096 Apr 23 14:39 umask_dir
# touch umask_file
# ls -la | grep umask_file
-rw-r--r--. 1 root root 0 Apr 23 14:39 umask_file