¿Por qué puedo crear usuarios con el mismo UID?

Mi comprensión de los UID es que es un número entero positivo único asignado por un sistema operativo tipo Unix a cada usuario. Cada usuario se identifica con el sistema mediante su UID, y los nombres de usuario generalmente se usan solo como una interfaz para humanos.

¿Cómo pueden dos usuarios tener el mismo UID? ¿No es un conflicto para mi sistema y mis paquetes?

root@kdc:~# id test12
uid=1005(test10) gid=1000(server) groups=1005(test10)
root@kdc:~# id test13
uid=1005(test10) gid=1000(server) groups=1005(test10)
root@kdc:~#

He agregado dos usuarios con el mismo UID y GID: test12y test13

La salida de /etc/passwd:

client@kdc:~$ cat /etc/passwd | grep test12
test12:x:1005:1000::/home/test12:/bin/sh
client@kdc:~$ cat /etc/passwd | grep test13
test13:x:1005:1000::/home/test13:/bin/sh

Agregué los usuarios por useradd -ou 1005 -g1000 username.

Me confundí cuál es el propósito de esto, y ¿puede afectar los permisos y los registros de usuarios, etc. Entonces, si un usuario se agrega uid=0y gid=0tiene privilegios como una cuenta raíz?

La respuesta aquí es que Linux no te protege de ti mismo.

Si realmente quiere su rootacceder a los archivos / etc y dar a todos los usuarios el mismo UID, puede hacerlo. Es solo un archivo de texto.

Pero realmente no debería y tendrá consecuencias no deseadas.

En realidad, hay razones válidas para esto. Por ejemplo, solía trabajar en un laboratorio donde cada uno tenía su propia computadora, pero la nuestra $HOMEestaba en una unidad compartida exportada por un servidor. Entonces, mi $HOMEera

/users/terdon

Dado que la /userscarpeta en realidad no estaba en mi máquina local, sino que se exportaba a través de NFS, para cualquier análisis que fuera pesado en E / S, usaría los datos almacenados en mis discos duros locales para no cargar la red del laboratorio. Para ese fin, yo y todos los demás, teníamos dos usuarios: uno para todo el sistema y otro para la máquina en cuestión. La casa del usuario local era

/home/localuser

Sin embargo, necesitaba tener acceso completo a mis archivos, ya sea que haya iniciado sesión como terdono como localusery la forma en que nuestro administrador de sistemas lo implementó fue dando ambos localusery terdonel mismo UID. De esa manera, podría manipular libremente mis archivos locales independientemente del usuario con el que estaba conectado actualmente.

Dos usuarios pueden tener el mismo UID porque es solo un número en un archivo de texto, por lo que puede configurarlo para lo que desee, incluido un valor que ya se utiliza. Sin embargo, como has visto, hacerlo no es una buena idea.

En realidad, es bastante común tener dos usuarios con la misma ID. En FreeBSD, generalmente hay dos usuarios con UID 0: root y toor. Root usa el shell incorporado / bin / sh, y toor usa un shell diferente, generalmente bash.

Los sistemas Unix y Linux generalmente no hacen nada para prohibir duplicados en el /etc/passwdarchivo. La intención de este archivo es asociar un UID con un nombre físico que pueda mostrarse mediante herramientas de línea de comandos, como lscuando el usuario enumera archivos.

$ ls -n | head -5
total 986000
drwxrwxr-x.   3 1000 1000      4096 Feb 13 19:51 1_archive_sansa
-rw-rw-r--.   1 1000 1000    760868 Dec 16 08:21 2.18.x Database Scheme.jpg
-rw-rw-r--.   1 1000 1000       972 Oct  6 20:26 abcdefg
drwxrwxr-x.   2 1000 1000      4096 Feb 11 03:34 advanced_linux_programming

El otro propósito previsto de este archivo es especificar qué shell obtendrá un usuario cuando inicie sesión.

$ getent passwd saml
saml:x:1000:1000:saml:/home/saml:/bin/bash

Un vector de ataque común en los sistemas de tipo Unix es agregar líneas como estas al /etc/passwdarchivo de un sistema :

$ getent passwd r00t
r00t:x:0:0:root:/root:/bin/bash

