Pour ceux qui voudraient essayer le parachutisme, je vous le conseille, c'est très fort ! Par contre ça vous empêche d'écrire des articles ...

Vous venez de faire un chroot et vous voulez pouvoir vous connecter dessus comme s'il s'agissait de votre machine locale ?
Pas de panique, c'est tout simple.

Pour cela nous allons regarder 3 méthodes différentes de connexion à votre chroot : le terminal local, ssh et l'environnement graphique. Mais avant tout préparons le chroot à ressembler à une distribution normale.

$ mount --bind /dev $CHROOT_BASE/dev
$ mount --bind /proc $CHROOT_BASE/proc
$ mount --bind /sys $CHROOT_BASE/sys

Terminal local

Pour se connecter en local à votre machine, vous utilisez les consoles disponibles (alt-Fx ou ctrl-alt-Fx si vous êtes en mode graphique). Vous en avez 6 à disposition.

Pour faire simple, nous allons juste faire en sorte que les consoles 4 à 6 redirigent dans le chroot tandis que les 1 à 3 resteront dédiées à la machine principale.

Il suffit de modifier /etc/inittab :

# /etc/inittab
1:2345:respawn:/sbin/getty tty1
2:2345:respawn:/sbin/getty tty2
3:2345:respawn:/sbin/getty tty3
4:2345:respawn:chroot <CHROOT_BASE> /sbin/getty tty4
5:2345:respawn:chroot <CHROOT_BASE> /sbin/getty tty5
6:2345:respawn:chroot <CHROOT_BASE> /sbin/getty tty6

