Estoy ejecutando un sistema de escritorio Ubuntu 12.04. Hasta ahora solo he instalado algunos programas (tengo derechos de sudo).

1. Cuando reviso la lista de usuarios en el sistema, veo una lista larga, como más de 20 usuarios, ¿cuándo se crearon estos usuarios (por ejemplo, daemon, sys, sync, games, pulse, etc.)? ¿Cómo se relacionan estos con los nuevos programas que se instalan?

2. Si ejecuto un programa en mi sistema, debería ejecutarse con mi UID. Pero al hacer una ps , veo muchos otros programas que se ejecutan con diferentes UID (como root, daemon, avahi, syslog, colord, etc.): ¿cómo se iniciaron estos programas con diferentes UID?

Las cuentas de usuario se utilizan no solo para usuarios reales, humanos, sino también para ejecutar servicios del sistema y, a veces, como propietarios de archivos del sistema. Esto se hace porque la separación entre los recursos de los usuarios humanos (procesos, archivos, etc.) y la separación entre los recursos de los servicios del sistema requiere los mismos mecanismos.

Los programas que ejecuta normalmente se ejecutan con su ID de usuario. Solo los demonios del sistema se ejecutan bajo su propia cuenta. El archivo de configuración que indica cuándo ejecutar el daemon también indica qué usuario debe ejecutarlo, o el daemon cambia a una cuenta sin privilegios después de comenzar. Algunos demonios requieren privilegios administrativos completos, por lo que se ejecutan bajo la cuenta raíz . Muchos daemons solo necesitan acceso a un dispositivo de hardware específico o a archivos específicos, por lo que se ejecutan bajo una cuenta de usuario dedicada. Esto se hace por seguridad: de esa manera, incluso si hay un error o una configuración incorrecta en uno de estos servicios, no puede conducir a un ataque completo del sistema, porque el atacante estará limitado a lo que este servicio puede hacer y no será capaz de sobrescribir archivos, espiar procesos, etc.

En Ubuntu, las ID de usuario en el rango 0–99 se crean en la instalación del sistema. 0 es raíz; muchos de los que están en el rango 1–99 existen solo por razones históricas y solo se mantienen por compatibilidad con algunas instalaciones locales que los usan (algunas entradas adicionales no perjudican). Las ID de usuario en el rango de 100–999 se crean y eliminan dinámicamente cuando se instalan o eliminan servicios que necesitan una ID de usuario dedicada. El rango de 1000 en adelante es para usuarios humanos o cualquier otra cuenta creada por el administrador del sistema. Lo mismo vale para los grupos.

¿Supongo que está encontrando esta lista de usuarios marcando /etc/passwd? Esto es totalmente normal: los 'usuarios' sirven para llevar un conjunto de permisos, útiles para bloquear no solo 'usuarios reales' sino también programas para ciertas áreas de su sistema y rastrear lo que cambiaron (el mismo concepto con grupos).

He insertado uno de mis /etc/passwdarchivos Raspberry Pi a continuación para su referencia; notarás al usuario ntopal final de este archivo, creado por el programa ntop(monitoreo de red). Del mismo modo sshd, gnatsinformes de errores , etc.

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/bin/sh
man:x:6:12:man:/var/cache/man:/bin/sh
lp:x:7:7:lp:/var/spool/lpd:/bin/sh
mail:x:8:8:mail:/var/mail:/bin/sh
news:x:9:9:news:/var/spool/news:/bin/sh
uucp:x:10:10:uucp:/var/spool/uucp:/bin/sh
proxy:x:13:13:proxy:/bin:/bin/sh
www-data:x:33:33:www-data:/var/www:/bin/sh
backup:x:34:34:backup:/var/backups:/bin/sh
list:x:38:38:Mailing List Manager:/var/list:/bin/sh
irc:x:39:39:ircd:/var/run/ircd:/bin/sh
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/sh
nobody:x:65534:65534:nobody:/nonexistent:/bin/sh
libuuid:x:100:101::/var/lib/libuuid:/bin/sh
pi:x:1000:1000:,,,:/home/pi:/bin/bash
sshd:x:101:65534::/var/run/sshd:/usr/sbin/nologin
ntp:x:102:104::/home/ntp:/bin/false
statd:x:103:65534::/var/lib/nfs:/bin/false
messagebus:x:104:106::/var/run/dbus:/bin/false
usbmux:x:105:46:usbmux daemon,,,:/home/usbmux:/bin/false
lightdm:x:106:109:Light Display Manager:/var/lib/lightdm:/bin/false
smmta:x:107:110:Mail Transfer Agent,,,:/var/lib/sendmail:/bin/false
smmsp:x:108:111:Mail Submission Program,,,:/var/lib/sendmail:/bin/false
Debian-exim:x:109:113::/var/spool/exim4:/bin/false
ntop:x:110:115::/var/lib/ntop:/bin/false

¿Cuándo se crearon estos usuarios?