$ getent passwd toor
toor:x:0:0:root:/root:/bin/bash

El rol del /etc/passwdarchivo NO está destinado únicamente a rastrear cuentas de usuario. La función de rastrear nombres de usuario y contraseñas es responsabilidad del /etc/shadowarchivo. Los archivos como /etc/passwdy /etc/grouprealmente están destinados a proporcionar un nombre legible por humanos cuando su sistema enumera archivos de discos.

Recuerde que sus archivos se escriben en el disco utilizando nombres no reales de UID / GID.

$ stat afile 
  File: ‘afile’
  Size: 0           Blocks: 0          IO Block: 4096   regular empty file
Device: fd02h/64770d    Inode: 6560621     Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1000/    saml)   Gid: ( 1000/    saml)
Context: unconfined_u:object_r:user_home_t:s0
Access: 2014-02-27 15:54:21.852697029 -0500
Modify: 2014-02-27 15:54:21.852697029 -0500
Change: 2014-02-27 15:54:21.852697029 -0500
 Birth: -

¡Observe el Uid:y Gid:, los números son lo que realmente está escrito en el disco!

En Linux, todos los usuarios y grupos son en realidad solo números. Eso es lo idque muestra la salida del comando que publicaste.

El /etc/passwdarchivo asigna nombres de usuario a ID de usuario (números) y, en el ejemplo que ha proporcionado, simplemente ha asignado dos nombres de usuario a la misma ID de usuario.

Efectivamente, ha creado un usuario, test12ID 1005, que también tiene un segundo nombre de usuario test13. Sin embargo, el sistema asignará el UID 1005 al primer nombre de usuario que encuentre, que seríatest12

Linux "te permite" hacer esto porque no hay un sistema que te impida hacerlo. /etc/passwdes solo un archivo de texto, los nombres de usuario se asignan al UID encontrado para su entrada en ese archivo, los UID se asignan al primer nombre de usuario encontrado en ese archivo.

Pero lo que ha creado es una situación confusa para otros administradores de systams; evítelo cambiando el UID detest13

La razón por la que esto está permitido hoy es simplemente porque el sistema no lo impide.

Si esto cambiara, entonces rompería aquellos sistemas en los que los administradores hayan tenido un uso para esta función (ver el ejemplo de Terdon). Por lo tanto, nunca se ha cambiado, y no creo que lo haga nunca.

Originalmente solo existían los archivos passwd y group, y cumplieron su propósito. no había comando adduser , no addgroup , los archivos fueron editados por root usando vi o ed.

¡Hubo algunas peculiaridades!

Para recordar el próximo ID de usuario que se debe usar, era común que los administradores tuvieran un usuario especial como la última línea que tenía un nombre de usuario !(porque !era un nombre de usuario no válido) y esa entrada se usaba para almacenar el siguiente ID de usuario. Crudo, lo admito, ¡pero funcionó! Entonces, ¿por qué reventar un intestino que lo hace más complicado, similar al desarrollo ágil de hoy?

Había defectos conocidos. El ser principal, que tenía que ser legible en todo el mundo, para que las empresas de servicios públicos lspudieran mapear user-id => name. Esto significaba que cualquiera podía ver la contraseña cifrada de todos, y todos los usuarios e identificaciones en el sistema.

Algunos sistemas Unix comenzaron a introducir un par de scripts de shell adduser addgroup, a menudo estos fueron ignorados, porque eran inconsistentes entre Unixes, por lo que la mayoría de las personas simplemente continuaron con la edición manual.

Pasaron algunos años, antes de shadowque se inventara el archivo de contraseña, esto proporcionó un poco más de seguridad, al ocultar las contraseñas cifradas. Una vez más, se agregó la complejidad suficiente, pero aún era bastante tosco y simple. Se introdujeron las utilidades useraddy groupaddse mantuvieron shadowy shadow-actualizaron. Para empezar, estos a menudo eran simples envoltorios de script de shell alrededor de las utilidades de adduser / addgroup patentadas de los proveedores . Nuevamente, fue suficiente para continuar.

