¿Puede un proceso tener un dueño? Qué significa eso?

Podemos determinar el propietario de un proceso utilizando el pscomando ¿Esto significa que otros usuarios no pueden ejecutar / matar / reanudar ese proceso?

Lea las credenciales (7) , fork (2) , execve (2) . La llamada al sistema fork es la forma en que se crean los procesos (hoy en día, a forkmenudo se implementa con el clon (2), pero puede verlo como un detalle de implementación). La llamada al sistema exec es la forma en que se inician los programas ejecutables . Recuerde que todo se hace desde algún proceso con algunas llamadas al sistema (enumeradas en syscalls (2) ). El primer proceso ( init o systemd ) ha sido iniciado mágicamente por el núcleo en el momento del arranque. Otros procesos han sido iniciados por fork (2). Los núcleos modernos de Linux a veces, pero raramente, inician mágicamente algunos procesos especiales (por ejemplo /sbin/hotplug) o hilos de kernel (por ejemplo kworker, kswapd...).

Entonces, sí, cada proceso (y cada archivo) tiene algún propietario (técnicamente el uid , un pequeño número no negativo) y un grupo (el gid). El 0 uid es para root y tiene permisos adicionales.

Lea también sobre setuid (y setreuid (2) ...) Es complicado.

¿Significa que el otro propietario no puede ejecutar ese proceso?

Ya hay un proceso ejecutando (pero podría estar inactivo o en espera), por lo que nadie puede volver a ejecutarlo. No confunda un proceso (algo dinámico) con el programa (un archivo ejecutable , a menudo en formato ELF ) que se ejecuta dentro de él.

Un programa dado (p. Ej. /bin/bash . ) Puede ejecutarse en varios procesos. Muchos ejecutables permanecen en su disco sin tener (en un instante dado) ningún proceso que los ejecute.

En Linux, proc (5) es muy útil para consultar al núcleo sobre el estado de los procesos. Prueba con ejemplos cat /proc/$$/statusy cat /proc/self/maps. Ver también pgrep (1) , ps (1) , top (1) .

Cada proceso tiene su propio espacio de direcciones virtuales , su propia tabla de descriptores de archivos , su propio directorio de trabajo (y a menudo varios hilos , consulte pthreads (7) ), etc., etc.

¿Significa que otros propietarios no pueden ejecutar / matar / reanudar ese proceso?

Ejecutar un proceso no tiene ningún sentido ( ya se está ejecutando). Sin embargo, el ejecutable del proceso de pid 1234 está disponible como /proc/1234/exeenlace simbólico, y puede usarlo para execve (2) , pero probablemente no debería hacerlo . Se aplican las reglas de permiso para execve.

Para matar (2) un proceso, generalmente debe tener el mismo uid. Sin embargo, la documentación dice:

  For a process to have permission to send a signal, it must either be
   privileged (under Linux: have the CAP_KILL capability in the user
   namespace of the target process), or the real or effective user ID of
   the sending process must equal the real or saved set-user-ID of the
   target process.  In the case of SIGCONT, it suffices when the sending
   and receiving processes belong to the same session. 

Para detener un proceso, use la señal SIGSTOP(o SIGTSTP) utilizada con kill (2) . Ver señal (7) .

Para reanudar un proceso detenido, use la SIGCONTseñal.

El propietario suele ser el usuario que inició ese proceso. El comando puede ser ejecutable por otros usuarios, pero ese sería un proceso diferente.

¿Significa que el otro propietario no puede ejecutar ese proceso?

No hay otro dueño. No confunda programas (archivos ejecutables) y procesos (programas en ejecución).

¿Significa que otros propietarios no pueden ejecutar / matar / reanudar ese proceso?

El propietario único ya lanzó el proceso. Si te refieres a otros usuarios , no propietarios, eso depende.

Root, es decir, un usuario con uidigual a 0, tiene plena potencia. Otros usuarios que comparten lo mismouid son, desde el punto de vista del sistema operativo, el mismo usuario, por lo que también tienen plena potencia en el proceso.

Los usuarios con un uid diferente no podrán matar / detener / reanudar el proceso, a menos que se les permita cambiar al propietario o privilegio raíz a través de sudoun comando similar o, en menor medida, si están relacionados con ese proceso de su jerarquía.