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 utiliza 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 de 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 dinámicamente:
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 egidde un proceso también afecta el control de acceso y también puede afectar la creación de archivos, dependiendo de la semántica de la implementación específica del kernel en uso y posiblemente de las opciones de montaje utilizadas. Según la semántica de BSD Unix , la propiedad del grupo otorgada a un archivo recién creado se hereda incondicionalmente de la propiedad del grupo del directorio en el que se crea. Según la semántica de AT&T UNIX System V (también adoptada por las variantes de Linux ), a un archivo recién creado normalmente se le asigna la propiedad del grupo especificada por egidel 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 grupal 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 sólo si , suido euides root. Cada vez que euidse cambia, el cambio se propaga al archivo fsuid.
La intención fsuides permitir que los programas (por ejemplo, el servidor NFS ) se limiten a los derechos del sistema de archivos de algunos 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 fsuidpermanece por razones de compatibilidad. [2]
La ID de usuario guardada se utiliza cuando un programa que se ejecuta con privilegios elevados necesita realizar algún trabajo sin privilegios temporalmente; cambiar euidde un valor privilegiado (normalmente 0) a algún valor sin privilegios (cualquier cosa que no sea el valor privilegiado) hace que el valor privilegiado se almacene en suid. Más adelante, el valor de un programa euidse puede restablecer al valor almacenado en suid, de modo que se puedan restaurar los privilegios elevados; un proceso sin privilegios puede establecerlo 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 señalar otro proceso sólo si el ruido del remitente coincide con el o euiddel receptor . Debido a que un proceso hijo hereda sus credenciales de su padre, un proceso hijo y un padre pueden comunicarse entre síruidsuid
POSIX requiere que el UID sea de tipo entero. La mayoría de los sistemas operativos tipo Unix representan el UID como un número entero sin signo. El tamaño de los valores UID varía entre los diferentes sistemas; algunos sistemas operativos UNIX [ ¿cuáles? ] usaba valores de 15 bits, permitiendo valores de hasta 32767 [ cita necesaria ] , mientras que otros como Linux (antes de la versión 2.4) admitían UID de 16 bits , lo que hacía posibles 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 básica estándar de Linux especifica que los valores de 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 después de la instalación. guiones. [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 central y estáticamente usuarios y grupos en el rango 60000-64999 y reserva además el rango 65000–65533. [4]
Systemd define una serie de rangos de UID especiales, incluidos [5]
En FreeBSD , los usuarios que necesitan un UID para su paquete pueden elegir uno gratuito entre 50 y 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 de UID centrales en redes empresariales (por ejemplo, a través de servidores LDAP y NFS ) pueden limitarse a usar solo números de UID muy por encima de 1000 y fuera del rango 60000–65535, para evitar posibles conflictos con los UID asignados localmente en las computadoras cliente. Cuando se crean nuevos usuarios localmente, se supone que el sistema local debe verificar y evitar conflictos con los UID ya existentes 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 sistema operativo asignen 65536 (2 16 ) UID por contenedor y los asigne agregando un múltiplo entero de 2 16 . [5]
(uid_t) -1POSIX reserva el valor para identificar un argumento omitido. [11]-2otros valores como 2 15 −1 = 32,767, como por ejemplo OpenBSD . [12] Para compatibilidad entre UID de 16 y 32 bits, muchas distribuciones de Linux ahora lo configuran en 2 16 −2 = 65,534; El kernel de Linux devuelve este valor de forma predeterminada cuando un UID de 32 bits no cabe en el valor de retorno de las llamadas al sistema de 16 bits. [13] Fedora Linux asigna el último UID del rango asignado estáticamente para uso del sistema (0–99) a nadie: 99, y llama a 65534 en su lugar nfsnobody.NFSv4 tenía como objetivo ayudar a evitar colisiones de identificadores numéricos mediante la identificación de usuarios (y grupos) en paquetes de protocolo utilizando nombres textuales "usuario@dominio" en lugar de números enteros. Sin embargo, mientras los kernels del sistema operativo 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 las bases de datos o los mecanismos de mapeo de UID locales fallan. configurado incorrectamente, perdido o no sincronizado. 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 sólo permiten establecer el dominio NFSv4 en un valor fijo, haciéndolo inútil.