Entender como funcionam os bits de modo nos arquivos do Azure NetApp

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.

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 quando se utiliza um volume com estilo de segurança NTFS e mapeamentos de nomes válidos de UNIX para Windows, por meio de um serviço de nomes, como o LDAP do Active 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.

Para obter mais informações, consulte Compreender ACLs de listas de controle de acesso NFSv4.x.

Bits de aderência, setuid e setgid

Ao usar bits de modo com montagem NFS, a posse de ficheiros e pastas é baseada no uid e gid do utilizador que criou os ficheiros e 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, setgid, bit sticky), este 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 /bin/passwd aplicativo tem o bit ativado setuid por padrão, portanto, o 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 setuid bit é restaurado, o aplicativo passwd é executado como o proprietário (raiz) e funciona corretamente, mas apenas para o 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 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".

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 mkdir comando, altere o grupo proprietário do mkdir aplicativo, altere as permissões para /bin/mkdir 750 e adicione o 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, user1 pode executar mkdir, mas user2 não pode, já que user2 não está em 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

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 directório "sticky" reside em um volume do Azure NetApp Files e tem permissões amplas abertas, mas o bit de fixação 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

Pelo contrário, user2 não pode modificar nem excluir user1-file pois não possuem o arquivo e o bit stick está ativado 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 de NFS, as permissões podem ser controladas através de bits de modo, que utilizam atributos numéricos para determinarem o acesso a ficheiros e pastas. Esses bits de modo determinam os atributos de leitura, de gravação, de execução e os especiais. Numericamente, as permissões são representadas como:

• Executar = 1
• Ler = 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 ficheiros criados a partir deste 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 nesse volume terão permissões 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

Próximos passos

• Compreender grupos auxiliares/suplementares com NFS
• Compreender as listas de controle de acesso NFSv4.x