<Précédent | Table des matières | Suivant>

Le manuel de formation -u et -a les options donnent des informations supplémentaires. Pour plus d'options et ce qu'elles font, reportez-vous aux pages d'informations.

Dans la section suivante, nous verrons comment un processus peut en créer un autre.

4.1.5. Vie et mort d'un processus

4.1.5.1. Création de processus

Un nouveau processus est créé car un processus existant fait une copie exacte de lui-même. Ce processus enfant a le même environnement que son parent, seul le numéro d'identification du processus est différent. Cette procédure s'appelle bifurquer.

Après le processus de fork, l'espace d'adressage du processus enfant est écrasé par les nouvelles données de processus. Cela se fait à travers un exec appel au système.

Le manuel de formation fourche-et-exec mécanisme commute ainsi une ancienne commande avec une nouvelle, tandis que l'environnement dans lequel le nouveau programme est exécuté reste le même, y compris la configuration des périphériques d'entrée et de sortie, les variables d'environnement et la priorité. Ce mécanisme est utilisé pour créer tous les processus UNIX, il s'applique donc également au système d'exploitation Linux. Même le premier processus, init, avec l'ID de processus 1, est fork pendant la procédure de démarrage dans le

soi-disant amorçage Procédure.

Ce schéma illustre le mécanisme fork-and-exec. L'ID de processus change après la procédure de fork :

Figure 4-1. Mécanisme fork-and-exec

Il y a quelques cas dans lesquels init devient le parent d'un processus, alors que le processus n'a pas été démarré par init, comme nous l'avons déjà vu dans le arbre Exemple. De nombreux programmes, par exemple, démoniser leurs processus enfants, afin qu'ils puissent continuer à s'exécuter lorsque le parent s'arrête ou est en cours d'arrêt. Un gestionnaire de fenêtres est un exemple typique ; ça commence un xterm processus qui génère un shell qui accepte les commandes. Le gestionnaire de fenêtres nie alors toute autre responsabilité et passe le processus fils à init. Grâce à ce mécanisme, il est possible de changer de gestionnaire de fenêtres sans interrompre les applications en cours d'exécution.

De temps en temps, les choses tournent mal, même dans les bonnes familles. Dans un cas exceptionnel, un processus peut se terminer alors que le parent n'attend pas la fin de ce processus. Un tel processus non enterré est appelé un zombie processus.

4.1.5.2. Fin des processus

Lorsqu'un processus se termine normalement (il n'est pas tué ou interrompu de manière inattendue), le programme renvoie son état de sortie au parent. Cet état de sortie est un nombre renvoyé par le programme fournissant les résultats de l'exécution du programme. Le système de retour d'informations lors de l'exécution d'un travail trouve son origine dans le langage de programmation C dans lequel UNIX a été écrit.

Les codes retour peuvent alors être interprétés par le parent, ou dans des scripts. Les valeurs des codes de retour sont spécifiques au programme. Ces informations se trouvent généralement dans les pages de manuel du programme spécifié, par exemple le grep la commande renvoie -1 si aucune correspondance n'est trouvée, sur laquelle un message sur les lignes "Aucun fichier trouvé" peut être imprimé. Un autre exemple est la commande intégrée Bash oui, qui ne fait rien d'autre que renvoyer un état de sortie de 0, ce qui signifie un succès.

4.1.5.3. Signaux

Les processus se terminent parce qu'ils reçoivent un signal. Il existe plusieurs signaux que vous pouvez envoyer à un processus. Utilisez le tuer commande pour envoyer un signal à un processus. La commande tuer -l affiche une liste de signaux. La plupart des signaux sont destinés à un usage interne par le système ou aux programmeurs lorsqu'ils écrivent du code. En tant qu'utilisateur, vous aurez besoin des signaux suivants :

Tableau 4-2. Signaux communs

Vous pouvez en savoir plus sur les actions par défaut qui sont prises lors de l'envoi d'un signal à un processus dans man 7 signal.

4.1.6. SUID et SGID

Comme promis dans le chapitre précédent, nous allons maintenant discuter plus en détail des modes spéciaux SUID et SGID. Ces modes existent pour fournir aux utilisateurs normaux la possibilité d'exécuter des tâches qu'ils ne seraient normalement pas en mesure de faire en raison du schéma d'autorisation de fichier strict utilisé sur les systèmes UNIX. Dans la situation idéale, les modes spéciaux sont utilisés aussi peu que possible, car ils comportent des risques de sécurité. Les développeurs Linux ont généralement essayé de les éviter autant que possible. Le Linux ps version, par exemple, utilise les informations stockées dans le / proc système de fichiers, qui est accessible à tous, évitant ainsi l'exposition de données et de ressources système sensibles au grand public. Avant cela, et toujours sur les anciens systèmes UNIX, le ps programme avait besoin d'accéder à des fichiers tels que / dev / mem et / dev / kmem, qui présentait des inconvénients en raison des autorisations et des propriétés sur ces fichiers :

Avec les anciennes versions de ps, il n'était pas possible de démarrer le programme en tant qu'utilisateur commun, à moins que des modes spéciaux ne lui soient appliqués.

