Pautas de Usuarios y Grupos

Hay muchas maneras de preasignar los UID y GID. Los sitios que solo desean personalizar los UID y GID de algunos servicios no esenciales pueden escribir un script para crear los apuntes con useradd y groupadd e instalar nuestro paquete posteriormente.

Los sitios que desean preasignar cuentas necesarias durante una instalación kickstart desatendida tienen un problema más complicado. Una forma de lograr sus objetivos es crear una versión personalizada del paquete setup con los usuarios y grupos deseados junto con sus asignaciones UID/GID elegidas en los archivos /etc/passwd, /etc/shadow y /etc/group. Luego, se aseguran de que la transacción de instalación use ese paquete en lugar del de la distribución original (versionando su paquete de instalación en una versión superior a la nuestra (por ejemplo, con una época) y colocándolo en un repositorio local que incluyen al instalar o reemplazando nuestro paquete de instalación con el suyo en un espejo local de los paquetes desde los que están instalando). Dado que la instalación está en la parte superior del árbol de dependencias, se instalará antes de cualquier paquete que necesite usar los UID y GID definidos en él.

La práctica de usar usuarios y grupos existentes si sus nombres simbólicos (nombres de usuario y de grupo) ya existen en el sistema permite al administrador personalizar los UID y GID a su gusto. Sin embargo, esto tiene una desventaja que los administradores deben tener en cuenta: si ya se ha creado una cuenta no relacionada que usa esos nombres de usuario y de grupo, el paquete las usará.

Por ejemplo, supongamos que está instalando el paquete mailman, que busca crear el usuario y el grupo mailman para que los archivos de la lista de correo privada sean propiedad de dicho usuario y grupo en el disco. Uno de sus usuarios locales ya tiene el nombre de usuario mailman. Al instalar el paquete mailman, detectará que ya existe un usuario mailman y usará esa cuenta para gestionar sus archivos privados. El usuario local propietario de la cuenta mailman podrá entonces leer dichos archivos privados.

Por el momento, los empaquetadores no tienen ninguna estrategia para contrarrestar esto. Es responsabilidad de los administradores del sistema del sitio monitorear y eliminar los conflictos entre los nombres de usuario y grupo que utilizan sus usuarios y los de los paquetes que utilizan.

Para crear usuarios y grupos del sistema en paquetes mediante asignación dinámica, el paquete debe instalar un archivo sysusers.d/<nombre-del-paquete>.conf. Si el desarrollador original no lo proporciona, el mantenedor proporcionaría uno como Source independiente o crearlo durante la compilación del paquete.

Por ejemplo, para el paquete munge, este archivo puede contener:

(El intérprete no está especificado, por tanto el predeterminado o nologin será utilizado.)

Al compilar un paquete con un archivo sysusers.d, se genera automáticamente un Provides virtual para user(…) y group(…). Al instalar rpm un paquete con dicho Provides, creará los usuarios y grupos según dichas definiciones.

Utilice rpm -q --qf='[%{SYSUSERS}\n]' … para ver las definiciones de usuarios y grupos decodificadas desde el proveedor Provides virtual.

Para lanzamiento de Fedora anteriores a 42, la creación de usuarios y grupos del manual es requerido.

El archivo sysusers debe ser un archivo Source separado.

En el archivo de especificaciones, agregue un BuildRequires para systemd-rpm-macros, instale el archivo sysusers, use la macro %sysusers_create_compat para consumirlo en la sección %pre (en este ejemplo, el archivo de configuración sysusers es Source3 del archivo de especificaciones) y la macro %sysusers_requires_compat para especificar las dependencias de ejecución para la sección %pre:

Este formato es compatible con Fedora 42+, y el mismo archivo de especificaciones puede usarse tanto para versiones anteriores como posteriores. En F42+, las macros %sysusers_requires_compat y %sysusers_create_compat se evaluarán como vacías.

Para asignar un UID o un GID, envíe un ticket a aquí para que el FPC lo evalúe. Si el FPC determina que su paquete necesita un UID o un GID estático flexible, aprobará su solicitud y la remitirá a los responsables del paquete setup para su implementación. Dado que el número de UID y GID es limitado, debe justificar la necesidad de un UID o un GID estático flexible en el ticket del FPC. Explique cómo se comparten los UID y los GID entre los equipos. Si corresponde, explique también por qué el programa no se puede adaptar para usar nombres simbólicos (nombre de usuario y nombre de grupo). Si se debe usar un UID o un GID específico, menciónelo y el motivo (por ejemplo, si es el que usa el desarrollador original o el que usan otras distribuciones). Intentaremos adaptarnos por orden de llegada si el UID o el GID está disponible dentro del intervalo de UID/GID del sistema Fedora.

Para crear usuarios y grupos en paquetes con un UID/GID asignado, siga los pasos de la sección de asignación dinámica anterior, pero agregue el UID o GID en la columna ID.

El paquete que proporciona la definición de la cuenta de usuario o grupo tiene el proveedor Provides automáticamente generado. Otros paquetes los cuales quieran asegurar que los usuarios o grupos existan, tal vez utilicen requisitos, Requires en los nombres de usuario o grupo.

Por ejemplo, Requires: user(mock) o Requires: group(man).

rpm crea dependencias débiles automáticamente (Recommends) para los paquetes los cuales contengan archivos propiedad de usuarios y grupos. En el futuro, esas dependencias serán cambiadas a los requisitos,Requires.

El listado de cuentas asignadas estáticamente es mantenido en el paquete setup : uidgid.