¿Cómo funcionan los permisos / atributos de archivo? ¿Nivel de núcleo, nivel FS o ambos?


8

Una pregunta que se me ocurrió antes: ¿los permisos / atributos de los archivos dependen del sistema operativo (y, por lo tanto, del núcleo) o del sistema de archivos? Me parece que la segunda alternativa es la más lógica, pero nunca oí hablar de reiserfspermisos de archivos, por ejemplo: solo "permisos de archivos Unix". Por otro lado, para citar un artículo de Wikipedia :

A medida que aparecieron nuevas versiones de Windows, Microsoft agregó al inventario de atributos disponibles en el sistema de archivos NTFS

lo que parece sugerir que los atributos de los archivos de Windows están de alguna manera vinculados al sistema de archivos.

¿Puede alguien por favor iluminarme?

Respuestas:


7

Tanto el kernel como el sistema de archivos juegan un papel importante. Los permisos se almacenan en el sistema de archivos, por lo que debe haber un lugar para almacenar la información en el formato del sistema de archivos. Los permisos son impuestos y comunicados a las aplicaciones por el núcleo, por lo que el núcleo debe implementar reglas para determinar qué significa la información almacenada en el sistema de archivos.

Los “permisos de archivos Unix” se refieren a un sistema de permisos tradicional que involucra tres acciones (leer, escribir, ejecutar) controladas a través de tres tipos de roles (usuario, grupo, otros). El trabajo del sistema de archivos es almacenar 3 × 3 = 9 bits de información. El trabajo del núcleo es interpretar estos bits como permisos; en particular, cuando un proceso intenta una operación en un archivo, el núcleo debe determinar, dado el usuario y los grupos que el proceso se está ejecutando, los bits de permiso del archivo y la operación solicitada, si se debe permitir la operación. (Los "permisos de archivo Unix" también suelen incluir bits setuid y setgid , que no son estrictamente permisos de habla).

Los sistemas Unix modernos pueden admitir otras formas de permisos. La mayoría de los sistemas Unix modernos (Solaris, Linux, * BSD) admiten listas de control de acceso que permiten asignar permisos de lectura / escritura / ejecución para más de un usuario y más de un grupo para cada archivo. El sistema de archivos debe tener espacio para almacenar esta información adicional, y el núcleo debe incluir código para buscar y usar esta información. Ext2, reiserfs, btrfs, zfs y la mayoría de los otros formatos modernos de sistemas de archivos Unix definen un lugar para almacenar tales ACL. Mac OS X admite un conjunto diferente de ACL que incluye permisos no tradicionales como "agregar" y "crear subdirectorio"; el formato del sistema de archivos HFS + los admite. Si monta un volumen HFS + en Linux, estas ACL no se aplicarán ya que el kernel de Linux no las admite.

Por el contrario, hay sistemas operativos y sistemas de archivos que no admiten el control de acceso. Por ejemplo, FAT y variantes se diseñaron para sistemas operativos de un solo usuario y medios extraíbles y sus permisos se limitan a lectura / lectura-escritura y oculto / visible. Estos son los permisos impuestos por DOS . Si monta un sistema de archivos ext2 en DOS, no aplicará los permisos ext2. Por el contrario, si accede a un sistema de archivos FAT en Linux, todos los archivos tendrán los mismos permisos.

Las versiones sucesivas de Windows han agregado soporte para más tipos de permisos. El sistema de archivos NTFS se amplió para almacenar esos permisos adicionales. Si accede a un sistema de archivos con los permisos más nuevos en un sistema operativo más antiguo, el sistema operativo no sabrá acerca de estos permisos más nuevos y, por lo tanto, no los hará cumplir. Por el contrario, si accede a un sistema de archivos más antiguo con un sistema operativo más nuevo, no tendrá los nuevos permisos y depende del sistema operativo proporcionar fallos razonables.


"El trabajo del kernel es interpretar estos bits como permisos; en particular, cuando un proceso intenta una operación en un archivo, el kernel debe determinar [...]" Eso no significa que un kernel en teoría podría ser alterado para ignorar todo eso y leer los datos de todos modos? (Una especie de acceso directo al disco) ¿O hay algo más que lo impida?
Overmind

@ Overmind Por supuesto. El código del kernel tiene acceso a todo. El disco no sabe nada sobre procesos, usuarios o permisos. El núcleo le dice al disco "dame el bloque 232876" y el disco responde con el contenido del bloque. Determinar qué procesos pueden acceder a qué bloques (o qué partes de bloques) es el trabajo del núcleo.
Gilles 'SO- deja de ser malvado'

4

Para utilizar ciertos derechos, tanto el núcleo como el sistema de archivos deben ser compatibles. Si el sistema de archivos ni siquiera admite los derechos de acceso más básicos, entonces el código del sistema de archivos tiene que falsificarlos (por ejemplo, con la opción de montaje umaskpara vfat).


3

Entiendo que el kernel implementa inodes en VFS. los inodes contienen información de permisos (UNIX y ACL) junto con otros metadatos y el sistema de archivos puede extender el inodo para agregar características. Si está interesado, lea sobre Linux VFS - cosas sangrientas si no es un programador de sistemas.


1

Como regla general, los permisos de archivos y los atributos de los archivos se almacenan en el sistema de archivos [la forma exacta depende del sistema de archivos en cuestión (ext3 / 4, riser, NTFS, etc.)], pero el núcleo los usa , normalmente para imponer algo.

Por ejemplo, el núcleo en * nix como sistema es "la cosa" que conoce el significado del UID asociado a un archivo / directorio. Un UID de archivo es simplemente un número almacenado junto con un archivo certan por el sistema de archivos, pero el núcleo realiza la "traducción" de dicho número a un determinado usuario (y los derechos correspondientes para hacer algo o no).

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.