Et là, soit vous redémarrez (bof on n'est pas sous windows) soit vous forcez init à relire sa configuration :

# en root
$ telinit q
$ pkill getty

Et maintenant passez à la console 4 (ctrl-F4) et vous pouvez vous connecter avec votre utilisateur intérieur au chroot.

SSH

Si vous vous connectez à votre machine en ssh, vous pouvez vouloir faire de même pour votre chroot.

Pour ce faire, vous pouvez lancer un service ssh à l'intérieur du chroot. Tout simplement :

$ chroot $CHROOT_BASE
$ apt-get install openssh-server

Par contre vous ne pouvez pas laisser ssh tourner sur le même port que le ssh qui tourne déjà. Utilisez donc un autre port, par exemple le 1022 :

$ vi $CHROOT_BASE/etc/ssh/sshd_config
> Port 1022

Puis lancez ssh dans le chroot :

$ chroot $CHROOT_BASE /etc/init.d/ssh restart

Vous pouvez maintenant vous connecter directement au chroot :

$ ssh -p 1022 user@leserveur.com 

GDM

Maintenant si votre habitude est d'avoir un environnement de bureau comme gnome, il faut faire pareil pour lui.

Tout passe par le login manager. Je prends l'exemple de GDM, mais vous pouvez faire la même chose avec KDM.

Tout d'abord, vous devez avoir un gdm d'installé dans le chroot, donc un environnement graphique minimal.

Une fois installé dans le chroot, par exemple avec :

$ chroot $CHROOT_BASE apt-get install gnome

Éditez le fichier de configuration de gdm $CHROOT_BASE/etc/gdm/gdm.conf :

[daemon]
# ceci devrait être inutile, mais on ne sait jamais
FirstVT=8

[server]
0=Standard device=/dev/console

Relancez gdm dans le chroot :

$ chroot $CHROOT_BASE /etc/init.d/gdm restart

Et voilà, rendez-vous sur la console 8 (ctrl-alt-F8) pour obtenir un login graphique dans le chroot. Sur la console 7 (ctrl-alt-F7) le login original est toujours disponible.

Si vous avez aimé, il y a aussi :

1. Configuration de init
2. Chroot
3. Chroot toujours

Niveau :      
Résumé : adb shell

Il y a peu je me suis offert un téléphone android. Devinez quoi ... c'est un linux (pas GNU pour une fois, plutôt un dalvik/linux).

Seule ombre au programme, je ne suis pas root dessus. C'est pas très fair play de la part du vendeur sachant que le téléphone m'appartient. Comment faire pour supprimer les applications installées par le fabriquant et qui me cassent les *** à se lancer sans me demander mon avis ?

Ma première mission est donc de devenir root.

Les habitués des OS de bureau auront l'idée de toucher au bootloader pendant qu'il boote. Bonne idée, mais sur une telle machine le bootloader est assez sobre, et plutôt protégé, ne parlons pas du bios. J'ai donc ignoré cette technique pour passer à une méthode plus courantes pour les bidouilleurs de tout poil : exploiter une faille de sécurité.

C'est donc grâce aux failles de sécurité que je vais avoir le droit d'accéder au système de ma propre machine ! Autrement dit, c'est parce que le fabriquant protège mal le système qu'il m'a vendu que mes droits de consommateur sont respectés ...

Les bases

Passons aux bases du téléphone, c'est un linux, mais il ne faut pas s'attendre à avoir tous les outils en ligne de commande auxquels vous êtes habitués. Pour obtenir un shell utilisateur simple (ça vous avez le droit) :

• installer le sdk android (une simple extraction)
• aller dans les paramètres / application / développement et activer le débogage USB
• branchez le câble
• sur le pc dans sdk/platform-tools lancez ./adb devices, votre téléphone doit être listé sinon il y a un problème
• tapez ./adb shell et hop vous êtes sur votre téléphone

Là on est sur un terrain presque connu : un shell, qui tourne avec l'utilisateur shell. Il est limité, mais on s'y fait. Par contre l'arborescence est inhabituelle. Je vous laisse explorer ... Pour mémoire, voici les répertoires à la racine :

/acct        # accounting
/bin         # comme unix
/cache       # contenu temporaire
/config      # vide chez moi
/d           # debug
/data        # /var d'unix
/dev         # comme unix
/etc         # comme unix
/init        # comme unix
/init.rc     # comme unix
/misc        # vide chez moi
/mnt         # comme unix
/proc        # comme unix
/root        # comme unix
/sbin        # comme unix
/sdcard      # partition fat visible aux utilisateurs
/sys         # comme unix
/system      # partition readonly contenant le système android
/usbdisk     # vide chez moi

Les android étant personnalisés par le constructeur, votre version variera nécessairement.

Les failles (pour passer root)

Maintenant on veut passer de shell à root. Il est temps de passer du côté hacking de la force. Ceux qui se sentent l'âme d'un hacker expérimenté peuvent chercher eux-même les failles dans le système. Les autres vont tenter les 2 ou 3 failles connues avec les exploits associés :

• dépôt d'un fichier suid root exécutable, nommé su (il parait que ça marche sur certaines machines, je ne vois pas comment ...)
• exploid
• rageagainstthecage
• psneuter

Le binaire et les source de ces exploits sont disponibles ici.

En général il s'agit de le mettre dans un répertoire inscriptible et permettant les exécutables puis de le lancer. Il semblerait que /data/local/tmp soit disponible un peu partout pour ça.

Dans mon cas (optimus 2X) c'est psneuter qui fonctionne. Pour les autres, dites moi ce qui marche chez vous, je n'ai pas assez d'argent pour tester tous les android :)

$ ./adb push psneuter /data/local/tmp
$ ./adb shell
$ chmod 555 /data/local/tmp/psneuter 
$ /data/local/tmp/psneuter 

On attend, on relance un adb shell et miracle on est root !

Busybox

Maintenant installons un environnement un peu plus user-friendly :

• télécharger busybox
• installer busybox :

$ ./adb push busybox /data/local/tmp
$ ./adb shell
$ chmod 555 /data/local/tmp/busybox
$ mkdir /data/busybox
$ /data/local/tmp/busybox --install
$ export PATH=/data/busybox:$PATH 

Et voila ! Une vraie ligne de commande sur notre petite machine. On peut maintenant découvrir l'os et faire joujou comme on veut.

Rendons tout ça permanent

N'ayant pas trouvé de su compilé qui marche sur mon android et ayant la flemme de compiler moi-même, j'ai fait avec les moyens du bord. Ma méthode d'origine était de mettre en place un shell setuid. Malheureusement, le shell vérifie que sont uid correspond à son euid et si ce n'est pas le cas il revient en arrière. J'ai été abusé par le fait qu'il affiche tout de même un #. Ce comportement, naturel pour un script ne l'est pas nécessairement pour un shell interactif mais c'est un fait.

J'ai donc fait avec les moyens fournis par busybox :

$ mount -o remount,rw /system
$ mkdir /system/bb       # /system/bin/su existe déjà
$ cp /data/busybox/su /system/bb
$ chmod 4550 /system/bb/su
$ echo 'root::0:' > /etc/group # /etc est dans /system
$ echo 'root::0:0:root:/root:/system/bin/sh' > /etc/passwd
$ passwd # si vous voulez un vrai mot de passe
$ mount -o remount,ro  //system # retour à la normale

Après le prochain reboot, pour devenir root (avec un mot de passe) :

$ ./adb shell
$ /system/bin/su

Note : Revenir en arrière est l'affaire de quelques suppression (/data/busybox, /system/bin/su, /etc/passwd et /etc/group). Vous n'avez donc rien fait de violent à votre téléphone, vous avez maitrisé ce que vous avez fait et c'est presque invisible.

Sécurité : A tous ceux qui rootent leur android en passant par une application toute faite, savez-vous ce que fait cette application dans votre dos ? Ne fait-elle pas autre chose que vous faire passer root ? Savez-vous qu'elle installe un binaire su permettant à n'importe quelle application (et pas seulement SuperUser.apk) de passer root si elle connait l'existence de ce binaire ...

On me dit que lors de son premier lancement SuperUser.apk se met lui-même en setuid et enlève le setuid du binaire su. Ce qui du coup vous retire le root avec adb.

PS : Message personnel à Bob Morane, j'ai rien compris à ta suggestion, dans quelle situation y a-t-il des liens qui se chevauchent ?

Si vous avez aimé, il y a aussi :

1. Une distribution GNU sur android
2. Personnalisez votre android
3. Espionner son android

Exécution

Savez-vous qu'on peut rendre n'importe quel fichier exécutable sous linux ? Bien sûr il suffit de faire un chmod +x, mais le noyau risque de vous envoyer balader si le fichier n'est pas réellement exécutable.

Mais je parle ici de rendre exécutable n'importe quel fichier, un jar, un source en C, un MP3 ...

Mais comment quoi que donc !?

Pour exécuter un fichier, le noyau lit les premiers octets du fichier et vérifie qu'ils correspondent à un format binaire (binfmt) connu. Il existe un système pour ajouter des formats binaires à ceux déjà supportés dans le noyau (en gros les elf et les scripts). Il s'agit du format misc.

Pour savoir si ce format est supporté chez vous, ce qui est très probable, lancez la commande :

$ cat /proc/sys/fs/binfmt_misc/status

S'il n'est pas supporté, il faut charger le module et monter le répertoire :

$ modprobe binfmt_misc
$ mount binfmt_misc -t binfmt_misc /proc/sys/fs/binfmt_misc 

C capital

Maintenant supposons vous vouliez rendre les fichiers .c exécutables. Vous pouvez soit utiliser un de mes anciens articles ... soit créer un petit script qui sera appelé à chaque exécution d'un .c :

#!/bin/sh
# /usr/local/bin/ccexec
gcc -Wall -o /tmp/cscript.$$ "$1" && shift && /tmp/cscript.$$ "$@"
ret=$? ; rm -f /tmp/cscript.$$ ; exit $ret

Et de faire en sorte qu'il soit réellement appelé :

$ echo ':cfile:E::c::/usr/local/bin/ccexec:' > /proc/sys/fs/binfmt_misc/register

Hop un test :

#include <stdio.h>
// test.c
int main() {
  printf("Coucou\n");
  return 0;
}

Et on lance :

$ chmod +x test.c
$ ./test.c
> Coucou

Yeah !!!

G tout compris

Maintenant, passons à l'exécution d'un gzip. Plutôt que de reconnaître le fichier à son extension, ce qui est franchement faible comme méthode nous allons vraiment détecter le type de fichier.

Allons voir la spécification, un fichier gzip se reconnait à ses 2 premiers octets qui doivent valoir 0x1f et 0x8b :

$ echo ':gzip:M::\x1f\x8b::/bin/gunzip:' > /proc/sys/fs/binfmt_misc/register

Même méthode et ça marche. Notez qu'il est possible d'utiliser n'importe quel champs de bits grâce à une masque et une position de départ, mais seulement dans les 128 premiers octets du fichier.

Enfin, certaines distributions vont vous installer des choses un peu plus utiles comme l'exécution des jar avec java ou celle d'exécutable windows avec wine.

Et pour une spécification plus détaillée de ce qu'il lest possible de mettre dans la ligne d'enregistrement, direction la documentation

PS : pour supprimer l'entrée : echo -1 > /proc/sys/fs/binfmt_misc/cfile

Si vous avez aimé, il y a aussi :

1. #!/usr/bin/gcc (bis)
2. Changer la priorité d’exécution des processus
3. Trucs et astuces (5)

Le temps est absolu

Le temps est quelque chose de sensible. Si mon serveur est en retard il va croire que la personne qui vient de s'authentifier sur mon site essaie de me flouer en me donnant une date invalide. S'il est en avance, il va croire qu'il n'est pas venu depuis longtemps et va le déconnecter.

Il est donc important d'être toujours à l'heure, car l'heure c'est l'heure et quand il est pas encore l'heure c'est pas l'heure et s'il n'est plus l'heure ce n'est toujours pas l'heure. Vous me suivez ?

Mais pour une fois je ne vais pas vous parler de l'heure selon NTP, mais l'heure selon Saint Matthieu, enfin presque.

Supposons que, grâce à votre professionnalisme, votre machine soit à l'heure, voire à la seconde, grâce à NTP. Supposons que vous vouliez connaitre cette heure. Que faites-vous ? Vous la demandez au noyau (via time ou gettimeofday), et il vous la donne en UTC ...

Mais en pratique vous voulez l'heure de chez vous, celle qui dit que le soleil va se coucher dans la belle province. Bien sûr la libc va faire la conversion pour vous (via localtime, mais voyons comment elle fait.

Enfin presque

La date et l'heure s'expriment de plusieurs façons. L'heure UTC est la version "absolue"', c'est à dire qu'elle ne dépend pas des différentes régions de la planète où l'on se place. Mais tous les pays ne l'entendent pas de cette oreille et veulent chacun définir leur heure. Définition qui peut changer dans le temps ...

Pour faire la conversion, il faut donc connaître toutes ces règles. Heureusement des acharnés on fait ce travail de récupération et les ont déposées dans /usr/share/timezone sur le système de fichier.

Vous croyez qu'il n'y à que 24 fuseaux horaires ? Faux il y en a un peu plus. Maintenant comptons les timezone :

$ find /usr/share/zoneinfo/ -type f | wc -l
1764

Imaginez le temps qu'il a fallu pour compiler ces données ...

Vous constaterez que ce sont des fichiers binaires. La libc les lit directement (pour en savoir un peu plus, man tzfile et man tzset), mais pour nous humains ? On utilise zdump

$ zdump -v Europe/Paris

Vous y verrez les changements d'heure une seconde avant et une seconde après chaque changement. Remarquez qu'il y a plus d'information dans le binaire que dans le dump qui ne fait qu'afficher les dates de saut temporel.

Pas du tout

Mais aujourd'hui est un grand jour, je vais faire ma propre nation (une de plus). J'y édicterai un nouvel horaire, UTC+1,25 et heure d'été en UTC +0,75. Le changement se fera à MON anniversaire.

Il faut donc que je crée un fichier de zone correspondant à mon pays. Prenons le source suivant :

# règles de changement d'heure
Rule peck 2010 max odd Mar 6 4:00 -0:30 -
Rule peck 2010 max odd Sep 6 4:00 0 -
# définition de l'heure standard dans la zone
Zone peck 1:15 peck PCK

Et on le compile avec zic :

# notez que j'ai récupéré yearistype dans le source de tzdata
# il permet l'usage de odd dans mon fichier de règles
$ /usr/sbin/zic -d . -y "sh yearistype.sh" peck

Il suffit maintenant de le déposer dans /usr/share/timezone et voilà ce qu'on peut obtenir :

$ TZ=peck LC_TIME=C date
Mon Mar  7 17:48:02 PCK 2011
# notez la différence (UTC+x et PCK)
$ TZ=peck LC_TIME=fr_FR date
lundi 7 mars 2011, 17:48:37 (UTC+0045)

Votre timezone perso !

Pour des exemples complets et complexes de zones, vous pouvez regarder le source du paquet tzdata. C'est votre référence, mais je doute que vous ayez à y toucher prochainement !

Quelle différence y a-t-il entre /dev/random et /dev/urandom ? Et d'abord à quoi servent-il ?

Aléatoire

Qu'est-ce qu'un nombre aléatoire ? C'est un nombre faisant partie d'une série dont on ne peut pas prédire le prochain à partir des nombres précédents de la série.

Il existe de nombreuses méthodes pour créer des nombres aléatoires. Je vous donne la plus mauvaise : rand : i -> 0

Mais il existe aussi des suites moins prévisibles, par exemple prendre le dernier chiffre d'une opération récursive produisant de grands nombres. Voire complètement imprévisible comme utiliser la mesure d'un bruit blanc.

Il existe donc plusieurs niveaux d'"aléatoirité" ou de "prévisibilité". Un bon générateur qui peut par exemple être utilisé en cryptographie est en pratique soit un générateur matériel, soit un générateur basé sur un état interne et une fonction de hachage forte.

Les générateurs logiciels sont appelés PRNG (pseudo random number generator). Puisqu'un tel algorithme est déterministe, il faut l'initialiser avec des valeurs vraiment aléatoires pour éviter qu'on puis en deviner la sortie en devinant comment il a été initialisé.

Entropie

Sous linux il y a deux sources de nombres aléatoires, /dev/random et /dev/urandom.

La première utilise uniquement l'entropie disponible pour fournir des nombres aléatoires et le second est un générateur pseudo aléatoire initialisé avec cette entropie.

Mais qu'est-ce que l'entropie ?

On y vient, l'entropie est une quantité de bits qu'on considère comme totalement aléatoires, donc générés par des évènements physiques. Sous linux, lorsqu'on ne dispose pas d'une puce générant ces nombres aléatoires, on utilise des choses comme l'intervalle entre deux interruptions pour créer les bits d'entropie.

Mais alors quel générateur faut-il utiliser ?

/dev/urandom est pseudo aléatoire, très pratique pour la plupart des usages, il permet de générer autant de nombres qu'on veut à un rythme soutenu.

/dev/random est complètement aléatoire, on ne l'utilise que lorsqu'on en a vraiment besoin, il utilise directement le pool d'entropie et ne donc fournir qu'un nombre limité de bits, il se remplit progressivement mais lentement.

Il me manque de l'entropie

Si vous avez besoin de beaucoup de nombres vraiment aléatoires (pour générer de nombreuses clés ssh par exemple), vous allez avoir besoin de beaucoup d'entropie.

Avant de tenter de rajouter de l'entropie, mesurons-la.

Deux méthode pour ca :

# pour obtenir l'entropie disponible à un instant t
$ cat /proc/sys/kernel/random/entropy_avail

# pour voir la vitesse de remplissage du pool d'entropie (en le vidant)
$ cat /dev/random | cpipe -ngr -vt > /dev/null

C'est là qu'on découvre cpipe, petit outil très sympa pour mesurer la bande passante d'un pipe.

Maintenant on peut laisser cette commande tourner en tache de fond et tenter d'ajouter de l'entropie pour trouver la meilleurs méthode. Quelques tests (en root de préférence)

$ while true; do cat /boot/vmlinux.gz > /dev/random; done
# -> rien
$ find / > /dev/null
# -> pas mal
$ # déplacer la souris
# -> un peu moins
$ yes # dans un terminal ssh distant
# -> un peu moins
$ ssh  machine distante "cat /dev/zero" > /dev/null
# -> rien

Attention, les résultats ne sont pas forcément les mêmes sur une vm. Conclusion temporaire : les sources d'entropie sont le disque dur (résultat du find) et la souris.

A vous d'en trouver d'autres ...

Bon j'en ai une autre pour vous. En fait il existe une api à base d'ioctl pour ajouter de l'entropie au noyau depuis l'espace utilisateur. Mais il faut faire attention à bien jouter de la vraie entropie et pas une suite de nombres prévisibles.

Pour faire ça, quelqu'un a fait un démon permettant de remplir ces bits avec différentes sources : la carte son, une entrée vidéo ou les variations de précision du timer idée originale, n'est-il pas ?

Si vous avez aimé, il y a aussi :

1. Cryptologie
2. Protection de clés grâce aux demi-bits
3. Attaché chrooté

Vous souvenez-vous de PAM (Pluggable Authentication Modules) ? En plus des nombreux modules déjà présentés, on trouve pam_exec qui permet d'exécuter une commande arbitraire. A partir de là on peut faire pas mal de choses, comme par exemple une notification à chaque session ouverte par un utilisateur (connexion ssh, su, sudo, etc.).

Notification de connexion

Nous allons créer une règle utilisant le module pam_exec pour exécuter un script de notification à l'ouverture d'une nouvelle session.

Script de notification

D'après le manuel de pam_exec, les informations PAM sont passées au script à l'aide des variables d'environnement : PAM_RHOST, PAM_RUSER, PAM_SERVICE, PAM_TTY, PAM_USER et PAM_TYPE. Concevons donc un script simple qui :

• ne s'intéresse qu'au cas de l'ouverture d'une nouvelle session, soit le type PAM open_session
• récupère les informations et les envoie par mail à l'administrateur

#!/bin/sh
[ "$PAM_TYPE" = "open_session" ] || exit 0
{
  echo "User: $PAM_USER"
  echo "Ruser: $PAM_RUSER"
  echo "Rhost: $PAM_RHOST"
  echo "Service: $PAM_SERVICE"
  echo "TTY: $PAM_TTY"
  echo "Date: `date`"
  echo "Server: `uname -a`"
} |mail -s "`hostname -s` $PAM_SERVICE login: $PAM_USER" root

On peut sauver ce script sous /usr/local/bin/pam-notify-login et n'oublions pas de le rendre exécutable :

# chmod a+x /usr/local/bin/pam-notify-login

Remarque : vous aurez besoin d'une version récente des modules PAM pour avoir la variable d'environnement PAM_TYPE envoyée par le module pam_exec. En effet celle-ci n'a été ajoutée qu'à partir de la révision 1.8. Concrètement Debian lenny ne l'a pas (libpam-modules 1.0) alors que squeeze l'a (libpam-modules 1.1).

Règle pam_exec

Après consultation de la documentation Linux-PAM, voici la règle à utiliser :

session    optional     pam_exec.so    /usr/local/bin/pam-notify-login

Il faut maintenant l'ajouter à tous les services interactifs (donc pas cron) qui utilisent PAM : SSH, login, su, sudo, etc. Sous Debian (et certainement d'autres distrib), on peut le faire grâce au fichier /etc/pam.d/common-session qu'incluent les services intéractifs. On ajoute donc cette règle à la fin du fichier.