Las redes de computadoras estaban creciendo, la gente trabajaba en varias a la vez para hacer el trabajo, por lo que la administración de los passwd/grouparchivos se estaba convirtiendo en una pesadilla, especialmente con NFS, por lo que aparecen las Páginas Amarillas, también conocidas como NIS, para aliviar la carga.

Se estaba volviendo obvio ahora que se necesitaba algo un poco más flexible, y se inventó PAM. Por lo tanto, si usted fuera realmente sofisticado y quisiera un sistema de autenticación centralizado, seguro, con id. Único, con todas las características, debería llamar a un servidor central para autenticar, tal vez un servidor Radius, un servidor LDAP o un directorio activo.

El mundo había crecido. Pero los archivos passwd / group / shadow aún permanecían para nosotros los usuarios / desarrolladores / laboratorios más pequeños. Todavía no necesitábamos todas las campanas y silbatos. Supongo que la filosofía había cambiado un poco a estas alturas, "Si lo mejoraras, no lo usarías en absoluto" , así que no te preocupes por eso.

Es por eso que no creo que el simple archivo passwd cambie alguna vez. Ya no tiene sentido, y es genial para esos £ 30 Raspberry Pi con 2 quizás 3 temperatura de monitoreo del usuario y feeds de Twitter. OK, solo debe tener un poco de cuidado con su ID de usuario si desea que sean únicos, y no hay nada que impida al entusiasta envolver useradd en un script que primero selecciona el siguiente ID único de una base de datos (archivo) para establecer un Identificación única, si eso es lo que quieres. Es de código abierto después de todo.

El /etc/passwdarchivo solo asigna nombres de usuario simbólicos al ID de usuario real. Si deliberadamente haces dos nombres simbólicos que se asignan a un ID de usuario, entonces te lo permitirá.

Eso no significa que sea una buena idea hacerlo realmente. Algunas personas pueden haber encontrado casos de uso muy específicos en los que pueden aprovechar esta característica, pero en general no debe hacerlo.

Linux (y otros UNIX) consideran que el administrador sabe lo que está haciendo. Si le dices que haga algo estúpido, entonces es tu culpa, de la misma manera que si le dices a tu auto que conduzca por un acantilado, no puedes ir a los fabricantes y preguntar por qué el auto te permitió hacer esto.

Hay identificadores que el sistema operativo espera que sean únicos, pero se usan para rastrear el hardware. El conocimiento de que un IDentifier universalmente particular corresponde a un disco duro que contiene archivos del sistema puede ayudarlo a continuar funcionando si cambia la configuración del hardware. Microsoft llama a estos IDentifiers Globally Unique y los usa para rastrear todo el software de Windows. Irónicamente, estos acrónimos fueron mal elegidos.

Desde la perspectiva del sistema operativo, la mayoría de los cambios de identificador de usuario y grupo equivalen a cambiar su interfaz externa. Podría funcionar normalmente a pesar de las colisiones; principalmente lo que se requiere de los usuarios y grupos del sistema es que existan. No puede saber qué requieren los usuarios. En situaciones como esta, la filosofía de Unix es que el sistema operativo debería asumir que los administradores saben lo que están haciendo, y debería ayudarlos a hacerlo rápidamente.

Encontré algunas pruebas que respaldan la respuesta de @andybalholm.

De APUE , §8.15:

Cualquier proceso puede encontrar su ID de usuario real y efectiva e ID de grupo. A veces, sin embargo, queremos averiguar el nombre de inicio de sesión del usuario que ejecuta el programa. Podríamos llamar a getpwuid( getuid()), pero ¿qué pasa si un solo usuario tiene varios nombres de inicio de sesión, cada uno con la misma ID de usuario? ( Una persona puede tener múltiples entradas en el archivo de contraseña con la misma ID de usuario para tener un shell de inicio de sesión diferente para cada entrada ). El sistema normalmente realiza un seguimiento del nombre con el que iniciamos sesión en (Sección 6.8), y la getloginfunción proporciona una manera para buscar ese nombre de usuario.

....

Dado el nombre de inicio de sesión, podemos usarlo para buscar al usuario en el archivo de contraseña, para determinar el shell de inicio de sesión, por ejemplo, usando getpwnam.

Por cierto, me gustaría saber si uno puede cambiar a otro shell mientras está conectado.