Descripción de los bits de modo en Azure NetApp Files
Los permisos de acceso a archivos en NFS limitan lo que los usuarios y grupos pueden hacer una vez que se monta un volumen NAS. Los bits de modo son una característica clave de los permisos de archivo NFS en Azure NetApp Files.
Bits del modo NFS
Los permisos de bits de modo en NFS proporcionan permisos básicos para archivos y carpetas, mediante una representación numérica estándar de los controles de acceso. Los bits de modo se pueden usar con NFSv3 o NFSv4.1, pero los bits de modo son la opción estándar para proteger NFSv3 tal como se define en RFC-1813. En la tabla siguiente se muestra cómo se corresponden esos valores numéricos con los controles de acceso.
| Numérico de bits de modo |
|---|
| 1 : ejecutar (x) |
| 2 : escritura (w) |
| 3 : escritura/ejecución (wx) |
| 4 – lectura (r) |
| 5 : lectura y ejecución (rx) |
| 6 – lectura y escritura (rw) |
| 7 : lectura,escritura/ejecución (rwx) |
Los valores numéricos se aplican a distintos segmentos de un control de acceso: propietario, grupo y todos los demás, lo que significa que no hay controles de acceso de usuario pormenorizados para NFSv3 básico. En la imagen siguiente se muestra un ejemplo de cómo se puede construir un control de acceso de bits de modo para su uso con un objeto NFSv3.
Azure NetApp Files no admite ACL POSIX. Por lo tanto, las ACL pormenorizadas solo son posibles con NFSv3 cuando se usa un volumen de estilo de seguridad NTFS con asignaciones válidas de UNIX a nombre de Windows a través de un servicio de nombres como LDAP de Active Directory. Como alternativa, puede usar NFSv4.1 con Azure NetApp Files y ACL NFSv4.1.
En la tabla siguiente se compara la granularidad de permisos entre bits del modo NFSv3 y las ACL NFSv4.x.
| Bits del modo NFSv3 | ACL nfSv4.x |
|---|---|
|
|
Para obtener más información, consulte Descripción de las listas de control de acceso nfSv4.x.
Bits pegajosos, setuid y setgid
Cuando se usan bits de modo con montajes NFS, la propiedad de los archivos y carpetas se basa en y uid gid en el usuario que creó los archivos y carpetas. Además, cuando se ejecuta un proceso, se ejecuta como el usuario que lo inició y, por tanto, tendría los permisos correspondientes. Con permisos especiales (como setuid, setgid, bit pegajoso), este comportamiento se puede controlar.
Setuid
El setuid bit lo designa un "s" en la parte de ejecución del bit de propietario de un permiso. El setuid bit permite que un archivo ejecutable se ejecute como propietario del archivo en lugar de como el usuario que intenta ejecutar el archivo. Por ejemplo, la /bin/passwd aplicación tiene el setuid bit habilitado de forma predeterminada, por lo que la aplicación se ejecuta como raíz cuando un usuario intenta cambiar su contraseña.
# ls -la /bin/passwd
-rwsr-xr-x 1 root root 68208 Nov 29 2022 /bin/passwd
Si se quita el setuid bit, la funcionalidad de cambio de contraseña no funcionará correctamente.
# 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
Cuando se restaura el setuid bit, la aplicación passwd se ejecuta como propietario (raíz) y funciona correctamente, pero solo para el usuario que ejecuta el 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 no tiene ningún efecto en los directorios.
Setgid
El setgid bit se puede usar en archivos y directorios.
Con los directorios, setgid se puede usar como una manera de heredar el grupo propietario de archivos y carpetas creados debajo del directorio primario con el conjunto de bits. Al igual que setuid, el bit ejecutable se cambia a "s" o "S".
Nota:
El capital "S" significa que el bit ejecutable no se ha establecido, por ejemplo, si los permisos en el directorio son "6" o "rw".
Por ejemplo:
# 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
En el caso de los archivos, setgid se comporta de forma similar a setuid: los ejecutables se ejecutan mediante los permisos de grupo del propietario del grupo. Si un usuario está en el grupo propietario, dicho usuario tiene acceso para ejecutar el ejecutable cuando se establece setgid. Si no están en el grupo, no obtienen acceso. Por ejemplo, si un administrador quiere limitar qué usuarios podrían ejecutar el mkdir comando en un cliente, pueden usar setgid.
Normalmente, /bin/mkdir tiene 755 permisos con propiedad raíz. Esto significa que cualquier persona puede ejecutarse mkdir en un cliente.
# ls -la /bin/mkdir
-rwxr-xr-x 1 root root 88408 Sep 5 2019 /bin/mkdir
Para modificar el comportamiento para limitar qué usuarios pueden ejecutar el mkdir comando, cambie el grupo propietario de la mkdir aplicación, cambie los permisos de a /bin/mkdir 750 y agregue el 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, la aplicación se ejecuta con permisos para group1. Si el usuario no es miembro de group1, el usuario no obtiene acceso para ejecutar mkdir.
User1 es miembro de group1, pero user2 no es:
# id user1
uid=1001(user1) gid=1001(group1) groups=1001(group1)
# id user2
uid=1002(user2) gid=2002(group2) groups=2002(group2)
Después de este cambio, user1 puede ejecutar mkdir, pero user2 no puede, ya user2 que no está en 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 persistente
El bit pegajoso solo se usa para directorios y, cuando se usa, controla qué archivos se pueden modificar en ese directorio independientemente de sus permisos de bits de modo. Cuando se establece un bit pegajoso, solo los propietarios de archivos (y la raíz) pueden modificar archivos, incluso si los permisos de archivo se muestran como "777".
En el ejemplo siguiente, el directorio "sticky" reside en un volumen de Azure NetApp Fils y tiene permisos abiertos anchos, pero se establece el bit pegajoso.
# mkdir sticky
# chmod 777 sticky
# chmod o+t sticky
# ls -la | grep sticky
drwxrwxrwt 2 root root 4096 Oct 11 19:24 sticky
Dentro de la carpeta hay archivos propiedad de distintos usuarios. Todos tienen 777 permisos.
# 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, cualquiera podría modificar o eliminar estos archivos. Pero dado que la carpeta primaria tiene un bit fijo, solo los propietarios de archivos pueden realizar cambios en los archivos.
Por ejemplo, user1 no puede modificar ni eliminar 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 el contrario, user2 no se puede modificar ni eliminar user1-file , ya que no poseen el archivo y el bit pegajoso se establece en el directorio primario.
# 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
Sin embargo, root todavía puede quitar los archivos.
# rm UNIX-file
Para cambiar la capacidad de raíz para modificar archivos, debe aplastar la raíz a un usuario diferente mediante una regla de directiva de exportación de Azure NetApp Files. Para obtener más información, vea root squashing.
Umask
En las operaciones NFS, los permisos se pueden controlar a través de bits de modo, que aprovechan los atributos numéricos para determinar el acceso a archivos y carpetas. Estos bits de modo determinan los atributos de lectura, escritura, ejecución y especial. Numéricamente, los permisos se representan como:
- Execute = 1
- Read = 2
- Escritura = 4
Los permisos totales se determinan agregando o restando una combinación del anterior. Por ejemplo:
- 4 + 2 + 1 = 7 (puede hacer todo)
- 4 + 2 = 6 (lectura y escritura)
Para obtener más información, consulte Ayuda de permisos de UNIX.
Umask es una funcionalidad que permite a un administrador restringir el nivel de permisos permitido a un cliente. De forma predeterminada, umask para la mayoría de los clientes se establece en 0022. 0022 significa que a los archivos creados a partir de ese cliente se les asigna ese umask. El umask se resta de los permisos base del objeto. Si un volumen tiene 0777 permisos y se monta mediante NFS en un cliente con un umask de 0022, los objetos escritos desde el cliente a ese volumen tienen acceso 0755 (0777 – 0022).
# umask
0022
# umask -S
u=rwx,g=rx,o=rx
Sin embargo, muchos sistemas operativos no permiten crear archivos con permisos de ejecución, pero permiten que las carpetas tengan los permisos correctos. Por lo tanto, los archivos creados con un umask de 0022 podrían acabar con permisos de 0644. En el ejemplo siguiente se usa 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