¿Cuáles son los peligros de crear un usuario normal con UID <500?


14

¿Cuáles son los peligros de crear un usuario normal con UID <500? Suponiendo que los UID no son duplicados de los UID existentes, ¿qué podría salir mal?

Esto no es algo que quiero hacer, sino algo que he visto y quiero saber por qué no debería hacerse. En este ejemplo, está en RHEL5.


2
Los sistemas derivados de Debian parecen iniciar UID normales a 1000, no a 500.
Keith Thompson

Respuestas:


16

No creo que haya ningún riesgo inherente, esto es algo que se hace simplemente para crear una separación entre lo que se consideran cuentas del sistema y cuentas de usuario. La práctica de usar números por debajo de 500, desde mi experiencia, es un Redhat-ismo, y realmente nada más que eso.

En Solaris, también vi a los usuarios asignándose números a partir de 100, solo años después descubrí que al fusionar 2 sistemas de departamentos más pequeños causa una especie de pesadilla, ya que había varios usuarios en los 2 departamentos que tenían el mismo UID / GID's asignado.

Este es realmente el principal riesgo / dolor de cabeza al asignar los UID. Dado que el UID es lo que finalmente se escribe en el inodo para los archivos / directorios dados por un usuario, no debe tener que realizar en findel futuro una búsqueda masiva de archivos que pertenecen al UID 1234 y tener que cambiarlos a 5678 .

Entonces, al pensar un poco en la selección de UID, los administradores pueden evitar el dolor de cabeza en el futuro.

El uso de 500 y superiores es solo un intento de Redhat (y otros Unixes) para obtener suficiente búfer para que cualquier cuenta del sistema que deba crearse no se mezcle con los UID asignados a los usuarios.

/etc/login.defs

Por cierto, el número 500 es impulsado por esta configuración en el archivo de configuración, /etc/login.defs.

#
# Min/max values for automatic uid selection in useradd
#
UID_MIN           500
UID_MAX         60000

#
# Min/max values for automatic gid selection in groupadd
#
GID_MIN           500
GID_MAX         60000

Puede cambiar esto a lo que desee, si desea anular el comportamiento predeterminado por useradd/adduser command.

Página de manual de Useradd

Si echa un vistazo a la useraddpágina de manual, notará esta parte que analiza el valor predeterminado para GID, pero este comentario también se aplica a los UID también:

extracto

-g, --gid GROUP
    The group name or number of the user´s initial login group. The group name 
    must exist. A group number must refer to an already existing group.

    If not specified, the behavior of useradd will depend on the USERGROUPS_ENAB 
    variable in /etc/login.defs. If this variable is set to yes 
    (or -U/--user-group is specified on the command line), a group will be 
    created for the user, with the same name as her loginname. If the variable 
    is set to no (or -N/--no-user-group is specified on the command line), 
    useradd will set the primary group of the new user to the value specified by 
    the GROUP variable in /etc/default/useradd, or 100 by default.

Cuentas del sistema

Otra cosa a tener en cuenta en la useraddpágina del manual es este bit en la generación de la cuenta del sistema.

extracto

-r, --system
    Create a system account.

    System users will be created with no aging information in /etc/shadow, 
    and their numeric identifiers are choosen in the SYS_UID_MIN-SYS_UID_MAX 
    range, defined in /etc/login.defs, instead of UID_MIN-UID_MAX (and their 
    GID counterparts for the creation of groups).

    Note that useradd will not create a home directory for such an user, 
    regardless of the default setting in /etc/login.defs (CREATE_HOME). You 
    have to specify the -m options if you want a home directory for a system 
    account to be created.

Es este método ( useradd -r ...) que a menudo se usa mediante secuencias de comandos lo que se incorpora a los distintos administradores de paquetes, como RPM, cuando se instala un paquete. La secuencia de comandos de esta manera permite que el sistema seleccione automáticamente el siguiente UID / GID disponible en un sistema determinado sin riesgo de pisar los UID / GID ya asignados a los usuarios del sistema.


1
FWIW, creo que este es un ismo general de GNU / Linux, no solo un Red Hat-ismo. He visto esto en todos los sistemas que uso, y nunca he usado Red Hat.
Strugee

@strugee: gracias. No quería que la declaración fuera demasiado amplia y que volviera a morderme.
slm

2

Desde la perspectiva del núcleo, solo hay un usuario especial: UID 0. Dividir los rangos de UID por razones administrativas simplifica su vida. Los rangos comunes son proveedor, sistema, local, global.

Los usuarios del proveedor se instalan durante la instalación inicial del sistema y el proveedor los administra de forma estática. Los usuarios del sistema se instalan por máquina dependiendo de qué paquetes estén instalados. La mayoría de las utilidades de agregar / eliminar usuarios tienen un límite de rango para manejarlas por separado. Los usuarios locales son usuarios regulares y se asignan por máquina. Los usuarios globales son asignados por una base de datos central, pero son usuarios regulares. El uso de rangos UID evita conflictos entre estos grupos diferentes. dónde están estos límites puede variar, pero generalmente es configurable.


1

No hay peligros inherentes al hacer esto. Si crea un usuario con UID 499, no tendrá ningún privilegio adicional. La razón por la que se sugiere no hacerlo es simplemente porque los UID suelen estar reservados para los usuarios del sistema. El problema que uno puede encontrar al crear dicho UID es cuando algún servicio del sistema espera que el UID esté disponible. Es como crear un nuevo servicio que se ejecuta en un puerto conocido: no hay ningún problema necesariamente, pero no es una buena práctica y puede causar problemas más adelante cuando configuras sshd, ftpd, etc.

Dicho esto, he visto muchos sistemas donde los usuarios fueron creados con UID <500 sin problemas. Sin embargo, a medida que crece la base de usuarios y ahora hay miles de usuarios, puede ser difícil diferenciar entre cuentas de usuario y cuentas del sistema. Siguiendo la regla de no UID <500, es muy fácil. Por lo tanto, también es una buena manera de organizar cuentas.


1

No hay peligro real. Al núcleo no le importan los valores de ID de usuario, excepto 0. A la mayoría de las herramientas de administración tampoco les importa: muy pocas partes del sistema marcan la diferencia entre los usuarios del sistema y los usuarios humanos.

Los usuarios del sistema tienden a tener grupos dedicados, por lo que no es probable que esto cree cuentas que pertenezcan a más grupos de lo que deberían.

Algunas distribuciones reservan el rango 1–499 (Red Hat y familiares) o 1–999 (Debian y familiares) para usuarios del sistema, incluidos los usuarios asignados al instalar un paquete que contiene un servicio del sistema que requiere un usuario dedicado. La convención de Debian es que el rango 1–99 se asigna estáticamente (por lo que crear un usuario humano en ese rango es una muy mala idea ya que puede chocar con un usuario del sistema) mientras que el rango 100–999 se asigna dinámicamente (creando un usuario humano en ese rango es inofensivo, ya que cualquier nuevo usuario del sistema elegirá una ID de usuario gratuita).

Puede encontrar inconvenientes menores, como que los administradores de pantallas no ofrezcan a los usuarios con UID por debajo del umbral en su lista.

El principal peligro para una máquina aislada es que es probable que confunda a sus compañeros administradores del sistema. Para una máquina en una red donde se comparten ID de usuario, puede encontrarse con conflictos con otras máquinas donde estos usuarios tienen la misma ID de usuario que un usuario del sistema. En redes con ID de usuario compartidos, es mejor mantener el rango 1000–65533 o incluso 10000–65533 para usuarios humanos.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.