Que retenir de "Bourne Into Oblivion" ?

#rm -rf /On m’a fait lire hier un article, « Bourne Into Oblivion« , dans lequel l’auteur explique comment ce qu’il nomme une bombe à retardement a eu des conséquences gravissimes pour le système informatique d’une société. En résumé, un script d’administration faisait le ménage après avoir terminé sa tâche grâce à un rm -rf $var1/$var2. Mais ce script s’est vu exécuté avec $var1 et $var2 non définis, et s’est donc terminé avec un rm -rf /, en root, sur un NFS (pour les non unixiens, cela signifie effacer l’intégralité des systèmes de fichiers du réseau, avec le droit de le faire). Autant dire que c’est une catastrophe sans nom pour la société, surtout lorsque l’on ajoute que c’est à ce moment que les backups se révèlent être inutilisables.

Cette histoire qui ferait froid dans le dos à tout administrateur système m’a plongé dans une réflexion, que voici, sur la liste finalement assez importante d’erreurs ayant conduit à cet accident. Le but n’est pas de critiquer, mais de voir ce qu’il est possible d’apprendre de tout cela.

Tout d’abord, il est clair que ce script était exécuté avec des privilèges bien trop importants. Il n’y a que peu de choses qui puissent justifier qu’un script doive être lancé en tant que root. Il aurait dû être lancé en tant que simple utilisateur sans privilège, éventuellement avec un compte créé spécialement dans ce but. Les opérations nécessitant réellement des droits de super utilisateur auraient dû être isolées et appelées avec un sudo ou encore disposer d’un bit suid. Pour le reste, et notamment tout ce qui s’apparente à de la lecture, des droits correctement affectés avec des groupes auraient dû suffire. D’une façon générale lancer un script en root n’est absolument pas anodin, et au delà du problème rencontré ici, se pose celui de la possibilité d’une faille de sécurité.

L’article mentionne de plus le fait d’avoir lancé un script pour le week-end, autrement dit pour une durée d’exécution a priori relativement longue. Si le fait de laisser une tâche d’administration sans surveillance est courant, le fait que ce soit en tant que root change la donne et vient aggraver, s’il était besoin, le point précédent.

La justification de l’exécution en tant que super utilisateur mise de côté, ce bout de script n’était manifestement pas assez défensif étant donné ce contexte particulièrement dangereux. Son auteur n’aurait jamais dû laisser un tel appel se faire sans un test des deux variables. Cela dit le script n’était peut-être pas prévu à l’origine pour être lancé en tant que root, ce qui amène donc à considérer comme règle qu’un code faisant ce type de manipulation doit être défensif quoi qu’il arrive, dans la mesure où l’on ne sait pas dans quelles conditions il peut-être amené à être utilisé par la suite.

On peut de plus remarquer que le fait d’utiliser un répertoire à la racine est déjà discutable. Si cette remarque peut sembler être un pinaillage purement cosmétique, on s’aperçoit que si en pratique les répertoires utilisés avaient été /tmp/$var1/$var2 ou encore /usr/src/$var1/$var2 par exemple, un tel drame ne serait pas survenu.

Pour finir sur l’aspect purement administration, ce script aurait dû être documenté. D’après l’article, l’absence de définition des variables est la conséquence du fait que l’opérateur ne savait pas qu’il y avait des opérations à effectuer au préalable. Ce point aurait donc dû être documenté. Cependant l’expérience montre que documenter n’évite pas les accident, et reste donc insuffisant (d’ailleurs le script était peut-être même déjà documenté) : j’ai l’exemple d’un script qui servait à envoyer un mail informatif à une base d’utilisateurs, et qui portait le nom pour le moins clair de spam.sh. Il avait pourtant fallu commenter la commande essentielle du script depuis que quelqu’un l’avait lancé par erreur, n’ayant apparemment pas considéré son nom comme un avertissement suffisamment clair sur l’effet du script. Un autre exemple amusant est le message d’avertissement du système Debian en cas de apt-get jugé un peu trop violent : il demande alors de taper en toutes lettres « Oui, faites ce que je vous dis ! ». Quoi qu’il en soit, il faut d’une façon ou d’une autre, mais par un moyen technique, mettre une commande dangereuse hors de portée de toute personne qui n’est pas parfaitement renseignée.

