Peu de temps avant de commencer à écrire cet article j'ai réussi à résoudre un problème qui a été ma bête noire pendant ces deux dernières semaines. Étant donné que c'est un problème que j'ai vu souvent réapparaître dans la Linux Gazette, en général rédigé d'une manière laissant penser que l'auteur l'a écrit avec les doigts de pieds parceque debout sur une chaise et la corde au coup, j'ai décidé de partager mon expérience avec les autres lecteurs, leur évitant ainsi le gaspillage d'une bonne corde. Ca peut être également vu comme un bon guide pour se debrouiller des problèmes logiciels en général. Mais soyez cependant prévenu qu'un problème de login peut mêtre en jeu n'importe lequel des domaines couverts ici — ce qui a servi à résoudre mon problème n'est peut-être pas une solution pour vous.

Il y a quelques semaines de ça j'ai pris la décision d'installer un MUA (Mail User Agent — un logiciel pour lire mon courrier) sur ma machine. C'est quelque chose d'étonnant quand on sait que je vis sur un bateau ancré bien loin de toute ligne téléphonique ou même électrique, mais j'ai mes raisons. J'avais fait ça à terre avant ; je voulais juste essayer quelques trucs.

Un MUA n'est rien sans un logiciel qui distribue le courrier (un MTA : Mail Transfert Agent). Il faut donc faire une installation conjointe MTA/MUA. Pas de problème, j'ai toujours la distribution Debian complète sur une partition Linux de mon disque dur. Ça accélère les installation et ça rend les recherches de paquetages triviales.

Pour vous dire la vérité je n'aime pas la commande su ou tout du moins pour tout ce qui touche à des opérations majeures. Le fait que cette commande conserve l'environnement de l'utilisateur original plutôt que de prendre celui de la personne qui est su-dé m'a rendu certains moments « intéressants ». C'est bon pour faire des petites modifs de permissions ou des changements dans les fichiers de /etc, mais dès qu'il sagit de travail sérieux comme l'installation ou la désinstallation de plusieurs paquetages majeurs (je n'était pas sur du MTA que je voulais), je me loge en tant que root.

Au travail. Midnight Commander permet, en quelques frappes de touches, de parcourir et d'explorer des répertoires mais également de regarder le contenu (et d'installer) des paquetages Debian ou RedHat. Voyons voir... sendmail (lire la page de manuel à l'intérieur du paquetage, regarder les docs, installer...) Non, trop gros et trop compliqué. J'ai besoin de quelque chose de plus simple. (Je désinstalle sendmail). exim ?... exmh ?... mh ?... nmh ? Tous ont eu droit au même sort d'installation et de désinstallation. Ceci à l'exception des bibliothèques : si j'installe une bibliothèque, elle reste installée. En faisant ça sur un nouveau système on arrive rapidement au moment où ne se voit plus importuné par des requettes de bibliothèques non trouvées. Si certaines bibliothèques n'étaient pas mutuellement exclusives sur certaines distributions, je les installerais toutes pour ne plus jamais avoir à m'en soucier !

Cependant, il me restait toujours à trouver un MTA. Ah, smail ! Facile à installer, se configure sans peine, voilà, c'est fait. Le choix du MUA a été facile vu que j'aime beaucoup les possibilités de configuration de Mutt. Et c'est terminé ! (des mots prophétiques...)

SAUF QUE : je ne pouvais plus me loger en tant qu'utilisateur non-root. Le message que j'avais était :

Impossible d'exécuter /bin/bash : permission non accordée.

Qu'est-ce que diable c'était que cela ?

Je savais que je n'avais rien touché dans /etc/password et pour cause, je n'avais rien touché à ce qu'il y a dans /etc. Mais je n'étais pas 100% sûr de ce que ces paquetages, sécurisés comme ils sont sensés l'être, avaient fait avec mes privilèges root. J'ai tout de suite fait une vérification. Oui l'utisateur ben existe encore dans /etc/password ; idem pour le groupe ben dans /etc/group et le fait d'entrer un mauvais mot de passe me donnait bien le message « Login incorrect » au lieu du « Impossible d'exécuter ». Mouais !

Autre vérification : je crée un nouvel utilisateur (joe) avec un mot de passe (joe) :)) et je tente de me loger sous ce nom. Rien à faire, même erreur. Quelque chose était foutu dans la séquence de login, pour je ne sais quelle raison. (À Dieu joe...)

