Nous pouvons déterminer le propriétaire d'un processus en utilisant la ps
commande. Est-ce à dire que les autres utilisateurs ne peuvent pas exécuter / tuer / reprendre ce processus?
Lisez les informations d'identification (7) , fork (2) , execve (2) . L' appel système fork est la façon dont les processus sont créés (aujourd'hui, il fork
est souvent implémenté avec clone (2) mais vous pouvez le voir comme un détail d'implémentation). L' appel système exec est la façon dont les programmes exécutables sont démarrés. N'oubliez pas que tout est fait à partir d'un processus avec des appels système (répertoriés dans syscalls (2) ). Le tout premier processus ( init ou systemd ) a été démarré comme par magie par le noyau au démarrage. D'autres processus ont été lancés par fork (2). Les noyaux Linux modernes démarrent parfois - mais rarement - comme par magie quelques processus spéciaux (par exemple /sbin/hotplug
) ou threads du noyau (par exemple kworker
, kswapd
....).
Donc oui, chaque processus (et chaque fichier) a un propriétaire (techniquement l' uid , un petit nombre non négatif) et un groupe (le gid). L'uid 0 est pour root et dispose d'autorisations supplémentaires.
Lisez aussi à propos de setuid (et setreuid (2) ...) C'est délicat.
cela signifie-t-il que l'autre propriétaire ne peut pas exécuter ce processus?
Un processus est déjà en cours d'exécution (mais il peut être inactif ou en attente), donc personne ne peut le réexécuter. Ne confondez pas un processus (quelque chose de dynamique) avec le programme (un fichier exécutable , souvent au format ELF ) qui s'exécute à l'intérieur.
Un programme donné (par exemple /bin/bash
) peut être exécuté en plusieurs processus. De nombreux exécutables restent sur votre disque sans avoir (à un instant donné) aucun processus les exécutant.
Sous Linux, proc (5) est très utile pour interroger le noyau sur l'état des processus. Essayez des exemples cat /proc/$$/status
et cat /proc/self/maps
. Voir aussi pgrep (1) , ps (1) , top (1) .
Chaque processus a son propre espace d'adressage virtuel , sa propre table de descripteurs de fichiers , son propre répertoire de travail , (et souvent plusieurs threads , voir pthreads (7) ) etc etc ...
cela signifie-t-il que d'autres propriétaires ne peuvent pas exécuter / tuer / reprendre ce processus?
L'exécution d'un processus n'a aucun sens (il est déjà en cours d'exécution). Cependant, l'exécutable du processus du pid 1234 est disponible en tant que /proc/1234/exe
lien symbolique, et vous pouvez l'utiliser pour execve (2) - mais vous ne devriez probablement pas -. Les règles d'autorisation execve
s'appliquent.
Pour tuer (2) un processus, vous devez généralement avoir le même uid. Cependant, la documentation indique:
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.
Pour arrêter un processus, utilisez le signal SIGSTOP
(ou SIGTSTP
) utilisé avec kill (2) . Voir signal (7) .
Pour reprendre un processus arrêté, utilisez le SIGCONT
signal.
Le propriétaire est généralement l'utilisateur qui a lancé ce processus. La commande peut être exécutable par d'autres utilisateurs, mais ce serait un processus différent.
cela signifie-t-il que l'autre propriétaire ne peut pas exécuter ce processus?
Il n'y a pas d'autre propriétaire. Ne confondez pas les programmes (fichiers exécutables) et les processus (programmes en cours d'exécution).
Cela signifie-t-il que d'autres propriétaires ne peuvent pas exécuter / tuer / reprendre ce processus?
Le propriétaire unique a déjà lancé le processus. Si vous voulez dire d'autres utilisateurs , pas des propriétaires, cela dépend.
Root, c'est-à-dire un utilisateur uid
égal à 0, a la pleine puissance. D'autres utilisateurs partageant la même chose uid
sont, du point de vue du système d'exploitation, le même utilisateur, donc ont également le plein pouvoir sur le processus.
Les utilisateurs avec un UID différent ne pourront pas tuer / arrêter / reprendre le processus, à moins qu'ils ne soient autorisés à basculer vers le propriétaire ou le privilège root via sudo
une commande similaire ou, dans une moindre mesure, s'ils sont liés à ce processus de leur hiérarchie.