Accessoirement, Joel Spolsky explique au deuxième point de son célèbre article, « The Joel Test« , que d’après lui l’opération de compilation et livraison d’un projet doit pouvoir être faite en une seule action, car toute étape supplémentaire entraîne la possibilité d’une erreur. L’erreur dont il est question ici et les conséquences qu’elle a eu montrent que finalement, la règle peut être étendue à toute opération d’administration.

D’autres erreurs, de nature plus humaine, sont également à l’origine de cet accident. Comme le souligne l’auteur de l’article, le passage de compétences ne s’est pas fait correctement par exemple, et la gravité de la tâche d’administration a été négligée en étant affectée à un novice. Je ne m’étendrai pas plus sur ce sujet, qui n’est plus celui de ma réflexion.

Aussi pour conclure, on se rend compte que cet incident, qui est extrêmement grave pour une société puisqu’il peut lui être fatal si les données ne sont pas récupérées, aurait pu être évité par de simples précautions. Pour la plupart d’entre elles, une seule de ces précautions aurait suffit à éviter cela. Mais peut-être que parce que ces précautions semblent dérisoires, elles sont négligées. Paradoxalement elles semblent tellement évidentes que les rappeler peut également paraître dérisoire.

Voilà en substance la réflexion que m’inspire cette histoire. N’ayant pas la prétention d’avoir plus de quelques notions d’administration système, je suis peut-être passé à côté de points importants. Si vous en voyez, n’hésitez pas à en faire part en commentaires.

Quel futur en imagerie numérique – Un spectre affichable plus large

Depuis l’apparition des premiers affichages couleurs et jusqu’à aujourd’hui, les écrans reposent sur la nature de l’œil humain, et représentent les couleurs dans l’espace RVB (rouge, vert, bleu). L’objet de ce billet est de s’interroger sur la validité de ce choix, et de manifester une certaine impatience envers une nouvelle technologie en la matière.

Sans aller plus loin que quelques considérations superficielles, rappelons que la rétine, le capteur au fond de l’œil, est composée de bâtonnets, qui sont sensibles à la luminosité, et de trois types de cônes, respectivement sensibles à trois plages de fréquences grossièrement centrées sur le rouge, le vert et le bleu. C’est la raison pour laquelle les affichages utilisent les couleurs rouge, vert et bleu : c’est la synthèse additive.

Planche n°19 du test du Docteur Shinobu Ishihara
Pourtant tout le monde n’est pas nécessairement sensible à ces trois couleurs. L’exemple le plus commun est le daltonisme : certaines personnes n’ont que deux, voire un seul type de cône, ce qui explique le fait qu’elles sont incapables de distinguer certaines couleurs. La forme la plus commune de daltonisme (la deutéranopie : l’absence de cône sensible au vert) est ainsi de percevoir indistinctement le rouge et le vert.

Mais alors, inversement, les personnes non daltoniennes ne sont-elles pas finalement daltoniennes dans une certaines mesures elles aussi ? N’y a-t-il pas des couleurs que mêmes les gens avec une vision considérée comme normale ne peuvent distinguer ? Je n’entends pas par là notre capacité à ne percevoir que le spectre dit visible, où à nécessiter un minimum d’écart entre deux teintes pour pouvoir les différencier. Mais par exemple, lorsqu’un écran affiche du vert et du rouge simultanément, on perçoit du jaune. Mais est-ce du jaune pour autant ? Non. Pour s’en convaincre, testons : observons son spectre lumineux. Pour cela, voici donc l’image présentée dans le précédent billet, représentant différentes franges de couleurs.

Franges de couleur

Le but est donc de constater la contribution de chaque frange dans les différentes fréquences du spectre visible, qui rappelons-le ressemble à ceci.

