Múltiples cuentas * NIX con UID idéntico

Tengo curiosidad por saber si existe un comportamiento estándar esperado y si se considera una mala práctica al crear más de una cuenta en Linux / Unix que tiene el mismo UID. He hecho algunas pruebas en RHEL5 con esto y se comportó como esperaba, pero no sé si estoy tentando al destino con este truco.

Como ejemplo, digamos que tengo dos cuentas con las mismas ID:

a1:$1$4zIl1:5000:5000::/home/a1:/bin/bash
a2:$1$bmh92:5000:5000::/home/a2:/bin/bash

Lo que esto significa es:

• Puedo iniciar sesión en cada cuenta con su propia contraseña.
• Los archivos que creo tendrán el mismo UID.
• Herramientas como "ls -l" enumerarán el UID como la primera entrada en el archivo (a1 en este caso).
• Evito cualquier problema de permisos o propiedad entre las dos cuentas porque realmente son el mismo usuario.
• Obtengo una auditoría de inicio de sesión para cada cuenta, por lo que tengo una mayor granularidad en el seguimiento de lo que está sucediendo en el sistema.

Entonces mis preguntas son:

• ¿Esta habilidad está diseñada o es solo la forma en que funciona?
• ¿Será esto consistente en las variantes * nix?
• ¿Es esta práctica aceptada?
• ¿Hay consecuencias no deseadas en esta práctica?

Tenga en cuenta que la idea aquí es usar esto para cuentas del sistema y no para cuentas de usuario normales.

Mi opinión:

¿Esta habilidad está diseñada o es solo la forma en que funciona?

Está diseñado Desde que comencé a usar * NIX, ha podido colocar usuarios en grupos comunes. La posibilidad de que el UID sea el mismo sin problemas es solo un resultado previsto que, como todo, podría traer problemas si se maneja incorrectamente.

¿Será esto consistente en las variantes * nix?

Eso creo.

¿Es esta práctica aceptada?

Aceptado como se usa generalmente de una forma u otra, sí.

¿Hay consecuencias no deseadas en esta práctica?

Aparte de la auditoría de inicio de sesión, no tiene nada más. A menos que quisieras exactamente eso, para empezar.

¿Funcionará en todos los Unixes? Si.

¿Es una buena técnica para usar? No. Hay otras técnicas que son mejores. Por ejemplo, el uso adecuado de grupos unix y configuraciones "sudo" estrictamente controladas pueden lograr lo mismo.

He visto exactamente un lugar donde esto se usó sin problemas. En FreeBSD es tradicional crear una segunda cuenta raíz llamada "toor" (raíz deletreada al revés) que tiene / bin / sh como el shell predeterminado. De esta manera, si el shell de root se estropea, aún puede iniciar sesión.

