Los sistemas operativos tipo Unix identifican a un usuario mediante un valor llamado identificador de usuario , a menudo abreviado como ID de usuario o UID . El UID, junto con el identificador de grupo (GID) y otros criterios de control de acceso, se utilizan para determinar a qué recursos del sistema puede acceder un usuario. El archivo de contraseñas asigna nombres de usuario textuales a UID. Los UID se almacenan en los inodos del sistema de archivos Unix , procesos en ejecución, archivos tar y el ahora obsoleto Servicio de información de red . En entornos compatibles con POSIX , el comando shell proporciona el UID del usuario actual, así como más información como el nombre de usuario, el grupo de usuarios principal y el identificador de grupo (GID). id
El estándar POSIX introdujo tres campos UID diferentes en la tabla de descriptores de procesos, para permitir que los procesos privilegiados asuman diferentes roles de forma dinámica:
El UID efectivo ( euid) de un proceso se utiliza para la mayoría de las comprobaciones de acceso. También se utiliza como propietario de los archivos creados por ese proceso. El GID efectivo ( egid) de un proceso también afecta al control de acceso y también puede afectar a la creación de archivos, dependiendo de la semántica de la implementación específica del núcleo en uso y posiblemente de las opciones de montaje utilizadas. Según la semántica BSD Unix , la propiedad de grupo dada a un archivo recién creado se hereda incondicionalmente de la propiedad de grupo del directorio en el que se crea. Según la semántica AT&T UNIX System V (también adoptada por las variantes de Linux ), a un archivo recién creado normalmente se le da la propiedad de grupo especificada por el egiddel proceso que crea el archivo. La mayoría de los sistemas de archivos implementan un método para seleccionar si se debe utilizar la semántica BSD o AT&T con respecto a la propiedad de grupo de un archivo recién creado; la semántica BSD se selecciona para directorios específicos cuando se establece el permiso S_ISGID (s-gid). [1]
Linux también tiene un ID de usuario del sistema de archivos ( fsuid) que se utiliza explícitamente para el control de acceso al sistema de archivos. Coincide con el euida menos que se establezca explícitamente lo contrario. Puede ser el ID de usuario de rootruid solo si , suido euides root. Siempre que euidse cambia el , el cambio se propaga al fsuid.
La intención de fsuides permitir que los programas (por ejemplo, el servidor NFS ) se limiten a los derechos del sistema de archivos de algunos usuarios uidsin darles uidpermiso para enviarles señales. Desde el kernel 2.0, la existencia de fsuidya no es necesaria porque Linux se adhiere a las reglas SUSv3 para enviar señales, pero fsuidse mantiene por razones de compatibilidad. [2]
El ID de usuario guardado se utiliza cuando un programa que se ejecuta con privilegios elevados necesita realizar temporalmente algún trabajo sin privilegios; cambiar euidde un valor privilegiado (normalmente 0) a un valor sin privilegios (cualquier valor distinto del valor privilegiado) hace que el valor privilegiado se almacene en suid. Más tarde, el ID de un programa euidse puede volver a establecer en el valor almacenado en suid, de modo que se puedan restaurar los privilegios elevados; un proceso sin privilegios puede establecer su euiden uno de solo tres valores: el valor de ruid, el valor de suido el valor de euid.
El UID real ( ruid) y el GID real ( rgid) identifican al propietario real del proceso y afectan los permisos para enviar señales. Un proceso sin privilegios de superusuario puede enviar señales a otro proceso solo si el ruido del remitente coincide con el o euiddel receptor . Debido a que un proceso secundario hereda sus credenciales de su padre, un proceso secundario y un proceso primario pueden enviarse señales entre sí.ruidsuid
POSIX requiere que el UID sea un tipo entero. La mayoría de los sistemas operativos tipo Unix representan el UID como un entero sin signo. El tamaño de los valores de UID varía entre los diferentes sistemas; algunos sistemas operativos UNIX [ ¿cuáles? ] usaban valores de 15 bits, lo que permitía valores de hasta 32767 [ cita requerida ] , mientras que otros, como Linux (antes de la versión 2.4), admitían UID de 16 bits , lo que hacía posible 65536 ID únicos. La mayoría de los sistemas modernos tipo Unix (por ejemplo, Solaris 2.0 en 1990, Linux 2.4 en 2001) han cambiado a UID de 32 bits , lo que permite 4.294.967.296 (2 32 ) ID únicos.
La especificación básica estándar de Linux especifica que los valores UID en el rango de 0 a 99 deben ser asignados estáticamente por el sistema y no deben ser creados por aplicaciones, mientras que los UID de 100 a 499 deben reservarse para la asignación dinámica por parte de los administradores del sistema y los scripts posteriores a la instalación. [3]
Debian Linux no sólo reserva el rango 100–999 para usuarios y grupos del sistema asignados dinámicamente, sino que también asigna de forma central y estática usuarios y grupos en el rango 60000–64999 y además reserva el rango 65000–65533. [4]
Systemd define una serie de rangos de UID especiales, incluidos [5]
En FreeBSD , los porteadores que necesitan un UID para su paquete pueden elegir uno gratuito del rango 50 a 999 y luego registrar la asignación estática. [6] [7]
Algunos sistemas POSIX asignan UID para nuevos usuarios a partir de 500 ( macOS , Red Hat Enterprise Linux hasta la versión 6), otros comienzan en 1000 (Red Hat Enterprise Linux desde la versión 7, [8] openSUSE , Debian [4] ). En muchos sistemas Linux, estos rangos se especifican en /etc/login.defs, for useraddy herramientas similares.
Las asignaciones centrales de UID en redes empresariales (por ejemplo, a través de servidores LDAP y NFS ) pueden limitarse a utilizar únicamente números de UID muy superiores a 1000 y fuera del rango 60000–65535, para evitar posibles conflictos con los UID asignados localmente en los equipos cliente. Cuando se crean nuevos usuarios localmente, se supone que el sistema local debe verificar y evitar conflictos con los UID que ya existen en NSS [9].
La virtualización a nivel de sistema operativo puede reasignar identificadores de usuario, por ejemplo, utilizando espacios de nombres de Linux , y por lo tanto necesita asignar rangos en los que se asignan los UID y GID reasignados:
Los autores de systemd recomiendan que los sistemas de virtualización a nivel de SO asignen 65536 (2 16 ) UID por contenedor y los mapeen sumando un múltiplo entero de 2 16 . [5]
(uid_t) -1está reservado por POSIX para identificar un argumento omitido. [11]-2otros valores como 2 15 −1 = 32,767, como por ejemplo en OpenBSD . [12] Para compatibilidad entre UID de 16 y 32 bits, muchas distribuciones de Linux ahora lo establecen en 2 16 −2 = 65,534; el kernel de Linux devuelve este valor por defecto cuando un UID de 32 bits no encaja en el valor de retorno de las llamadas del sistema de 16 bits. [13] Fedora Linux asigna el último UID del rango asignado estáticamente para uso del sistema (0–99) a nobody: 99, y llama a 65534 en su lugar nfsnobody.NFSv4 fue pensado para ayudar a evitar colisiones de identificadores numéricos al identificar usuarios (y grupos) en paquetes de protocolo usando nombres textuales “usuario@dominio” en lugar de números enteros. Sin embargo, mientras los núcleos de los sistemas operativos y los sistemas de archivos locales sigan usando identificadores de usuario enteros, esto se produce a expensas de pasos de traducción adicionales (usando procesos de demonio idmap), que pueden introducir puntos de falla adicionales si los mecanismos de mapeo de UID locales o las bases de datos se configuran incorrectamente, se pierden o no están sincronizados. La parte “@dominio” del nombre de usuario podría usarse para indicar qué autoridad asignó un nombre en particular, por ejemplo en forma de
Pero en la práctica, muchas implementaciones existentes solo permiten configurar el dominio NFSv4 con un valor fijo, lo que lo vuelve inútil.