Spectre de la lumière visible

Notez comme toutes les couleurs des franges sont présentes dans ce spectre. Idéalement, une frange devrait donc avoir une forte intensité à la fréquence correspondant à sa couleur, indépendamment d’une éventuelle intensité sur d’autres fréquences.

Avec l’aide d’un CD, ou de tout autre objet capable de diffracter la lumière, observons donc le spectre des différentes raies. Les photos qui suivent présentent plusieurs problèmes, qu’il convient de prendre en compte. L’écran de test tout d’abord est un cathodique (je referai peut-être un test avec un LCD si l’occasion se présente), dont le calibrage est probablement discutable. La balance des blancs de la prise de vue n’est quant à elle pas terrible, d’où un jaune qui semble tirer sur le vert. Enfin il faut remarquer que les franges ont une certaine largeur (il fallait pouvoir les photographier), ce qui entraîne un spectre moins précis (les décompositions sur la largeur d’une frange se chevauchent un peu). Ces remarques préalables étant faites, voici le résultat.

Frange blanche

Frange rouge

Frange jaune

Frange verte

Frange cyan

Frange bleue

Frange magenta

Prenons le cas de la frange jaune : l’écran est sensé afficher une raie de jaune. Pourtant sur le spectre on observe du vert et du rouge, et un peu de bleu (dû à la luminosité de l’écran, qui a tendance à blanchir les couleurs), mais en tout cas pas de jaune. Ce n’est pas du jaune. c’est seulement une couleur que l’on perçoit comme jaune. Enfonçons bien le clou : un écran ne peut pas afficher de jaune, pas plus qu’il ne peut afficher du cyan, du magenta, ou du blanc (le spectre devrait alors ressembler à celui indiqué plus haut). Cependant si l’on mettait du véritable jaune à côté on ne verrait pas la différence, car faute d’être sensible à cette couleur nos yeux réagissent de la même façon à ces deux couleurs.

Du moins, la majorité des gens ne verraient pas la différence. Car il existe également le contraire du daltonisme : des personnes ne possédant pas trois, mais quatre types de cônes différents (des quadrichromates ; il existerait mêmes des pentachromates), le quatrième étant sensible au jaune justement. Les personnes dans ce cas doivent donc percevoir la différence entre du jaune et un mélange de vert et de rouge aussi nettement que je perçois la différence entre du vert et du rouge. N’en connaissant pas personnellement (et je serais très intéressé par le témoignage de quelqu’un ayant cette expérience), je n’ai pas de témoignage le confirmant, mais j’ai la conviction que pour elles les écrans doivent sembler bien peu fidèles…

Notez d’ailleurs que même pour les personnes ayant une vue classique à trois types de cônes, la synthèse additive ne constitue pas une approximation suffisante. En effet, il existe des couleurs que la plupart des gens savent distinguer et que les écrans sont parfaitement incapables d’afficher. Vous n’êtes pas convaincu ? Vous voulez un exemple ? Essayez d’afficher du orange fluo pour voir.

Alors ma question est : quand aura-t-on des affichages qui ne soient plus basés sur cette astuce médiocre de la synthèse additive, mais qui soient véritablement capables d’émettre n’importe quelles fréquences (notez le pluriel) du spectre visible ? Dans un premier temps, l’amélioration peut passer par l’utilisation d’un plus grand nombre de couleurs primaires (voir ma note ci-après). Mais au delà, on peut imaginer la mise au point d’un matériau dont les caractéristiques chromatiques pourraient être contrôlées par excitation par un courant. On pourrait alors envoyer des signaux correspondant au spectre souhaité et obtenir la couleur correspondante, de la même façon qu’en envoyant à un haut-parleur un signal, on obtient un son ayant pour spectre le spectre de ce signal (avec plus ou moins de fidélité bien sûr).

