Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
As permissões de acesso a arquivos no NFS limitam o que os usuários e grupos podem fazer uma vez que um volume NAS é montado. Os bits de modo são um recurso importante das permissões de arquivo NFS no Azure NetApp Files.
Bits de modo NFS
As permissões de bits 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 no RFC-1813. A tabela a seguir mostra como esses valores numéricos correspondem aos controles de acesso.
| Numérico de bits de modo |
|---|
| 1 – executar (x) |
| 2 – gravar (w) |
| 3 – gravar/executar (wx) |
| 4 – ler (r) |
| 5 – ler/executar (rx) |
| 6 – ler/gravar (rw) |
| 7 – ler/gravar/executar (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 granulares de acesso de usuários no NFSv3 básico. A imagem a seguir mostra um exemplo de como um controle de acesso de bits de modo pode ser construído para uso com um objeto NFSv3.
O Azure NetApp Files não dá suporte a ACLs POSIX. Portanto, as ACLs granulares só são possíveis com NFSv3 ao usar 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 Azure NetApp Files e 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 Entender as listas de controle de acesso ACLs NFSv4.x.
Bits autoadesivos, setuid e setgid
Ao usar os bits de modo com montagens NFS, a propriedade de arquivos e pastas é baseada no uid e gid do usuário que criou os arquivos 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 autoadesivo), esse comportamento pode ser controlado.
Setuid
O bit setuid é 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 que está tentando executar o arquivo. Por exemplo, o /bin/passwd aplicativo tem o setuid bit habilitado por padrão, portanto, o aplicativo é executado como raiz 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.
Nos diretórios, o setgid pode ser usado como uma forma de herdar o grupo proprietário de arquivos e pastas criados abaixo do diretório pai com o conjunto de bits. Como setuid, o bit executável é alterado para um "s" ou um "S".
Observação
O “S” maiúsculo significa que o bit executável não foi definido, por exemplo, se as permissões no diretório forem “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
Quanto aos arquivos, o setgid se comporta de forma semelhante a setuid-executáveis são executados usando as permissões do proprietário do grupo. Se um usuário estiver no grupo de proprietários, ele tem acesso para executar o arquivo quando o setgid é definido. Se eles não estiverem no grupo, eles não obterão acesso. Por exemplo, se um administrador quiser limitar quais usuários podem executar o mkdir comando em um cliente, eles poderão usar setgid.
Normalmente, /bin/mkdir tem 755 permissões com propriedade do usuário 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 mkdir comando, altere o grupo que possui o mkdir aplicativo, altere as permissões para /bin/mkdir 750 e adicione o bit setgid a 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, group1o usuário não obterá acesso para execução mkdir.
User1 é um membro de 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, pois 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 autoadesivo
O bit autoadesivo é usado somente nos diretórios e, quando usado, controla quais arquivos podem ser modificados nesse diretório, independentemente das permissões de bit do modo. Quando um bit autoadesivo é definido, somente os proprietários de arquivos (e raiz) podem modificar arquivos, mesmo que as permissões de arquivo sejam mostradas como “777”.
No exemplo a seguir, o diretório “autoadesivo” reside em um volume do Azure NetApp Fils e tem permissões abertas, mas o bit autoadesivo 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 há arquivos pertencentes a usuários diferentes. Todas 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 o diretório pai tem o bit sticky ativado, somente os proprietários dos 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, user2 não podem modificar nem excluir user1-file, pois não possuem o arquivo e o bit autoadesivo é 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 esmagar a raiz para um usuário diferente por uma regra de política de exportação do Azure NetApp Files. Para obter mais informações, consulte esmagamento raiz.
Umask
Em operações NFS, as permissões podem ser controladas por meio de bits de modo, que utilizam atributos numéricos para determinar o acesso a arquivos e pastas. Esses bits de modo determinam atributos especiais, de leitura, gravação, execução e de leitura. Numericamente, as permissões são representadas como:
- Executar = 1
- Leitura = 2
- Gravação = 4
O total de permissões é determinado adicionando ou subtraindo uma combinação do anterior. 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 UNIX.
Umask é uma funcionalidade que permite que um administrador restrinja o nível de permissões permitidas a um cliente. Por padrão, a umask para a maioria dos clientes é definida como 0022. 0022 significa que os arquivos criados a partir desse cliente são atribuídos a essa umask. A umask é subtraída das permissões base do objeto. Se um volume tiver permissões 0777 e for montado usando NFS em um cliente com uma umask de 0022, os objetos gravados do cliente nesse 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 uma 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