¿Cómo funcionan los permisos de archivo para el usuario "root"?

Tengo el siguiente archivo:

---------- 1 Steve Steve 341 2017-12-21 01:51 myFile.txt

Cambié al usuario rooten el terminal y noté los siguientes comportamientos:

• Puedo leer este archivo y escribirle.

• No puedo ejecutar este archivo.

• Si configuro el xbit en los permisos de usuario ( ---x------) o los permisos de grupo ( ------x---) o los otros permisos ( ---------x) del archivo, entonces podría ejecutar este archivo.

¿Alguien puede explicarme o señalarme un tutorial que explique todas las reglas que se aplican cuando el rootusuario maneja archivos y directorios?

El acceso privilegiado a archivos y directorios está realmente determinado por las capacidades, no solo por ser rooto no. En la práctica, rootgeneralmente tiene todas las capacidades posibles, pero hay situaciones en las que todas / muchas de ellas podrían descartarse, o algunas podrían entregarse a otros usuarios (sus procesos).

En resumen, ya describió cómo funcionan las verificaciones de control de acceso para un proceso privilegiado. Así es como las diferentes capacidades realmente lo afectan:

El principal capacidad aquí es queCAP_DAC_OVERRIDE un proceso que tiene puede "omitir la lectura, escritura y ejecución de verificaciones de permisos". Eso incluye leer y escribir en cualquier archivo, así como leer, escribir y acceder a directorios.

En realidad, no se aplica a la ejecución de archivos que no están marcados como ejecutables. El comentario engeneric_permission (fs/namei.c ), antes de que el acceso verifique los archivos, dice que

Los DAC de lectura / escritura son siempre reemplazables. Los DAC ejecutables son reemplazables cuando hay al menos un conjunto de bits de ejecución.

Y el código verifica que haya al menos uno x bit establecido si está intentando ejecutar el archivo. Sospecho que es solo una característica conveniente, para evitar la ejecución accidental de archivos de datos aleatorios y obtener errores o resultados extraños.

De todos modos, si puede anular los permisos, puede hacer una copia ejecutable y ejecutarla. _{(Aunque podría hacer una diferencia en teoría, los archivos setuid de un proceso podían anular los permisos de archivo ( CAP_DAC_OVERRIDE), pero no tenían otras capacidades relacionadas ( CAP_FSETID/ CAP_FOWNER/ CAP_SETUID). Pero tenerCAP_DAC_OVERRIDE permitir la edición /etc/shadowy cosas así, es aproximadamente igual solo tener acceso completo a la raíz de todos modos)}

También existe la CAP_DAC_READ_SEARCHcapacidad que permite leer cualquier archivo y acceder a cualquier directorio, pero no ejecutar ni escribir en ellos; yCAP_FOWNER eso permite que un proceso haga cosas que generalmente están reservadas solo para el propietario del archivo, como cambiar los bits de permiso y el grupo de archivos.

Anular el bit adhesivo en los directorios solo se menciona debajo CAP_FOWNER, por lo que parece queCAP_DAC_OVERRIDE no sería suficiente para ignorar eso. (Le daría permiso de escritura, pero generalmente en directorios fijos lo tiene de todos modos, y lo +tlimita).

_{(Creo que los dispositivos especiales cuentan como "archivos" aquí. Al menos generic_permission()solo tiene una verificación de tipo para los directorios, pero no verifiqué fuera de eso).}

Por supuesto, todavía hay situaciones en las que incluso las capacidades no lo ayudarán a modificar archivos:

• algunos archivos /procy/sys , dado que no son realmente archivos reales
• SELinux y otros módulos de seguridad que pueden limitar la raíz
• chattrinmutable +iy solo agregar+a indicadores en ext2 / ext3 / ext4, los cuales detienen incluso la raíz y evitan también el cambio de nombre de archivos, etc.
• sistemas de archivos de red, donde el servidor puede hacer su propio control de acceso, p. ej. root_squash en mapas NFS root a nadie
• FUSE, que supongo que podría hacer cualquier cosa
• montajes de solo lectura
• dispositivos de solo lectura

Eso es exactamente como lo has notado para los permisos predeterminados:

• Leer y escribir: de
  forma predeterminada, el usuario raíz puede acceder a cualquier archivo en el sistema. Puede eliminar este acceso cambiando los atributos como explicar aquí: chattr . Esto se vincula a las capacidades.

• Ejecutar: el
  usuario raíz no tiene permiso de ejecución a menos que se establezca al menos uno de los bits de ejecución.

El myFile.txtes obtenido por chmod 000 myFile.txt.

0 no permission
1 execute
2 write
3 execute + write
4 read 
5 read + execute
6 read + write
7 all

--------- significa que no hay permiso para usuarios, grupos y otros.

El usuario root tiene una capacidad ilimitada para modificar este archivo. La lectura / escritura se otorga. Para ejecutar este archivo, el usuario raíz debe hacerlo ejecutable de todos modos. (chmod 100, 010 o 001)

El modo de ejecución se trata un poco diferente de los otros modos.

Los permisos de lectura y escritura se utilizan para aplicar políticas de seguridad. losroot usuario generalmente es inmune a las restricciones de seguridad (hay algunas excepciones, como archivos inmutables, y las características modernas como las capacidades lo han hecho más preciso), por lo que otro nombre para esta cuenta es el "superusuario".

El permiso de ejecución es más un modo de aviso, que distingue si el archivo está destinado a ser ejecutable o es solo un dato. Debido a esto, incluso el usuario root lo obedece: no tiene sentido ejecutar un archivo de datos. Si ninguno de los permisos de ejecución está configurado, root no puede ejecutar el archivo; si alguno de ellos está configurado, él puede. Por supuesto, dado que root también tiene permiso para cambiar los permisos de cualquier archivo, la cuenta puede hacer que un archivo sea ejecutable si lo desea (a menos que el sistema de archivos sea de solo lectura).

Por cierto, los guiones son un caso interesante en esto. Los scripts son archivos de datos para el intérprete relevante. Si el script tiene una #!línea, puede ejecutarla como un programa: el intérprete nombrado en el shebang se ejecuta con el nombre del archivo del script como argumento. Pero esto solo se hará cuando se establezca el permiso de ejecución. Por otro lado, puede ejecutar el intérprete directamente, por ejemplo /bin/bash scriptname. Los intérpretes solo se preocupan si pueden leer el archivo, no verifican los permisos de ejecución.

Déjame explicarte teóricamente.

El usuario root es el rey del sistema operativo.

Si un archivo o directorio tiene algún permiso como X para ejecutar pero nada más y alguien como el usuario de Steve tiene el archivo, entonces el usuario root también puede ejecutar el archivo.

Siempre recuerde, en la raíz de Linux puede hacer cualquier cosa, no hay restricciones en la raíz.