La publication de ce billet a été pas mal retardée par la démonstration du spectre de l’écran, que je n’avais ni le temps ni l’occasion de réaliser (d’ailleurs un grand merci Boris pour le coup de main lors de la séance photo). Or entre temps j’apprenais par le site Akihabara News que Sharp travaille sur la construction d’un écran LCD avec cinq couleurs primaires. Cela me conforte donc dans la conviction que l’amélioration radicale du spectre des écrans est l’une des évolutions proches de l’imagerie numérique.

Beam

Article « Rouge vert bleu » sur Wikipédia

Cours « La vision des couleurs »

Article « Daltonisme » sur Wikipédia

Un dispositif de test simple pour observer le spectre d'un écran

Cette image qui pique les yeux est l’un des éléments d’une petite expérience liée à un prochain article. Elle va me servir à observer le spectre de la lumière émise par un écran selon la couleur affichée.

Bien que cela ne transparaisse pas tellement dans ce blog, un de mes sujets d’intérêts majeurs est la 3D, et plus généralement l’imagerie numérique. Si je n’ai ni la connaissance ni l’expérience suffisantes pour traiter avec régularité et aplomb du sujet, j’ai néanmoins quelques idées sur son devenir. Aussi je vais tâcher de publier quelques articles sur le thème : « Quel futur en imagerie numérique ». Plusieurs sont déjà en cours, dont certains pratiquement terminés.

L’un d’entre eux, qui devrait être le premier à être publié, concerne le spectre des écrans actuels et leurs lacunes. Afin de soutenir mon propos, j’ai besoin d’un dispositif simple permettant de mettre en évidence le spectre d’un écran. N’étant pas dans un laboratoire d’optique, je ne dispose bien évidemment pas d’un appareil permettant une quelconque mesure. De plus, je préfère une méthode simple, éventuellement grossière mais néanmoins rigoureuse, que n’importe quel lecteur peut reproduire.

Observer le spectre d’une source de lumière ? Un prisme bien sûr, répond-t-on automatiquement. Mais qui possède un prisme ? En avez-vous ne serait-ce que déjà eu un entre les mains ? Moi non, ou peut-être une fois, dans un lointain cours de physique au lycée. Il va donc falloir trouver autre chose de plus commun. Alors que je faisais le tour de ce qui pouvait faire l’affaire, mon attention s’est arrêtée sur… un CD traînant sur mon bureau (sourire bête et bienheureux de celui qui vient de trouver une solution simple et inattendue à son problème). Tout le monde possède au moins un CD. :-) Un rapide test réalisé immédiatement après s’est avéré concluant.

Ça fait un peu solution bricolage, mais après tout les expériences d’Augustin Fresnel (dont j’ai déjà parlé) étaient autrement plus rudimentaires, et lui ont pourtant permis d’obtenir des résultats qui feront trembler la communauté scientifique. Et par « rudiementaires », il faut comprendre qu’il faisait des mesures sur des rayons de lumière éclairant des fils de fer en traversant des gouttes de miel, faute de lentille !

À venir donc, une petite réflexion sur la technologie actuellement utilisée pour les affichages, dès que j’aurai pu tester et photographier le bricolage expérimental dont il est question.

Un peu de temps plus tard…

Un peu plus d’un an s’est écoulé depuis ce billet où à défaut de prendre des résolutions, je faisais une liste non exhaustive des choses qui me tiennent plus ou plus moins fermement à cœur. À l’origine ce blog n’a pas pour but de tenir au courant des dernières nouvelles me concernant (sinon il aurait toutes les chances d’être tenu à jour encore plus rarement), mais je vais tout de même faire un petit point sur l’avancement de cette liste.

Dans le désordre, je vais commencer par la dernière nouvelle en date : le boulot. Quelques recherches, effectuées lorsque le temps et l’énergie laissés par les contraintes de production le permettaient, m’ont permis de me convaincre que malgré les évènements économiques récents, le marché de l’emploi reste très dynamique dans l’informatique. Même dans mon domaine, le développement 3D, pourtant assez limité (qui a encore besoin d’écrire des moteurs 3D ?) je n’ai eu aucune difficulté à trouver des gens ayant des postes à proposer. Peut-être aussi est-ce justement parce que ce domaine est limité qu’il subit moins la crise. J’ai donc présenté à la fin de l’année mes vœux, de partir. Quelle est la suite ? Rien n’est certain mais il se pourrait bien que je fasse de la 3D et de l’IHM sur iPhone.