En los casos de los que mencionó, se crearon en la instalación del sistema. Estas cuentas de usuario son convencionales, algunas datan de décadas. También están estandarizados. La base estándar de Linux los divide en:

• la requerida cuentas de usuario estándar, root, bin, y daemon; y
• el opcional de usuario estándar cuentas adm, lp, sync, shutdown, halt, mail, news, uucp, operator, man, ynobody

Otras cuentas de usuario que se mencionan aquí - pulse, avahi, colord, y Debian-exim(a elegir uno de fichero de contraseñas de py4on) - nos llevan a la siguiente pregunta.

¿Cómo se relacionan estos con los nuevos programas que se instalan?

Las cuentas de usuario no estándar son creadas y destruidas por los "scripts de mantenimiento" para varios paquetes, ya que esos paquetes se instalan y purgan. Se creará una cuenta de usuario mediante la llamada postinstsecuencia de comandos del mantenedor del paquete , que se ejecuta getentpara ver si la cuenta de usuario ya existe, y useraddsi no es así. En teoría, sería eliminado por el llamado postrmscript de mantenedor del paquete , en ejecución userdel.

En la práctica, las cuentas de usuario para paquetes no se eliminan. El wiki de Fedora (qv) explica que esto estaría lleno de dificultades. Consulte el error de Debian # 646175 para ver un ejemplo de esta lógica en acción, en la que se decide simplemente no eliminar la rabbitmqcuenta de usuario cuando se purga el paquete, para resolver un problema con un demonio que continúa ejecutándose bajo los auspicios de esa cuenta.

¿Cómo comenzaron estos programas con diferentes UID?

Bajo Unix y Linux, un proceso que se ejecuta bajo los auspicios del superusuario puede cambiar su cuenta de usuario a otra y continuar ejecutando el mismo programa, pero no se permite lo contrario. (Uno debe usar el mecanismo set-UID).

El sistema de gestión de dæmon se ejecuta como superusuario. Sus datos de configuración especifican que los demonios particulares se ejecutan bajo los auspicios de cuentas de usuario particulares:

• Con el Sistema 5, rcel script /etc/init.dutiliza una herramienta auxiliar como start-stop-daemony su --chuidopción.
• Con un gestor de servicios daemontools familia, las runllamadas de guión setuidgid, s6-setuidgid, chpst, o runuidcon el nombre de cuenta de usuario. Hay ejemplos de esto en /unix//a/179798/5132 que configuran la nagioscuenta de usuario.
• Con el arranque, hay una setuidestrofa en un archivo de trabajo que especifica la cuenta de usuario. Esto no es particularmente fino, y a veces uno quiere lo que se describe en /superuser//a/723333/38062 .
• Con systemd hay una User=configuración en el archivo de la unidad de servicio, que especifica la cuenta de usuario.

Cuando el sistema de administración de daemon genera un proceso para ser el daemon, estos mecanismos eliminan los privilegios de superusuario para que el proceso de daemon continúe ejecutándose bajo los auspicios de la cuenta de usuario no privilegiada.

Hay una explicación bastante extensa de por qué se hace una buena gestión de demonios de esta manera. Pero no preguntaste por qué; solo cuándo, cómo y de dónde. ☺ Un breve resumen, por lo tanto:

Los sistemas operativos Unix y Linux aíslan los procesos que se ejecutan bajo los auspicios de diferentes cuentas de usuario entre sí. Históricamente, si uno podía hacerse cargo de un demonio que funcionaba como superusuario, podía hacer lo que quisiera. Un demonio que se ejecuta bajo los auspicios de una cuenta no privilegiada, por otro lado, solo puede acceder a archivos, directorios, dispositivos y procesos que esa cuenta no privilegiada puede. Un sistema de programas de daemon mutuamente no confiables que se ejecutan bajo los auspicios de diferentes cuentas de usuario y que no pueden acceder / controlar los archivos / directorios / procesos / dispositivos (internos, confiables) de los demás, es mucho más difícil de descifrar.

Otras lecturas

• Jonathan de Boyne Pollard (2014). Una mirada en paralelo a los scripts de ejecución y las unidades de servicio. . Respuestas frecuentes.
• Manejo de cuentas en guiones de mantenimiento . Wiki de Debian.
• Empaque: UsersAndGroups . Proyecto Fedora wiki.
• "Capítulo 15. Usuarios y grupos" . Especificación básica estándar de Linux 2.1 . 2004. Grupo de Normas Libres.
• "9.2 Usuarios y grupos" . Manual de políticas de Debian . 2014-11-22. La lista de correo de la política de Debian.
• "37.3. Usuarios estándar" . Guía de implementación de RHEL . 11a Edición. 2013. Red Hat.
• Usuarios y grupos . Arch wiki.
• Carol Hurwitz y Scott McPeak (12-02-2001). ¡Abolir los demonios de la raíz! . DOI 10.1.1.120.3567 .

En Linux cuando instalamos un servicio, crea un usuario con su nombre de servicio o similar para que no pueda acceder a otros archivos.