A ce moment là j'ai eu un peu peur ; j'ai sauté sur un autre terminal et j'ai essayé de me loger en tant que root. OUF ! Pas de problème de ce côté. J'aurai au moins encore accès à la machine la prochaine fois que je la remétrai en route... J'aurai détesté avoir eu à faire une sauvegarde à la volée et avoir tout à réinstaller !

Voyons voir dans /bin>. À quoi ressemblent les permissions des fichiers ? Ha, tout est à 755 (-rwxr-xr-x) ; en plus login, mount, umount, ping et su sont tous SETUID (-rwsr-xr-x). Jusque là tout va bien. Qu'en est-il des permissions de /etc ? Elles ont toutes l'air OK. 644 pour la plupart (-rw-r--r--), avec de temps en temps un 600 (-rw-------) ici et là pour les fichiers interdits à tous sauf à root. Bien, essayons quelque chose de stupide ; j'écrase login et bash avec de toutes nouvelles version à peine sorties de leur paquetage, juste pour être sûr qu'ils n'étaient pas corrompus. Ben non ; toujours pas de chance.

Attendez, et /home ? Si les permissions de ce répertoire étaient fausses et que l'utilisateur ne pouvait y accéder... Zut, c'était bon aussi : 6775 (drwxrwsr-s). Je n'ai rien trouvé de plus en vérifiant les fichiers .bashrc et .bash_profile ; de plus leurs permissions étaient correctes. Juste pour voir j'ai vérifié tous les répertoires de / ; tous sauf root étaient lisibles par tout le monde, c'est ce qu'il faut.

Dans /var il y a des fichiers qui conservent une trace des personnes qui se sont connectées, du moment où elles se sont déconnectées et du reste. Si ces fichiers sont corrompus, toutes sortes de choses étranges et imprévisibles arrivent. Donc, mesure d'urgence, je tape :

cat >/var/log/wtmp
cat >/var/run/utmp

Ceci a pour effet de détruire le contenu de ces fichiers et de les laisser vide avec une taille nulle.

Je me suis déloggé de tous les terminaux (comme ça, utmp et wtmp vont recevoir quelques infos), et... argh, le résultat habituel.

Qu'en est-il des permissions de /dev/ttyX et de /dev/vcsX (terminaux et consoles virtuelles) ? Elles étaient également toutes bonnes. Je commençais à perdre espoir.

Bon, et si je faisais une approche systématique ? Essayons d'avoir une idée de ce qui se passe exactement avant de faire tout et n'importe quoi. Je jette un œil, pour me raffraichir la mémoire, au Guide de l'Administrateur Système et, ah, voilà, le processus de login :

Tiré du « Guide de l'Administrateur Système » de Lars Wirzenius :

Si on suit le diagramme, on peut voir que tout semble bon au moins jusqu'à la dernière partie, le exec("/bin/sh"). C'est pendant, ou après cet appel, que tout fout le camp. Le problème était à présent au niveau des appels système, quelque chose que je ne savais pas comment approcher... et pourtant c'est là que se trouvait la solution ; seulement je ne savais pas comment l'appliquer. Plus tard ça deviendra évident.

Pendant à peu prés les dix jours qui suivirent, chaque fois que je me logais j'essayais quelque chose de nouveau ; des trucs complètement incongrus et très peu aptes à fonctionner ; parfois j'avais des idées géniales qui conduisirent à de grandes déceptions quand, encore une fois, ce satané message apparaissait. Rien ne fonctionnait. J'ai remplacé getty, j'ai essayé d'autres shells que /bin/bash, j'ai essayé de su-dé à ben, j'ai vérifié les fichiers de log (ils montraient que ben avait réussi à se connecter avec succès (!), ce qui m'appris que login fonctionnait correctement et que le problème venait de la prise en main de bash : je le savais déjà !)...