À propos de 3D justement, à force de mener, pendant le trajet vers et depuis mon travail, des réflexions plus ou moins désordonnées sur la façon d’architecturer un moteur 3D, j’ai fini par prendre des notes, puis à les organiser. Cette évacuation de la frustration de ne pas faire la moindre 3D au travail a abouti à près d’une quinzaine de pages décrivant un moteur en bonne partie. J’ai profité d’une semaine de congés à la fin de l’été pour commencer à concrétiser cela sous forme de code et afficher des cubes. Aujourd’hui, quelques mois plus tard, je n’affiche toujours que des cubes. Rien de bien attrayant visuellement certes, mais le plaisir réside dans la manière de les afficher (ou non d’ailleurs). La satisfaction esthétique attendra. Si la chose avance au point de me sembler digne de plus d’intérêt, j’en parlerai peut-être à nouveau ici. En attendant, ça fait du bien, et je ne cacherai pas cette satisfaction personnelle fait partie des choses qui m’ont donné l’énergie d’aller voir ailleurs si l’herbe n’était pas plus verte.

Pour ce qui est des langues, je me suis finalement décidé à tenter d’approcher, avec une certaine méfiance tout de même, voire des précautions, le coréen. Pour le moment je tente d’en appréhender les sonorités, au travers de séries télévisées. Pourquoi cette langue ? Certainement pas par intérêt professionnel, ni pour un besoin irrépressible de pouvoir communiquer avec 70 millions de personnes (les mauvaises langues corrigeront par 50) de plus. Par simple curiosité, goût du défi peut-être, et intérêt comme partie intégrante d’une culture, découverte petit à petit au travers de son histoire tristement commune avec le Japon. Et comme déjà dit, parce que son système d’écriture est peut-être le meilleur au monde.

Du reste, j’ai bien tenté de jouer plus souvent au go, et même gagné (perdu ?) quelques kyû. Mais faute de régularité, tout cela ne reste guère qu’un niveau débutant. Ah, et ce site a effectivement changé de tête depuis quelques temps déjà, mais le thème n’est certainement pas de ma création.

Mine de rien, je n’ai pas non plus négligé le fait de glander un peu aussi… Petite erreur dans les priorités peut-être. :-)

WordPress et les captcha

Ce blog qui était épargné jusqu’ici a apparemment été récemment découvert par une machine à spam. Un bot s’entête en effet depuis quelques jours à me dire que mon bref article sur les interfaces du futur est génial, que c’est une bonne idée, qu’il devrait essayer, et autres compliments vides de sens, en anglais évidemment. Avec deux ou trois tentatives quotidiennes, ça reste néanmoins limité, sans commune mesure avec les centaines que des blogs plus importants subissent. Mais en grand fainéant cela suffit à me fatiguer au point de chercher une solution.

Celle qui me vient à l’esprit en premier est l’utilisation d’un captcha. Non pas une image d’un texte vu à travers un fond de bouteille de vodka préalablement vidée, mais juste une question absolument triviale, dont l’effet à déjà fait ses preuves à mes yeux. J’avais en effet déjà implémenté une telle fonction sur le forum de l’ancien site de Prologin avec la question « Combien font deux et deux ? », à laquelle il était possible de répondre en chiffres ou en lettres (ainsi que « 42 », à la demande de quelques candidats). Ce bout de code s’était révélé autrement plus efficace que le module Akismet, à l’effet très discutable, puisque l’on n’avait plus jamais eu le moindre problème depuis lors.

Néanmoins, plutôt que d’aller faire rentrer ça à la hache et au marteau comme précédemment, je me suis dit que quelqu’un avait déjà dû le coder sous forme de module, et qu’une petite recherche serait le plus simple. À défaut de m’avoir encore permis de trouver exactement ce que je cherche, elle aura été très instructive.