Alors que nous essayons généralement d'éviter d'appliquer des modes spéciaux, il est parfois nécessaire d'utiliser un SUID. Un exemple est le mécanisme de modification des mots de passe. Bien sûr, les utilisateurs voudront le faire eux-mêmes au lieu d'avoir leur mot de passe défini par l'administrateur système. Comme nous le savons, les noms d'utilisateur et les mots de passe sont répertoriés dans le / Etc / passwd fichier, qui a ces autorisations d'accès et propriétaires :

bea:~> ls -l /etc/passwd

-rw-r--r-- 1 racine racine

1267 16 janvier 14:43 /etc/passwd

bea:~> ls -l /etc/passwd

-rw-r--r-- 1 racine racine

Néanmoins, les utilisateurs doivent pouvoir modifier leurs propres informations dans ce fichier. Ceci est obtenu en donnant au passwd

programmer des autorisations spéciales :

mia :~> quel mot de passe

passwd est /usr/bin/passwd

mia :~> quel mot de passe

passwd est /usr/bin/passwd

mia :~> ls -l / usr / bin / passwd

-rs--x--x 1 racine racine

13476 7 août 06:03 /usr/bin/passwd*

mia :~> ls -l / usr / bin / passwd

-rs--x--x 1 racine racine

Lorsqu'il est appelé, le passwd La commande s'exécutera en utilisant les autorisations d'accès de racine, permettant ainsi à un utilisateur commun de modifier le fichier de mot de passe qui appartient à l'administrateur système.

Les modes SGID sur un fichier ne se produisent pas aussi fréquemment que SUID, car SGID implique souvent la création de groupes supplémentaires. Dans certains cas, cependant, nous devons passer par cette difficulté afin de construire une solution élégante (ne vous en souciez pas trop - les groupes nécessaires sont généralement créés lors de l'installation). C'est le cas pour le écrire et wall programmes, qui sont utilisés pour envoyer des messages aux terminaux d'autres utilisateurs (ttys). Les écrire commande écrit un message à un seul utilisateur, tandis que wall écrit à tous les utilisateurs connectés.

L'envoi de texte vers le terminal ou l'affichage graphique d'un autre utilisateur n'est normalement pas autorisé. Afin de contourner ce problème, un groupe a été créé, qui possède tous les terminaux. Quand le écrire et wall les commandes reçoivent des autorisations SGID, les commandes s'exécuteront en utilisant les droits d'accès applicables à ce groupe, tty dans l'exemple. Étant donné que ce groupe dispose d'un accès en écriture au terminal de destination, un utilisateur n'ayant aucune autorisation d'utiliser ce terminal de quelque manière que ce soit peut lui envoyer des messages.

Dans l'exemple ci-dessous, l'utilisateur joe recherche d'abord sur quel terminal son correspondant est connecté, à l'aide de la pour qui commander. Puis il lui envoie un message en utilisant le écrire commander. Sont également illustrés les droits d'accès sur le écrire programme et sur les terminaux occupés par l'utilisateur récepteur : il est clair que d'autres que l'utilisateur propriétaire n'ont aucune autorisation sur l'appareil, à l'exception du groupe propriétaire, qui peut y écrire.

joe :~> qui écrivent

écrire est /usr/bin/write

joe :~> ls -l /usr/bin/écriture

-rwxr-sr-x 1 tty racine

8744 5 déc 00:55 /usr/bin/write*

joe :~> qui écrivent

écrire est /usr/bin/write

joe :~> ls -l /usr/bin/écriture

-rwxr-sr-x 1 tty racine

joe :~> pour qui

jenny tty1

jenny pts/1

jenny pts/2

jenny pts/3

Joe pts/0

Jan 23 11: 41

23 janvier 12:21 (:0)

23 janvier 12:22 (:0)

23 janvier 12:22 (:0)

20 janvier 10:13 (lo.callhost.org)

joe :~> pour qui

jenny tty1

jenny pts/1

jenny pts/2

jenny pts/3

Joe pts/0

joe :~> ls -l /dev/tty1

crw--w---- 1 jenny tty 4,

1er janvier 23 11:41 /dev/tty1

joe :~> ls -l /dev/tty1

crw--w---- 1 jenny tty 4,

joe :~> écrire jenny tty1

Salut Jenny, allons-nous déjeuner ensemble ?

^C

joe :~> écrire jenny tty1

Salut Jenny, allons-nous déjeuner ensemble ?

^C

Utilisateur jenny obtient ceci sur son écran:

message de [email protected] sur ptys/1 à 12h36 ... hé Jenny, on déjeune ensemble ?

EOF

message de [email protected] sur ptys/1 à 12h36 ... hé Jenny, on déjeune ensemble ?

EOF

Après réception d'un message, le terminal peut être effacé à l'aide du Ctrl+L combinaison de touches. Afin de ne recevoir aucun message (sauf de la part de l'administrateur système), utilisez le message commander. Pour voir quels utilisateurs connectés acceptent les messages des autres utilisent pour qui -w. Toutes les fonctionnalités sont expliquées en détail dans les pages d'informations de chaque commande.

Les noms de groupe peuvent varier

Le régime collectif est spécifique à la distribution. D'autres distributions peuvent utiliser d'autres noms ou d'autres solutions.

<Précédent | Table des matières | Suivant>