Entender 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 depois que um volume NAS é montado. Os bits de modo são um recurso importante das permissões de arquivo NFS nos Arquivos do Azure NetApp.
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 o NFSv3, conforme definido na 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 – Escreva (w) |
| 3 – Gravar/Executar (WX) |
| 4 – Ler (R) |
| 5 – Leitura/Execução (Rx) |
| 6 – Leitura/Gravação (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 em vigor 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.
Os Arquivos NetApp do Azure não oferecem suporte a 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 Active Directory. Como alternativa, você pode usar o NFSv4.1 com os Arquivos do Azure NetApp e as ACLs do 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 Noções básicas sobre listas de controle de acesso do NFSv4.x ACLs.
Sticky bits, 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, , setgidsticky bit), 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 habilitado 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 (root) e funciona corretamente, mas apenas para o setuid usuário que executa o 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 de proprietários 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".
Observação
"S" maiúsculo significa que o bit executável não foi definido, como se as permissões no diretório fossem "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 de proprietários, 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 poderá usar setgid.
Normalmente, /bin/mkdir tem 755 permissões com propriedade root. 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 que possui o aplicativo, altere as permissões para /bin/mkdir 750 e, em seguida, adicione o mkdir 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 do 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 executar mkdir, mas user2 não pode, user1 uma vez que user2 não está no group1.
# 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
Pedaço 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 pegajoso é definido, somente os proprietários de arquivos (e a raiz) 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, mas o bit sticky é 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 fixo definido, somente os proprietários do arquivo 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 é possível 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 da raiz de modificar arquivos, você deve squash 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
As permissões totais são determinadas 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.
O Umask é uma funcionalidade que permite a um administrador restringir 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, 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