Attention cependant si vous utilisez sudo sous Debian, un petit oubli fait que la règle de sudo n'inclut pas ce fichier. On doit donc rajouter la règle à la main dans /etc/pam.d/sudo en attendant mieux.

Une fois les règles ajoutées, essayez de vous connecter en SSH, de faire un su ou un sudo : vous devriez recevoir la notification par mail.

PS : Ceci est un billet invité, s'il vous a plu, vous pouvez aller lire la prose de StalkR en version originale sur son site.

Si vous avez aimé, il y a aussi :

1. En vrac (20)
2. En vrac (22)
3. Connaitre les protocoles : POP

Les processus comme je l'ai déjà décrit, forment une grande famille.

La famille processus

Dans la famille processus je voudrais le père

Les processus se reproduisent par fork (Mitose en français). Ce qui veut dire qu'à la genèse il n'y avait qu'un processus que nous ne nommerons pas Adam mais init.

Tous les processus possèdent un identifiant (pid) ainsi qu'un identifiant de processus parent (ppid) permettant de les repérer dans un arbre généalogique (pstree).

Comment reconnait-on le père du fils lors du fork d'un processus ? Uniquement par le code de retour de la méthode fork qui vaut 0 pour le fils et donne le pid du fils au père. En dehors de cela les 2 processus sont rigoureusement identiques.

