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

37

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?

nux
fuente
No estoy seguro, pero creo que la salida está imprimiendo el UID del usuario "test10" en ambos comandos. Por qué está haciendo eso, no tengo idea, pero debe ser algún usuario que hayas creado anteriormente.
animaletdesequia
como si dijera que hay un usuario que tiene esta identificación
nux
OK, entendí mal la pregunta. Pensé que creaste a los usuarios normalmente y que el sistema les asignó el mismo UID.
animaletdesequia
ningún hombre no normalmente, la pregunta aquí, cómo el sistema acepta uids únicos
nux
Lo tengo. Buena pregunta entonces, gracias por la explicación :)
animaletdesequia

Respuestas:

40

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.

Chris digital
fuente
44
mi pregunta es ¿por qué el sistema acepta esto?
nux
46
¿Qué quieres decir con "aceptar"? ¿Cómo NO lo aceptaría? Esto es como ser un chef y preguntar por qué la sopa le permitió ponerle demasiada sal. En términos de computación moderna, probablemente esté acostumbrado a una mentalidad RDBMS, donde las improntas en cosas importantes como las identificaciones evitan que se dispare en el pie. Las ID de usuario de Linux son mucho más primitivas y no tienen verificación o corrección interna.
Digital Chris
55
Correcto, y al usarlo useradd -o, reconoce que está fuera de la norma adduser. Como @psusi mencionó, crea dos inicios de sesión que apuntan a la misma ID en cuanto a permisos de archivos, etc. Probablemente también crea problemas, ya que ese no es un caso de uso normal y, sin duda, no se ha probado con muchos paquetes.
Digital Chris
2
Respuesta: tener 2 inicios de sesión apunta a permisos idénticos del sistema de archivos.
Chris digital
55
@Josh, por supuesto que sí, hay razones válidas para tener varios usuarios con el mismo UID; consulte mi respuesta para ver un ejemplo.
terdon
38

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.

terdon
fuente
66
Para respaldar esta respuesta, vale la pena señalar que algunas configuraciones, como el alojamiento de correo electrónico virtual, usan esto con gran efecto, es decir, una gran cantidad de cuentas de correo electrónico virtuales que comparten un único UID; la documentación para el servidor de correo Dovecot realmente sugiere esto como un enfoque opcional. en wiki2.dovecot.org/UserIds#mailusers
Matt Thomason
no chmod 666tendría los mismos efectos?
Brian
3
@GIJoe que permitiría a ambos usuarios leer / escribir pero no preservaría la propiedad, lo que podría ser un problema. Además, no todos los archivos se pueden configurar con esos permisos (por ejemplo, las teclas ssh) y no es práctico jugar con permisos todo el tiempo.
terdon
12

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.

psusi
fuente
¿Cómo trata el sistema con los usuarios entonces? compartir permisos
nux
12
@nux, ambos son el mismo usuario. Ellos sólo pueden tener un nombre de usuario / contraseña diferente con el propósito de iniciar sesión.
psusi
44
@ bigbadonk420, el término "compatible" es bastante nebuloso. Ciertamente es algo que siempre ha podido hacer en sistemas Unix y solía ser una puerta trasera bastante común para configurar otro usuario que tiene uid 0 para que pueda iniciar sesión y efectivamente ser root, sin necesidad de saber o cambiar la contraseña en el usuario root normal.
psusi
1
@ bigbadonk420 es compatible, hay casos en que esto es útil, vea mi respuesta para ver un ejemplo.
terdon
11

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.

andybalholm
fuente
11

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!

slm
fuente
9

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

Josh
fuente
esta es mi máquina virtual de prueba, mi pregunta es si hay un propósito para asignar dos usuarios para el mismo uid
nux
1
El único propósito que se me ocurre es darle a un UID un segundo nombre de usuario con alias. Pero este es un comportamiento indefinido y no recomendado. Realmente esta es una situación indeseable: estás mejor con una relación 1: 1 entre los nombres de usuario y los UID
Josh
es por eso que hice esta pregunta que necesitaba saber, sentí que es una forma confusa
nux
Es confuso; Por eso no deberías hacerlo. No tiene un "propósito", es más un mal uso del /etc/passwdarchivo. Pero no hay medios para evitar que lo haga. ¿Tiene sentido?
Josh
1
un usuario mencionó que el objetivo es hacer que 2 inicios de sesión apunten a permisos idénticos del sistema de archivos.
nux
5

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.

X Tian
fuente
2

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.

usuario253158
fuente
¿Por qué fue mencionado como un error?
nux
1

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.

usuario130144
fuente
0

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.

Almiar
fuente