Solución 1:
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 ubicar a los usuarios en grupos comunes. La capacidad de hacer que el UID sea el mismo sin problemas es solo un resultado intencionado que, como todo, puede traer problemas si se maneja incorrectamente.
¿Va a ser consistente en todas las variantes *nix?
Yo creo que sí.
¿Es esta una práctica aceptada?
Aceptado como en uso general de una forma u otra, sí.
¿Existen consecuencias no deseadas de 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.
Solución 2:
¿Funcionará en todos los Unixes? Sí.
¿Es una buena técnica a utilizar? 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 escrito al revés) que tiene /bin/sh como shell predeterminado. De esta manera, si el shell de root se estropea, aún puede iniciar sesión.
Solución 3:
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 raíz 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 las mismas 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 funciona según lo diseñado.
Yo no haría esto con una cuenta de usuario regular. 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 cuentas del sistema, aunque funciona muy bien.
Solución 4:
¿Existen consecuencias no deseadas de esta práctica?
Hay un problema del que soy consciente. Cron no funciona bien con este alias de UID. Intente ejecutar "crontab -i" desde un script de Python para actualizar las entradas de cron. Luego ejecute "crontab -e" en el shell para modificar lo 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).
Solución 5:
¿Esta habilidad está diseñada o es solo la forma en que funciona?
Diseñado de esa manera.
¿Va a ser consistente en todas las variantes *nix?
Debería, sí.
¿Es esta una 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 pidiendo un problema estúpido en el futuro. Si no está seguro de si esta es la solución correcta, probablemente no lo sea.
¿Existen consecuencias no deseadas de esta práctica?
Es 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 cualquier secuencia de comandos/programa relevante relacionada con el usuario (las secuencias de comandos useradd, usermod, userdel de su distribución, cualquier secuencia de comandos de mantenimiento periódico, etc.).
¿Qué intenta lograr con esto que no se lograría agregando estos dos usuarios a un nuevo grupo y otorgando a ese grupo los permisos que necesita?