Dans la famille processus je voudrais la mère

Désolé, il n'y a pas de femme chez les processus, la reproduction est asexuée, mais c'est une idée à creuser ...

Dans la famille processus je voudrais le fils

Lorsqu'un processus forke, en général le père poursuit sa vie comme si de rien n'était, par contre le fils va muter. La mutation génétique chez les processus est bien plus violente que chez les êtres vivants. En effet, le code (l'ADN en français) est intégralement relu et remplacé depuis un nouveau fichier sur le disque. C'est ce qu'on appelle un exec.

Il existe quelques cas de processus qui ne fonctionnent pas comme ceci, mais qui laissent leur père mourir (ingrats !) et qui prennent leur place. C'est le cas des démons (un parricide est-il un démon ?) dont le but est de devenir indépendants (émancipés) et ne plus avoir de problèmes d'adolescence (le tty du père) ou de famille (le groupe de processus).

Dans la famille processus je voudrais le grand-père

Lorsqu'un processus meurt, sa dépouille est remise à son père. Elle est essentiellement constituée de son code de retour.

Lorsque le père est déjà mort, c'est le doyen qui a la charge de récupérer le code de retour, par exemple avec la méthode wait.

Dans la famille processus je voudrais le zombie

Si le père ne s'occupe pas des funérailles du fils bien aimé, celui-ci erre dans les méandres du noyau en attendant que quelqu'un veuille bien l'enterrer.

C'est ce qu'on appelle un zombie, caractérisé par la lettre Z ou par le mot defunct dans la liste des processus. Il est impossible de tuer un zombie (il est déjà mort). Seul son ascendant le plus proche le peut.

Heureusement l'ascendant universel, père de tous les processus, j'ai nommé init, prend soin de la dépouille de tous les enfants qui lui sont confiés. Donc si le père d'un zombie meurt, init s'occupera de le faire disparaître.

Les non processus

Chez les amis des processus voudrais le thread

Le thread n'est pas vraiment un processus, c'est un élément de processus, tout comme la main est un élément du corps. Avoir plusieurs threads permet à un processus de faire plusieurs choses en même temps tout en restant une seule entité. Cela permet par exemple de dédier une main au traitement et un pied à l'affichage (oui on s'y prend souvent comme des pieds pour faire des IHM, sauf certains qui y dédient la casquette).

