Por lo general, un sistema de archivos mantiene configuraciones de permisos para cada elemento almacenado ( normalmente archivos y directorios ) que otorgan o deniegan la capacidad de manipular dichos elementos. A menudo, estas configuraciones permiten controlar el acceso según funciones como leer, modificar, navegar y ejecutar, así como para diferentes usuarios y grupos de usuarios.
Una tecnología bien establecida se desarrolló para Unix , posteriormente fue codificada por POSIX y se utiliza en Linux [ 1 ] . Otra tecnología común es la lista de control de acceso (ACL), con múltiples variantes implementadas en sistemas de archivos y una codificada por POSIX. Dado que POSIX define tanto la tecnología más antigua basada en Unix como las ACL, a la primera se la denomina permisos POSIX tradicionales para mayor claridad, aunque no sea un término muy conocido.
Una interfaz de usuario basada en permisos adapta la funcionalidad disponible para el usuario según los permisos de los elementos del sistema de archivos. Por ejemplo, la interfaz podría ocultar las opciones de menú que no están permitidas según los permisos almacenados para un elemento.
Historia
CTSS
Un sistema de tiempo compartido primitivo, el Sistema de Tiempo Compartido Compatible (CTSS), admitía múltiples usuarios; la cuenta de cada usuario tenía un "número de problema" y un "número de programador". [ 2 ]
La primera versión del sistema de archivos CTSS admitía solo dos modos de archivo de "solo lectura", uno de los cuales podía ser desactivado por el usuario y el otro solo podía ser desactivado con tarjetas de edición enviadas al centro de computación. [ 2 ] : 45–46 Los archivos pueden ser compartidos entre usuarios en el mismo proyecto; los archivos compartidos se asignan al programador número cero. [ 2 ] : 24 No hay protección más allá de la proporcionada por los bits de solo lectura.
La segunda versión del sistema de archivos tiene bits de permisos separados para "solo lectura" y "solo escritura"; este último solo permite agregar contenido al archivo. También tiene un bit "privado", que permite que solo el autor del archivo acceda a él, y un bit "protegido", que permite que solo el autor del archivo cambie los permisos del archivo. [ 3 ]
Multics
Los usuarios del sistema de tiempo compartido Multics tienen un "Person_id" y los proyectos un "Project_id"; un usuario inicia sesión en el sistema con su Person_id y un Project_id. Un archivo contiene una lista de control de acceso (ACL), con entradas que incluyen un Person_id o un "*", un Project_id o un "*" y una "etiqueta de instancia" o un "*". Una etiqueta de instancia representa un tipo de proceso; por ejemplo, una "a" representa un proceso de una sesión interactiva normal. Las entradas de una ACL se comparan con el Person_id, el Project_id y la etiqueta de instancia del proceso; un "*" es un comodín que coincide con todos los Person_id, Project_id o etiquetas de instancia. Se utiliza la entrada de la ACL que coincide con la menor cantidad de comodines. [ 4 ] : 6–2, 6-46-8
Una ACL para un archivo tiene permisos de acceso de "lectura", "escritura" y "ejecución"; una ACL para un directorio tiene permisos de acceso de "estado" (permite leer los atributos de los archivos y directorios en el directorio), "modificar" (permite modificar los atributos de los archivos y directorios en el directorio y eliminar elementos del directorio) y "añadir" (permite agregar nuevos elementos al directorio). [ 4 ] : 6-3
TENEX
Un usuario en TENEX pertenece a un conjunto de grupos. [ 5 ] : 44
Un archivo o directorio tiene un conjunto de bits de permisos: seis bits para los permisos del propietario, seis para los permisos de otros usuarios del grupo del archivo o directorio y seis para otros usuarios. Para un archivo, los bits de permisos son "lectura", "escritura", "ejecución", "añadir" y "cada página del archivo tiene sus propios permisos", sin que se utilice el sexto bit. Para un directorio, los bits de permisos son "acceso permitido" (si no se establece, no se permite el acceso al directorio), "se pueden abrir archivos en el directorio" (sujeto a los bits de permisos del archivo), "se pueden realizar funciones similares a las del propietario sin la contraseña del archivo" y "se pueden añadir archivos al directorio", sin que se utilicen el quinto y el sexto bit. [ 5 ] : 42–44
TOPS-10
En TOPS-10, una cuenta de usuario tiene un número de programador y un número de proyecto.
Un archivo tiene un conjunto de bits de permisos: tres bits para los permisos del propietario del archivo, tres bits para los permisos de otros usuarios con el mismo número de proyecto que el propietario y tres bits para todos los demás usuarios. El sistema operativo puede configurarse para tratar como propietario a cualquier cuenta con un número de programador igual al del directorio que lo contiene, o para tratar como propietario únicamente a las cuentas con el mismo número de programador y número de proyecto que los del directorio que lo contiene. Los valores de los bits de permisos son:
- 7 - sin privilegios de acceso, excepto que el propietario puede consultar el archivo para cambiar sus permisos;
- 6 - solo ejecución;
- 5 - leer y ejecutar;
- 4 - agregar, leer y ejecutar;
- 3 - actualizar, agregar, leer y ejecutar;
- 2 - escribir, actualizar, añadir, leer y ejecutar;
- 1 - renombrar, escribir, actualizar, agregar, leer y ejecutar;
- 0 - cambiar permisos, renombrar, escribir, actualizar, agregar, leer y ejecutar.
El propietario siempre tiene permiso para cambiar los permisos. [ 6 ]
Sistemas UNIX y similares a Unix
Los archivos en la primera edición de Unix (v1) tenían cinco bits de permiso:
- escribir, no propietario;
- leer, no propietario;
- escribe, propietario;
- leer, propietario;
- ejecutable;
y un bit set-UID . [ 7 ] No tenía noción de grupos. Esto continuó hasta la tercera edición (v3); [ 8 ] la cuarta edición (v4) introdujo grupos, y los archivos en v4 tenían nueve bits de permiso:
- leer, propietario;
- escribe, propietario;
- ejecutar, propietario;
- leer, grupo;
- escribir, grupo;
- ejecutar, grupo;
- leer, otro;
- escribir, otro;
- ejecutar, otro;
así como un bit set-UID y set-GID ; [ 9 ] Este es el mismo conjunto de permisos que se especifican en POSIX y que proporcionan los sistemas Unix y similares a Unix actuales .
Ejemplos
Los permisos del sistema de archivos se han implementado de muchas maneras. Aquí se describen algunos ejemplos destacados.
NTFS , presente en muchas versiones de Windows , incluida la actual , utiliza ACL para proporcionar control de acceso basado en permisos; las ACL de NTFS se consideran potentes pero complejas. [ 10 ]
Los sistemas de archivos de Linux, como ext2 , ext3 , ext4 y Btrfs, admiten tanto permisos POSIX como ACL POSIX.1e. Existe soporte experimental para ACL NFSv4 para los sistemas de archivos ext3 [ 11 ] y ext4.
FreeBSD admite ACL POSIX.1e en UFS y ACL NFSv4 en UFS y ZFS. [ 12 ] [ 13 ]
HFS y su sucesor , HFS+ , tal como se implementan en los sistemas operativos Classic Mac OS , no admiten permisos.
macOS admite permisos compatibles con POSIX, tanto en HFS+ como en APFS . A partir de la versión 10.4 ("Tiger"), también admite el uso de ACL de NFSv4 además de los permisos compatibles con POSIX. El Manual de administración de servicios de archivos de Apple Mac OS X Server versión 10.4+ recomienda utilizar únicamente permisos Unix tradicionales siempre que sea posible. macOS también sigue admitiendo el atributo "Protegido"/"Bloqueado" del Mac OS clásico como indicador "inmutable para el usuario" en el campo de indicadores de 4.4BSD . [ 14 ]
La tabla de asignación de archivos (versión original) tiene un atributo de solo lectura por archivo que se aplica a todos los usuarios.
OpenVMS define cuatro funciones de acceso: lectura, escritura, ejecución y eliminación, y selecciones de usuario: sistema, propietario, grupo y mundo, donde mundo incluye grupo, que a su vez incluye propietario, y sistema selecciona a los usuarios del sistema. Este diseño es similar al de Unix con extensiones notables: función adicional: eliminación y selección de usuario adicional: sistema. [ 15 ] Las ACL son compatibles con VMS 4.0 y versiones posteriores. [ 16 ]
La compatibilidad de Solaris con las ACL depende del sistema de archivos que se utilice; el sistema de archivos UFS, más antiguo , admite las ACL POSIX.1e, mientras que ZFS solo admite las ACL NFSv4. [ 17 ]
IBM z/OS implementa la seguridad de archivos mediante RACF (Resource Access Control Facility) [ 18 ].
El sistema de archivos de AmigaOS, AmigaDOS, admite un sistema de permisos relativamente avanzado para un sistema operativo de un solo usuario. En AmigaOS 1.x, los archivos tenían permisos/indicadores de Archivo, Lectura, Escritura, Ejecución y Eliminación (conocidos colectivamente como ARWED). En AmigaOS 2.x y versiones posteriores, se añadieron permisos/indicadores adicionales de Retención, Script y Puro.
El sistema operativo OpenHarmony, junto con su ecosistema del lado del cliente en Oniro OS y HarmonyOS con versiones HarmonyOS NEXT y también el sistema operativo de servidor basado en Linux openEuler, utiliza de forma nativa su sistema de archivos distribuido Harmony (HMDFS) que admite el administrador de tokens de acceso ( control de acceso basado en roles ) y la API Core File Kit basada en capacidades con administración de permisos granular, con excepción de openEuler que es de grano fino . [ 19 ]
Permisos POSIX tradicionales
Tradicionalmente, los permisos de archivo en un sistema de archivos basado en Unix se definen mediante POSIX.1. [ 20 ] Este especifica tres clases (usuario, grupo y otros) que permiten asignar permisos a los usuarios y tres operaciones (lectura, escritura, ejecución) que se pueden otorgar o denegar para cada clase. Cuando se crea un archivo, sus permisos predeterminados son los que se pueden acceder mediante el umaskcomando.
En un sistema de archivos basado en Unix, todo es un archivo, incluso los directorios y otros archivos especiales .
Clases
Las clases determinan cómo se asignan los permisos a un usuario. Los permisos de la clase "usuario" se aplican al usuario propietario del archivo. Los permisos de la clase "grupo" se aplican a los usuarios del grupo propietario del archivo . La clase "otros" se aplica a los demás usuarios.
Los permisos efectivos son los de la clase a la que pertenece el usuario en primer lugar, según el orden: usuario, grupo y luego otros. Por ejemplo, el usuario propietario tiene permisos efectivos de la clase de usuario, incluso si pertenece al grupo propietario.
Permisos
Los siguientes permisos otorgan las operaciones correspondientes sobre archivos y directorios:
Leer (r)
- Para archivos: otorga la capacidad de leer el contenido del archivo (no su nombre ni sus metadatos, que están determinados por los permisos de su directorio principal).
- Para directorios: otorga la capacidad de leer los nombres de las entradas de directorio de los archivos y directorios que contiene, pero no de acceder a sus metadatos ( inodo ) y, por lo tanto, a su contenido, que está determinado por el permiso de ejecución del directorio .
Escribe (w)
- Para archivos: otorga la capacidad de modificar el contenido del archivo.
- Para directorios: otorga la capacidad de modificar las entradas del directorio, lo que permite crear, eliminar y renombrar sus archivos o directorios.
- Para ello, también se requiere el permiso de ejecución para acceder a los metadatos ( inodos ) de todos los archivos y directorios que contiene. Por lo tanto, sin el permiso de ejecución , el permiso de escritura resulta prácticamente inútil.
Ejecutar (x)
- Para archivos: otorga la capacidad de ejecutar un archivo. Este permiso debe configurarse para que los programas ejecutables puedan ejecutarse.
- Para ello también se requiere permiso de lectura .
- Para directorios: otorga la capacidad de leer los metadatos de los archivos y directorios que contiene si se conocen sus nombres, pero no de leer sus nombres. Un directorio sin permiso de ejecución bloquea efectivamente la lectura y escritura del contenido de sus archivos y directorios.
- Un directorio con permiso de ejecución pero sin permiso de lectura convierte, en la práctica, el acceso al contenido de sus archivos y directorios en un auténtico juego de adivinanzas.
Requisito de acceso general dentro de los directorios
Para acceder al contenido de un archivo o directorio dentro de otro directorio se requiere:
- Saber su nombre, que se puede descubrir si se ha configurado el permiso de lectura del directorio padre (o adivinando su nombre).
- El directorio padre tiene permiso de ejecución para acceder al inodo del archivo o directorio .
- Sus permisos correspondientes de lectura , escritura o ejecución .
Resumen de los requisitos de permisos para las operaciones de archivos
Para leer desde un archivo necesitas:
- El archivo tiene permiso de lectura .
- Permiso de ejecución en su directorio padre.
Para escribir en un archivo necesitas:
- El permiso de escritura del archivo.
- Permiso de ejecución en su directorio padre.
Para ejecutar un archivo necesitas:
- Permisos de lectura y ejecución de archivos .
- Permiso de ejecución en su directorio padre.
Para saber el nombre del archivo que necesitas:
- Permiso de lectura de su directorio padre.
Para agregar, eliminar o renombrar un archivo, necesita:
- permisos de escritura y ejecución en su directorio padre.
Notas
Los metadatos de un archivo o directorio suelen incluir el ID del inodo , el tipo de archivo, el tamaño, la propiedad (GUI y UID) y los bits de permisos.
El efecto de establecer los permisos en un directorio, en lugar de en un archivo, es "uno de los problemas de permisos de archivo que más se malinterpretan". [ 21 ]
A diferencia de los sistemas basados en ACL, estos permisos no se heredan. Los archivos creados dentro de un directorio no necesariamente tienen los mismos permisos que el directorio que lo contiene.
Cambiar el comportamiento de los permisos con setuid, setgid y bits persistentes.
A cada archivo se le aplican tres atributos adicionales de un solo bit relacionados con los permisos, que se almacenan en el modo de archivo junto con los permisos.
- El bit setuid o SUID activa el modo de ID de usuario. Al ejecutar un archivo con este bit activado, se crea un proceso con el ID de usuario establecido al usuario propietario del archivo. Esto permite que los usuarios sean tratados temporalmente como root (u otro usuario).
- El bit setgid o SGID establece el ID de grupo . Al ejecutar un archivo con este bit activado, se crea un proceso con el ID de grupo establecido al grupo propietario del archivo. Cuando se aplica a un directorio, los nuevos archivos y directorios creados en él heredan su grupo. (Por defecto, se utiliza el grupo principal del usuario efectivo al establecer el grupo de los nuevos archivos y directorios, excepto en sistemas derivados de BSD, donde el bit setgid se comporta como si siempre estuviera activado en todos los directorios (véase Setuid )).
- El modo persistente (también conocido como modo texto ). El comportamiento clásico del bit persistente en archivos ejecutables ha sido incentivar al núcleo a conservar la imagen del proceso resultante en memoria incluso después de su finalización; sin embargo, este uso del bit persistente ahora se limita a una minoría de sistemas operativos tipo Unix ( HP-UX y UnixWare ). En un directorio, el permiso persistente impide que los usuarios cambien el nombre, muevan o eliminen archivos que pertenezcan a otros usuarios, incluso si tienen permisos de escritura en el directorio. Solo el propietario del directorio y el superusuario están exentos de esta restricción.
Representación
Los permisos se suelen representar mediante notación simbólica u octal.
Notación simbólica
La notación simbólica se utiliza en el formato de salida largo del comando ls -l.
El primer carácter de la salida indica el tipo de archivo Unix , que no es un permiso, aunque aparezca junto a la información de permisos. Los nueve caracteres restantes representan los permisos para el usuario, el grupo y otras clases, como grupos de permisos de operación para lectura, escritura y ejecución. Una operación se deniega cuando se muestra con un guion y se concede cuando se muestra como rlectura, wescritura o xejecución.
Ejemplos:
-rwxr-xr-x: el inicial-indica un archivo regular, los siguientes tresrwxindican que la clase de usuario tiene todos los permisos y el grupo y otras clases (ambasr-x) solo tienen lectura y ejecución.crw-rw-r--: inicialcindica un archivo especial de caracteres, las clases de usuario y grupo (ambasrw-) tienen permisos de lectura y escritura y otras clases (r--) solo tienen permiso de lecturadr-x------: inicialdindica un directorio, la clase de usuario (r-x) tiene permisos de lectura y ejecución y el grupo y otras clases (ambas---) no tienen permisos
Para representar los atributos setuid , setgid y sticky/text , se modifica el carácter en la tercera posición para una clase, aunque esta posición sea solo para ejecutar y aunque estos atributos afecten al archivo sin tener en cuenta la clase. El atributo setuid modifica el carácter de ejecución para la clase de usuario, el atributo setgid modifica el carácter de ejecución para la clase de grupo, y el atributo sticky o text modifica el carácter de ejecución para la clase others. Para setuid o setgid, xse convierte en sy -se convierte en S. Para el atributo sticky o text xse convierte en ty -se convierte en T. Por ejemplo, -rwsr-Sr-tindica un archivo regular, la clase de usuario tiene permisos de lectura, escritura y ejecución; la clase de grupo tiene permiso de lectura; la clase others tiene permisos de lectura y ejecución; y que tiene los atributos setuid , setgid y sticky establecidos.
Algunos sistemas muestran funciones de permisos adicionales:
+El sufijo indica una lista de control de acceso que puede controlar permisos adicionales..El sufijo indica que hay un contexto SELinux presente. Los detalles pueden consultarse con el comando.ls -Z@El sufijo indica que hay atributos de archivo extendidos.
Notación octal
Los permisos suelen mostrarse en notación octal , por ejemplo, mediante el comando stat -c %a. La notación consta de al menos tres dígitos. Los tres últimos dígitos representan el permiso por clase: usuario, grupo y otros. Si hay un cuarto dígito, el de la izquierda representa los tres atributos especiales: setuid , setgid y sticky .
A cada concesión de operación se le asigna una posición de bit que, para un dígito octal, es:
- Lectura: izquierda, binario 100, octal 4
- Escribir: medio, binario 010, octal 2
- Ejecutar: derecha, binario 001, octal 1
El valor de un permiso de clase es la suma o, alternativamente, el resultado de la operación lógica OR de las concesiones.
Ejemplos:
Grupo privado de usuarios
Some systems diverge from the traditional POSIX model of users and groups by creating a new group – a "user private group" – for each user. Assuming that each user is the only member of its user private group, this scheme allows an umask of 002 to be used without allowing other users to write to newly created files in normal directories because such files are assigned to the creating user's private group. However, when sharing files is desirable, the administrator can create a group containing the desired users, create a group-writable directory assigned to the new group, and, most importantly, make the directory setgid. Making it setgid will cause files created in it to be assigned to the same group as the directory and the 002 umask (enabled by using user private groups) will ensure that other members of the group will be able to write to those files.[22][23]
See also
- chattr or chflags – Change attributes or flags including those which restrict access
- chmod – Shell command for changing access permissions of a file
- lsattr– List attributes
- Comparison of file systems § Metadata
References
- ↑"Classic SysAdmin: Understanding Linux File Permissions". Retrieved 18 Jun 2026.
- 123The Compatible Time-Sharing System: A Programmer's Guide(PDF). The MIT Press. 1963.
- ↑The Compatible Time-Sharing System: A Programmer's Guide(PDF) (Second ed.). The MIT Press. 1965. Section AD.2, p. 5.
- 12Multics Programmer's Manual Reference Guide(PDF). Honeywell. December 1975.
- 12TENEX Executive Manual(PDF). BBN. April 1973.
- ↑DECsystem 10 Monitor Calls Manual(PDF). DEC. May 1974.
- ↑Unix Programmer's Manual, System calls, Part 1(PDF). November 3, 1971. SYS CHMOD (II).
- ↑"Tarball of v3 man pages; see stat.2".
- ↑"Tarball of v4 man pages; see stat.2".
- ↑"File and Folder Permissions". Microsoft. 9 December 2009.
- ↑"Native NFSv4 ACLs on Linux". Archived from the original on October 12, 2008. Retrieved May 4, 2010.
- ↑"NFSv4_ACLs – FreeBSD Wiki".
- ↑ "Guía del usuario de FreeNAS 9.1.1" (PDF) . 2013. Archivado del original (PDF) el 24 de septiembre de 2015.
- ↑ Gite, Vivek (3 de junio de 2010). "Apple OS X: Proteger un archivo contra escritura desde la línea de comandos" .
- ↑ "Documentación de OpenVMS" . Archivado del original el 5 de marzo de 2012. Consultado el 6 de junio de 2009 .
- ↑ "Sistemas de archivos: protección" . Diapositivas de la clase CS322 .
- ↑ "Guía de administración de Oracle Solaris ZFS" (PDF) . Septiembre de 2010.
- ↑ "Centro de conocimiento de IBM" .
{{cite web}}: CS1 maint: servicio de archivado obsoleto ( enlace ) - ↑ "Guía de desarrollo del sistema de archivos distribuido HarmonyOS" . Substack . Blog LivingInHarmony. 13 de marzo de 2024. Consultado el 13 de marzo de 2024 .
- ↑ "Definiciones, 3.175 Bits de permisos de archivo" . pubs.opengroup.org . 22 de julio de 2018. Consultado el 24 de junio de 2023 .
- ↑ Hatch, Bri (24 de abril de 2003). "Confusión con los permisos de archivos en Linux, parte 2" . Hacking Linux Exposed . Consultado el 6 de julio de 2011 .
- ↑ Epstein, Brian. "El cómo y el por qué de los grupos privados de usuarios en Unix" . security.ias.edu . Instituto de Estudios Avanzados sobre Seguridad de Redes. Archivado del original el 8 de agosto de 2014. Recuperado el 5 de agosto de 2014 .
- ↑ "Guía del administrador del sistema de Red Hat Enterprise Linux 7, 4.3.4 Creación de directorios de grupo" . Portal del cliente de Red Hat . Red Hat.
Enlaces externos
- El libro de cocina de Linux: Grupos y cómo trabajar en ellos, de Michael Stutz, 2004.
- Permisos del sistema de archivos