it-swarm-es.com

Varias 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. Hice 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 los mismos 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 cree tendrán el mismo UID.
  • Herramientas como "ls -l" mostrarán el UID como la primera entrada en el archivo (a1 en este caso).
  • Evito problemas de permisos o de propiedad entre las dos cuentas porque en realidad son el mismo usuario.
  • Recibo auditoría de inicio de sesión para cada cuenta, por lo que tengo una mejor granularidad para rastrear lo que está sucediendo en el sistema.

Entonces mis preguntas son:

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

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

14
Tim

Mi opinión:

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

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

¿Va a ser coherente en todas las variantes * nix?

Eso creo.

¿Es esta práctica aceptada?

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

¿Esta práctica tiene consecuencias no deseadas?

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

8
user1797

¿Funcionará en todos los Unix? 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 se usó sin problemas. En FreeBSD es tradicional crear una segunda cuenta de root llamada "toor" (root escrito 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.

7
TomOnTime

No puedo proporcionar una respuesta canónica a sus preguntas, pero, de manera anecdótica, mi empresa ha estado haciendo esto durante años con el usuario root y nunca ha tenido problemas con él. 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 administradores de bases de datos de Oracle hacen algo similar con sus usuarios, teniendo 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 durante al menos diez años, en Solaris y Linux. Creo que está funcionando 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 primer 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, funciona muy bien.

4
jj33

¿Esta práctica tiene consecuencias no deseadas?

Hay un problema del que soy consciente. Cron no funciona 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.

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

4
Sridhar Ratnakumar

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

Diseñado de esa manera.

¿Va a ser coherente en todas 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 root/toor). En cualquier otro lugar y estás preguntando por un problema estúpido en el futuro. Si no está seguro de si esta es la solución correcta, probablemente no lo sea.

¿Esta práctica tiene consecuencias no deseadas?

Es una costumbre general tratar los nombres de usuario y los 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?

4
sh-beta

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 usarlo en su propio entorno si lo considera oportuno.

El único problema que me viene a la mente 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 averiguar cuál hizo qué cuando está analizando registros.

3
Michael Gorsuch

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

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

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

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

3
Brent

Por cierto, esta pregunta/respuesta se actualizó para los sistemas operativos actuales.

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

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

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

Si a dos entradas se les asigna el mismo número de identificación, 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 intentado 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 finalmente me dirigí en de una manera completamente diferente), pero podría iniciar sesión con "usera", hacer un "quién" o "id" y ver "userb" OR "usera" - aleatoriamente.

Existe 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 espera lo mismo o un comportamiento similar entre sistemas o incluso aplicaciones en el mismo sistema puede sorprenderse lamentablemente.

En Sun (ahora Oracle) yp (páginas amarillas) o NIS (NetworkInformationServices), también hay muchas referencias a los requisitos de unicidad. Las funciones especiales y los servidores están configurados para asignar ID únicos a través de múltiples servidores y dominios (ejemplo es el id_allocd, gid_allocd - demonios de asignación de UID y GID página de manual

Una tercera fuente que se puede consultar 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 describe cómo el ID mantiene los permisos y el acceso a los archivos. Allí, escriben:

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

  • GID. Este es un número entero sin signo utilizado por el kernel 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, quizás?), 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 lo hacen.

2
Astara

Tampoco sé si es una buena idea o no, pero utilizo 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 pareció romper nada y pareció facilitar el manejo de los permisos de lo que habría sido con varias cuentas.

1
Zoredache

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.

Posteriormente, el servidor RHEL 7 se unió a un dominio de Active Directory mediante winbind. En este punto, el servidor Informix DB ya no podía iniciarse. La ejecución de oninit estaba 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. Corriendo id root o getent passwd 0 (para resolver el UID 0 en un nombre de usuario) en un sistema unido a Active Directory devolvería aleatoriamente "user1" o "user2" en lugar de "root".

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

  3. Sin winbind, id root y getent passwd 0 siempre 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 se resolvió una vez más de manera consistente como "raíz" e Informix podría iniciarse.

Espero que esto sea útil para alguien.

0
Daibhi O Domhnaill