Chez les amis des processus je voudrais le binaire

Le binaire (ou fichier exécutable) est le modèle du processus, l'ADN si vous préférez. Sans binaire, impossible de créer un processus. Celui-ci est inerte et manipulable aisément.

Chez les amis des processus je voudrais la bibliothèque

La bibliothèque c'est un bout de code qui peut être réutilisé par des processus, tout comme les plasmides , elles s'intègrent à n'importe quel autre processus pour leur apporter une fonctionnalité donnée.

Chez les amis des processus je voudrais le thread noyau

Le thread noyau est un cas particulier de thread, il tourne dans l'espace noyau et ne partage donc sa mémoire qu'avec le noyau mais ne rentre dans aucun processus. On devrait les appeler des anges puisque ce sont des être invisibles (ou presque) agissant au compte de dieu (le noyau).

Chez les amis des processus je voudrais le core

Le core, ou core dump est la version fossilisée d'un processus mort au combat. Lorsqu'un processus meurt il est effacé de la mémoire, mais s'il meurt dans des conditions exceptionnelle, par exemple s'il s'est pris un coup de signal (man kill) dans la tête et qu'un résineux est à proximité (ulimit -c) on le coule dans l'ambre pour une analyse ultérieure. gdb est un grand ami médecin qui est aussi légiste, il saura vous aider le temps venu.

Si vous avez aimé, il y a aussi :

1. Processus et threads
2. Brutus Processus
3. Processus de boot