¿Cuál es la ventaja de sincronizar UID / GID en máquinas Linux?

24

Antes de sumergirme en las profundidades de cómo sincronizar UID / GID en mis diferentes máquinas Linux, me gustaría saber cuál es realmente el beneficio.

Sé que esto mantiene la sincronización de archivos relativamente fácil (ya que la propiedad se conserva "naturalmente"). Sin embargo, esto también se puede lograr de otra manera dependiendo del servicio de transmisión.

¿Hay algo más que se beneficiaría de UID / GID consistentes?

linux synchronization uid alex
fuente
44
No olvide, al cambiar uid / gid, actualizar los archivos (archivos tar, etc.), y también los archivos conf que pueden usar identificadores numéricos en lugar de uidname / groupnames.
Olivier Dulac

Respuestas:

31

deuda técnica

Por las siguientes razones, es mucho más simple abordar este problema desde el principio para evitar la acumulación de deuda técnica . Incluso si ya se encuentra en esta situación, probablemente sea mejor tratarlo en un futuro cercano que dejar que continúe creciendo.

sistemas de archivos en red

Esta pregunta parece centrarse en el alcance limitado de la transferencia de archivos entre máquinas con sistemas de archivos locales, lo que permite estados de propiedad específicos de la máquina.

Las consideraciones del sistema de archivos en red son fácilmente el caso más importante para tratar de mantener sincronizadas sus asignaciones de UID / GID, porque generalmente puede arrojar lo "logrado de otra manera" que mencionó en la ventana en el momento en que ingresan a la imagen. Claro, es posible que no tenga sistemas de archivos en red compartidos entre estos hosts en este momento ... pero ¿qué pasa con el futuro? ¿Puede decir honestamente que nunca habrá un caso de uso para un sistema de archivos en red introducido entre sus hosts actuales o hosts que se creen en el futuro? No es muy avanzado pensar asumir lo contrario.

Suponga que /homees un sistema de archivos en red compartido entre host1y host2en los siguientes ejemplos.

  • Permisos en desacuerdo : /home/user1es propiedad de un usuario diferente en cada sistema. Esto evita que un usuario pueda acceder o modificar constantemente su directorio de inicio en los sistemas.
  • Guerras chown : es muy común que un usuario envíe un ticket solicitando que los permisos de su directorio principal se arreglen en un sistema específico. La solución de este problema host2rompe los permisos en host1. A veces puede tomar varios de estos boletos para trabajar antes de que alguien retroceda y se dé cuenta de que hay un tira y afloja en juego. La única solución es arreglar las asignaciones de ID en desacuerdo. Lo que lleva a...
  • UID / GID reequilibrando el infierno : la complejidad de corregir IDs luego aumenta exponencialmente por el número de reasignaciones involucradas para corregir un solo usuario en múltiples máquinas. ( user1tiene la ID de user2, pero user2tiene la ID de user17... y ese es solo el primer sistema en el clúster) Cuanto más espere para solucionar el problema, más complejas pueden volverse estas cadenas, que a menudo requieren el tiempo de inactividad de las aplicaciones en múltiples servidores con el fin de sincronizar las cosas correctamente.
  • Los problemas de seguridad : user2el host2tiene la misma UID que user1el host1, lo que les permite escribir en /home/user1el host2sin el conocimiento de user1. Estos cambios luego se evalúan host1con los permisos de user1. ¿Qué podría salir mal? (si user1es un usuario de la aplicación, alguien en desarrollo descubrirá que se puede escribir y hará cambios. Esto es un hecho comprobado).

Hay otros escenarios, y estos son solo ejemplos de los más comunes.

los nombres no siempre son una opción

Cualquier script o archivo de configuración escrito con ID numéricos se vuelve inherentemente inportable dentro de su entorno. En general, no es un problema porque la mayoría de las personas no las codifica a menos que sea absolutamente necesario ... pero a veces la herramienta con la que está trabajando no le da una opción al respecto. En estos escenarios, se ve obligado a mantener n versiones diferentes del script o archivo de configuración.

Ejemplo: le pam_succeed_ifpermite usar campos de user, uidy gid... una opción de "grupo" está notablemente ausente. Si lo pusieran en una posición en la que se esperaba que varios sistemas implementaran alguna forma de restricción de acceso basada en grupos, tendría n variaciones diferentes de las configuraciones de PAM. (o al menos un único GID en el que debe evitar colisiones)

gestión centralizada

La respuesta de natxo ha cubierto esto bastante bien.

Andrew B
fuente
No estoy tan seguro de que sea correcto decir que el uso de un sistema de archivos en red evita la solución de problemas con diferentes uids, conozco al menos un sistema de archivos que admite un mapa de uid que le permite especificar qué grupos y usuarios coinciden en diferentes máquinas.
Vality
@Vality Si se tratara de una solución comúnmente disponible, aún dudaría en llamarla escalable.
Andrew B
Estoy de acuerdo, simplemente no quería que el OP pensara que es imposible, estoy de acuerdo en gran medida con su sugerencia de que la mejor solución es mantenerlos sincronizados.
Vality
¡Gracias! Lamentablemente, "desde el principio" ya no existe. Si bien sé que alguna configuración de ldap / kerberos es algo que me gustaría incluir aquí donde trabajo, pero eso no sería ahora. Por otras razones, estaba específicamente interesado en el uso de UID / GID en los sistemas de interoperación. Como dije, la transferencia de archivos es un problema (que actualmente tiene un estado de "funciona"), por eso quería saber si hay otras cosas (como usted mencionó) también afectadas por los UID. ¿Podría agregar algunas palabras clave de esos "otros escenarios"? ¡Eso haría que esta sea una respuesta espléndida!
alex
@alex Bueno, quise decir "otros escenarios" en términos de problemas del sistema de archivos en red. No importa qué tan tarde estés en el juego, el problema solo sigue empeorando, ya que no se resuelve. Si las razones que proporcionamos no son adecuadas, probablemente sería útil que usted dirigiera su pregunta un poco más al proporcionar esas "otras razones". Las respuestas proporcionadas hasta ahora son bastante buenas en mi opinión. Si está tratando de persuadir a la gerencia, no nos corresponde a nosotros hacer que hagan lo correcto.
Andrew B
18

una vez que alcance un cierto tamaño (y siempre es antes de lo que piensa), se dará cuenta de que cambiar sus contraseñas o deshabilitar cuentas para alguien en todos los hosts es una PITA. Es por eso que las personas usan sistemas con bases de datos LDAP (o NIS pero no lo hacen, no es seguro hoy en día) como openldap o hoy en día el excelente freeipa.

Mantiene toda la información de cuentas / grupos en una base de datos central, todos los hosts comparten esa información. Puede hacer muchas más cosas desde allí: utilice la información de los usuarios para los permisos de archivos, por supuesto, pero también cree usuarios virtuales para todas las aplicaciones que tengan enlaces ldap en lugar de tener que crear sus usuarios allí (muchas aplicaciones web pueden usar ldap para su base de datos de usuarios), mantenga una base de datos central de reglas de sudo, distribuya su entorno de autofs, mantenga sus zonas dns, ...

natxo asenjo
fuente