No puedo proporcionar una respuesta canónica a sus preguntas, pero anecdóticamente mi empresa ha estado haciendo esto durante años con el usuario root y nunca ha tenido ningún problema. Creamos un usuario 'kroot' (UID 0) cuya única razón de existencia es tener / bin / ksh como shell en lugar de / bin / sh o bin / bash. Sé que nuestros DBA de Oracle hacen algo similar con sus usuarios, tienen 3 o 4 nombres de usuario por instalación, todos con los mismos ID de usuario (creo que esto se hizo para tener directorios de inicio separados con cada usuario. Hemos estado haciendo esto al menos durante diez años, en Solaris y Linux, creo que funciona según lo diseñado.

No haría esto con una cuenta de usuario normal. Como notó, después del inicio de sesión inicial, todo vuelve al nombre en el archivo de registro, por lo que creo que las acciones de un usuario podrían enmascararse como las acciones de otro en los registros. Para las cuentas del sistema, aunque funciona muy bien.

¿Esta habilidad está diseñada o es solo la forma en que funciona?

Diseñado de esa manera.

¿Será esto consistente en las variantes * nix?

Debería, sí.

¿Es esta práctica aceptada?

Depende de lo que quieras decir. Este tipo de cosas responde a un problema extremadamente específico (ver cuentas raíz / toor). En cualquier otro lugar y estás pidiendo un problema estúpido en el futuro. Si no está seguro de si esta es la solución correcta, probablemente no lo sea.

¿Hay consecuencias no deseadas en esta práctica?

Es costumbre general tratar los nombres de usuario y UID como intercambiables. Como señalaron algunas otras personas, las auditorías de inicio de sesión / actividad serán inexactas. También querrá revisar el comportamiento de los scripts / programas relevantes relacionados con el usuario (useradd, usermod, scripts de userdel de su distribución, cualquier script de mantenimiento periódico, etc.).

¿Qué está tratando de lograr con esto que no se lograría agregando estos dos usuarios a un nuevo grupo y otorgándole a ese grupo los permisos que necesita?

¿Hay consecuencias no deseadas en esta práctica?

Hay un problema que conozco. Cron no juega bien con este alias de UID. Intente ejecutar "crontab -i" desde un script Python para actualizar las entradas cron. Luego ejecute "crontab -e" en el shell para modificar el mismo.

Tenga en cuenta que ahora cron (vixie, creo) habrá actualizado las mismas entradas para a1 y a2 (en / var / spool / cron / a1 y / var / spool / cron / a2).

Este es el comportamiento esperado en todas las distribuciones que he visto, y es un truco común que 'el enemigo' usa para ocultar cuentas con acceso de root.

Ciertamente no es estándar (no he visto esto en juego en ninguna parte), pero no debería haber ninguna razón por la que no pueda usar esto en su propio entorno si lo cree conveniente.

El único problema que se me ocurre en este momento es que esto podría dificultar la auditoría. Si tiene dos usuarios con el mismo uid / gid, creo que le resultará difícil descubrir cuál hizo qué cuando analiza los registros.

Compartir ID de grupo primario es común, por lo que la pregunta realmente gira en torno al UID .

He hecho esto antes para dar acceso a alguien a la raíz, sin tener que divulgar la contraseña de root, que ha funcionado bien. (aunque sudo habría sido una mejor opción, creo)

Lo principal con lo que sería cauteloso es cosas como eliminar uno de los usuarios: el programa puede confundirse y eliminar ambos usuarios, o archivos que pertenecen a ambos, o cosas similares.

De hecho, creo que los programadores probablemente asuman una relación 1: 1 entre el usuario y el UID, por lo que podría haber consecuencias inesperadas con otros programas similares a los que he descrito para userdel.

Por cierto, esta pregunta / respuesta actualizada para los sistemas operativos de hoy.

Citando de redhat: administrando asignaciones únicas de números UID y GID , describe el uso de UID y GID y su administración y cómo los generadores (servidores de ID)

debe generar valores aleatorios de UID y GID y simultáneamente garantizar que las réplicas nunca generen el mismo valor de UID o GID. La necesidad de números únicos de UID y GID podría incluso cruzar dominios IdM, si una sola organización tiene múltiples dominios dispares.

Del mismo modo, las utilidades que permiten el acceso al sistema pueden comportarse de manera impredecible (misma referencia):

Si a dos entradas se les asigna el mismo número de ID, solo se devuelve la primera entrada en una búsqueda de ese número.

El problema surge cuando el concepto de "primero" está mal definido. Dependiendo del servicio instalado, los nombres de usuario pueden mantenerse en un hash de tamaño variable que devolvería un nombre de usuario diferente en función de factores inconsistentes. (Sé que esto es cierto, ya que a veces he tratado de usar 2 nombres de usuario con una ID, uno es un nombre de usuario local y el otro es un dominio. Nombre de usuario que quería asignar al UID (que eventualmente abordé en una manera completamente diferente), pero podría iniciar sesión con "usera", hacer un "who" o "id" y ver "userb" O "usera" - al azar.

Hay una interfaz para recuperar múltiples valores de UID de un grupo (los grupos con un solo GID están diseñados para asociarse con múltiples UID), pero no hay una interfaz portátil para devolver una lista de nombres para un UID, por lo que cualquiera que espere lo mismo o un comportamiento similar entre sistemas o incluso aplicaciones en el mismo sistema puede ser desafortunadamente sorprendido.

En el Sol (ahora oráculo) yp (páginas amarillas) o NIS (NetworkInformationServices), también hay muchas referencias a requisitos de unicidad. Las funciones y servidores especiales se configuran para asignar identificaciones únicas en varios servidores y dominios (por ejemplo, el , uid_allocd, gid_allocd - página de manual de demonios UID y GID allocator)

Una tercera fuente que se puede verificar es la documentación del servidor de Microsoft para la asignación de cuentas NFS. NFS es un protocolo de uso compartido de archivos Unix y describen cómo la ID mantiene los permisos y el acceso a los archivos. Allí escriben:

• UID Este es un entero sin signo utilizado por los sistemas operativos UNIX para identificar a los usuarios y debe ser único en el archivo passwd.

• GID Este es un entero sin signo utilizado por el núcleo de UNIX para identificar grupos y debe ser único en el archivo de grupo. Página de administración de MS-NFS

Si bien algunos sistemas operativos pueden haber permitido múltiples nombres / UID (¿derivados de BSD, tal vez?), La mayoría de los sistemas operativos dependen de que esto sea único y pueden comportarse de manera impredecible cuando no lo son.

Nota: estoy agregando esta página, ya que alguien se refirió a esta entrada fechada como soporte para utilidades modernas para acomodar UID / GID no únicos ... que la mayoría, no.

Tampoco sé si es una buena idea o no, pero uso el comportamiento anterior en algunos lugares. Principalmente es para cuentas que se usaron para acceder al servidor ftp / sftp y actualizar el contenido del sitio web. No parecía romper nada y parecía facilitar el manejo de los permisos, entonces habría sido con varias cuentas.

Me encontré con un problema (bastante oscuro) derivado del uso de varias cuentas con el mismo UID, y pensé en compartirlo como un ejemplo de por qué esto no es una buena práctica.

En mi caso, un proveedor configuró un servidor de base de datos Informix y un servidor de aplicaciones web en RHEL 7. Durante la configuración, se crearon varias cuentas "raíz" con UID 0 (no me pregunte por qué). Es decir, "root", "user1" y "user2", todos con UID 0.

El servidor RHEL 7 se unió más tarde a un dominio de Active Directory usando winbind. En este punto, el servidor Informix DB ya no podría iniciarse. La ejecución oninitestaba fallando con un mensaje de error que decía que uno"Must be a DBSA to run this program" .

Esto es lo que encontramos al solucionar problemas:

1. La ejecución id rooto getent passwd 0(para resolver el UID 0 en un nombre de usuario) en un sistema unido a Active Directory devolvería aleatoriamente "usuario1" o "usuario2" en lugar de "raíz".

2. Aparentemente, Informix confiaba en una comparación de cadenas para verificar si el nombre de usuario textual del usuario que lo iniciaba era "root" y no funcionaría de otra manera.

3. Sin winbind, id rooty getent passwd 0constantemente devolvería "root" como nombre de usuario.

La solución fue deshabilitar el almacenamiento en caché y la persistencia en /etc/nscd.conf:

enable-cache    passwd      no
persistent      passwd      no

Después de este cambio, el UID 0 una vez más se resolvió constantemente a "root" e Informix podría comenzar.

Espero que esto sea útil para alguien.