Après n'avoir trouvé que quelques références sur l'Internet, la plupart en japonais, suédois et allemand (j'ai réussi à faire quelque chose des deux derniers dont un suggerait de vérifier les permissions de / ! Excellente idée... qui ne mena à rien dans mon cas), j'ai lancé un appel au secour sur The Answer Guy... Salut ! :)) Malheureusement il a du être noyé dans toutes ces questions sur Windows2000 auquel il adore répondre... Allez, débrouille toi tout seul.

Ah ! strace ! Tu te souviens de strace ; strace est ton ami... Un super programme qui trace l'exécution d'un programme et en fait un rapport pas à pas. C'est parti !

Comme vous devez être logé pour lancer un programme, j'ai exécuté

strace -s 10000 -vfo login.ben login ben

depuis le terminal courrant. Ceci signifiait « Lance strace sur login ben ; affiche toutes les lignes de moins de 10000 caractères (je ne voulais pas rater de message, peu importe s'ils étaient très long) ; soit bavard ; fait un rapport de n'importe quel processus fork-é ; met le résultat dans le fichier login.ben ». Et pour avoir une base de comparaison je lançais

strace -s 10000 -vfo login.root login root

et à présent, j'avais deux fichiers à comparer. Celui de root était à peu prés deux fois plus long que celui de ben. Cela semblait correct vu qu'un login fructueux mène à l'exécution de tout dans les fichiers ~/.bash*.

strace login est très intéressant à lire. Si je n'avais pas lu le Guide de l'Administrateur Système avant, ça m'aurait donné toutes les informations précisément — avec bien plus de détails. Il montre toutes les bibliothèques qui sont lues, tous les fichiers qui sont examinés par login, les procédures de comparaison pour group et password... La seule chose qu'il ne montrait pas était la raison de l'échec ; uniquement le fait lui-même, exactement où je l'attendais :

(300+ lines elided)
execve("/bin/bash", ["-bash"], ["TERM=linux", "HZ=100", "HOME=/home/ben", 
    "SHELL=/bin/bash", "PATH=/bin:/usr/bin", "USER=ben", "LOGNAME=ben", 
    "MAIL=/var/spool/mail/ben", "LANG=C", "HUSHLOGIN=FALSE"]) = -1 EACCES 
    (Permission denied)            
write(2, "Cannot execute /bin/bash: Permission denied\n", 44) = 44

Super. Le dernière chose que ce pauvre login essaye de faire avant de se retrouver les quatre fers en l'air est d'execve bash avec les variables collectées dans /etc/password, /etc/login.defs et ainsi de suite — toutes paraissant OK — et d'écrire ces 44 caractères détestables sur stderr (descripteur de sortie numéro 2). En gros, ce dont je m'étais déjà rendu compte.

Cependant, j'ai remarqué que login ouvrait un certain nombre de bibliothèques dans /lib qui étaient nécessaires au fichier de configuration du Name Service Switch (littéralement le service de commutation de noms) : /etc/nsswitch.conf. Et si une des bibliothèques mentionnées était corrompue ? Ce serait en ligne directe avec la thèorie des appels système puisque les bibliothèques sont le point de départ de ces appels système ! Vérifions les bibliothèques qui se chargent des logins locaux pour NSS (reportez-vous à la page de manuel de nsswitch) :

dpkg -S libnss_compat-2.0.7.so

(« Dis moi, Ô puissant gestionnaire de paquetages Debian d'où vient le dit programme ? »), et l'Oracle Debian dans son infinie sagesse répondi :

libc6: /lib/libnss_compat-2.0.7.so

Mouais. Le cœur même des bibliothèques de Linux. Bon... je tente un rapide remplacement de toutes les bibliothèques /lib/libnss*... et pas de changement. Idée suivante.

Cependant cela me fit réfléchir. Il y avait vraiment « quelque chose de pourri au royaume de Danemark ». Peut-être devrai-je vérifier les permissions des fichiers dans /lib ?

Le seul problème était que je ne connaissais pas les valeurs qu'elles étaient sensées avoir. Vous voyez, la plupart des bibliothèques sont positionnées avec les attributs root.root 644 (propriétaire root, groupe root, utilisateur autorisé en lecture/écriture, groupe autorisé en lecture seule, les autres autorisés en lecture seule). Cependant certaines avaient des droits root.root 755, soit la même chose que précédemment mis à par une posibilité d'exécution pour tout le monde. Sans pouvoir jetter un œil a une installation récente de Linux, je n'avais aucune idée de ce qui était bon.

Mais, une seconde ! Comme je l'avais écrit dans un conseil à 3 sous que j'avais envoyé à la Linux Gazette, j'aime bien garder des fichiers copie de l'installation Debian de base (7 fichiers pour à peu prés 15 Mo) sur ma partition DOS comme utilitaire de sauvetage. Ça devrait contenir tout ce dont j'ai besoin !

Et tel fut le cas. Midnight Commander, par le biais de son Système de Fichiers Virtuel (VFS en anglais) vous permet d'explorer les fichiers compressés comme s'ils étaient des répertoires ; un coup d'œil à base2_1.tgz#utar/lib (la syntaxe VFS utilisée pas MC) me montra que l'une des toutes premières bibliothèques (ld-2.0.7.so) était sensée avoir des permissions positionnées à 755. Dix secondes plus tard, j'étais le propriétaire d'un tout nouveau VT en tant qu'utilisateur ben.

J'ai bien sûr vérifié les permissions de toutes les autres bibliothèques et ld-2.0.7.so avait éte la seule à être affectée. La seule inconnue était de savoir comment les permissions ont changé... mais je devine que cette question n'obtiendra jamais de réponse.

Comme d'habitude, les leçons que Linux nous enseigne sont dures, mais honnêtes. Il y a toujours un moyen de résoudre un problème ; il faut bien admettre que parfois, la manière la plus simple est de réinstaller tout le système, mais cela nous vous montre pas le « cœur » d'un OS ; ce à quoi le fait de rechercher la cause d'un problème aboutira. Dans mon cas la réinstallation aurait été assez facile : j'ai quelques disques dur de rechange, assez gros pour contenir toutes mes données, même les plus récentes, pour ne pas avoir à toucher à mes sauvegardes. De plus, l'installation basique d'une Debian ne me prend pas plus de 10 minutes. Mais cela ne m'interessait pas. Ce qui me venait constament à l'esprit était : « Que se passerait-il si cela arrivait à un de mes utilisateurs ? » Je devais savoir comment m'en sortir... et grace à la persévérance — non, uniquement pour emmerder le monde — j'ai réussi.

Je ne suis pas en train de vous conseiller de vous prendre la tête sur un problème une fois par semaine juste pour garder la forme, mais je suggère que vous utilisiez une approche méthodique, basée sur le savoir que vous avez acquis par la lecture des HOWTO appropriés ainsi que d'autres documentations que vous auriez pu vous procurer avant d'avoir recours, une fois de plus, au CD d'installation. Il se passera du temps avant que vous ne préfériez rire comme un maniaque en voyant votre système devenir gros comme une tête d'épingle aprés que vous l'ayez lancé de votre appartement tout en haut de l'Empire State Building... Et il se passera également du temps avant que la satisfaction d'avoir résolu un problème épineux comme celui-là vous fasse bomber le torse et vous lancer dans une imitation de Tarzan.

Et à présent, si vous voulez bien m'excuser, il y a un chimpanzé et un éléphant que je suis sensé rencontrer...

Joyeuses Linuxations à tous.