Tout d’abord il est partout conseillé d’utiliser Akismet, mais ayant constaté son échec sur le forum de Prologin, c’est la première chose que j’ai désactivée en mettant ce blog en ligne. De plus, sur un site plus important, je ne serais pas surpris que le traitement impliqué ait un coût.

Viennent ensuite les captcha à base d’images brouillées. Cette solution me semble poser quatre gros inconvénients.
Exemple de captcha

  • Tout d’abord elle est pénible : ce type de système me gène en tant qu’utilisateur, et j’imagine que c’est le cas de beaucoup d’autres, même sans aller jusqu’à des extrêmes comme ce grand gagnant (j’ai testé aussi, et je vous recommande de le faire, c’est proprement hallucinant : l’inscription au forum de pompiers.fr). La raison en est simple : il s’agit de chiffres et lettres aléatoires, qui n’ont donc aucun sens, et nécessitent de ce fait une certaine concentration.
  • De plus ces images sont souvent difficilement lisibles, comme le résume très démonstrativement cet article.
  • Ensuite la méthode manque d’accessibilité. Accessibilité, ce n’est pas un mot à la mode à sortir quand on n’a plus d’argument contre des technos qui permettent de faire des sites kikoolol avec des trucs qui clignottent. J’ai un ami qui utilise un clavier braille pour aller sur Internet : pour lui, l’accessibilité, c’est ce qui sépare le net auquel il a accès du reste.
  • Enfin, cette solution s’avère finalement peu efficace face aux progrès de la reconnaissance de forme. En janvier une équipe russe publiait en effet avec fracas un article de recherche traitant de reconnaissance de captcha, et annonçait un taux de réussite de 35% sur les images générées à l’époque par le site Yahoo!, ce qui est amplement suffisant pour en ruiner l’effet. D’ailleurs, sans recourir à ces approches techniques, d’autres spammeurs font lire les images par des utilisateurs en les mettant sur des sites à fort trafic, comme par exemple des sites pornographiques.

Au cours de cette recherche, j’ai également vu passer une méthode à base de son. Cette approche me semble être encore pire que la précédente, aussi je ne vais pas m’étendre plus.

Afin de se débarrasser de la gène occasionnée, certains modules tels que WP Captcha-Free ou WP-SpamFree utilisent le Javascript ou les cookies pour automatiser la reconnaissance du type de visiteur. C’est un moindre mal, mais imposer ces fonctions me gène, toujours pour des raisons d’accessibilité.

Enfin on arrive au méthodes textuelles. Les méthodes dites mathématiques (« arithmétiques » corrigeront les plus rigoureux) semblent être les plus populaires, en témoignent les citations fréquentes de Math Comment Spam Protection Plugin par exemple. Les méthodes textuelles on l’avantage de ne plus poser le problème de l’accessibilité, du moins quand elles restent raisonnables. Le lien que j’ai déjà cité donne quelques exemples d’abus qui en plus d’être tristement risibles, sont parfaitement inefficaces. Reconnaître une expression dans un texte et en retourner le résultat est en effet du domaine du trivial, et demander de calculer la deuxième sur deux ne fait que réduire le taux de réussite d’un bot à 50%. Aussi pénible et peu efficace est remarquable.

À mon avis l’efficacité d’un simple texte pour un captcha réside dans l’analyse sémantique qu’elle nécessite. « Quel fruit pousse sur un pommier ? » est une question simple, ne demandant aucune réflexion, mais qui requiert un traitement du langage qui nous met à l’abri pour cinq à dix ans au moins. WP-Gatekeeper fait partie des modules reposant sur cette technique. N’en ayant pas encore trouvé d’autres de ce genre, mon choix n’est cependant pas encore arrêté. Toute suggestion est d’ailleurs bienvenue. :-)

Pour finir, voici un article en anglais où l’auteur semble avoir constaté lui aussi une grande efficacité pour un bout de code écrit rapidement.