FAQ

Cet article est relatif au système d'exploitation Manux, version 0.0.5. Nous supposerons que le lecteur est habitué à l'utilisation en ligne de commande d'un autre Unice.

Installation

L'installation échoue sur mon ordinateur, que faire?

Distinguons les principaux cas :

L'installation échoue lors de l'initialisation d'un module noyau

Ah, ça, c'est pas bon. Si le module en question est "ide", c'est qu'il n'est pas parvenu à contacter votre disque dur. Dans ce cas, vous pouvez essayer de trouver ses ports grâce à Linux, puis de forcer leur valeur dans noyau/démarrer_ide.c. (Vous êtes un hacker noyau, non?) Sinon, ma foi, tentez de débogger le problème, ou signalez-le moi. (Même si je crains ne pas pouvoir faire grand-chose, si je ne peux pas reproduire le problème.)

L'installation échoue avec une panique du noyau

Oups.... Ça, c'est très mal. Et je sais que c'est possible, parce qu'il reste des bogues dans le noyau que je ne suis pas parvenu à reproduire (ils surviennent très rarement, sauf durant l'installation). Signalez-le-moi et réessayez, et si c'est reproductible, tentez d'identifier le problème... Désolé.

L'installation se bloque lors de l'installation d'un paquetage

Non, elle ne se bloque pas :-) . L'installation de certains paquetages est très longue et prend plusieurs minutes - attendez simplement. (D'un autre côté, si elle se bloque vraiment, alors vous avez rencontré un bogue noyau... Et je n'ai jamais subi quoi que ce soit de ce genre, donc si cela vous arrive, je soupçonne que ce soit lié au matériel. Tentez de ralentir les entrées-sorties du module "ide", et voyez si cela améliore la situation.)

L'installation s'achève avec un message d'échec

Quoi? Elle ne devrait pas. Signalez-moi où cela se produit, et voyez si c'est reproductible ou non.

L'installeur affiche des caractères bizarres (des coeurs et des visages) durant l'installation

C'est parfaitement normal, ignorez-le.

(Ah, vous voulez savoir pourquoi cela se produit? L'installeur est un processus Manux standard, donc il est chrooté. Mais il n'y a pas de /packages dans son chroot, parce que la portion Linux de l'installeur ne peut pas créer de lien matériel vers un répertoire, et que sa portion initiale en C n'effectue que le strict minimum avant d'exécuter le script d'installation. Donc /packages lui est passé sous la forme d'un paramètre de sa ligne de commande. Mais /packages n'est pas dans /... , donc les algorithmes anti-collision ont dû lui donner un nouveau nom dans /... , et ils en ont choisi un composé de deux caractères non écrivables. Ensuite, pour des raisons de mise au point, ce script affiche ses actions, qui incluent la manipulation de fichiers et le lancement de programmes situés dans /packages. De la sorte, les deux caractères non écrivables sont émis, et dans la mesure où mon implémentation de la console noyau n'a pas d'objection à écrire des caractères qui ne devraient pas pouvoir l'être, ces caractères bizarres apparaissent à l'écran.)

Après qu'init soit lancé, il y a un échec...

Il faut de bons yeux pour repérer cela, mais c'est vrai. Juste après l'installation, en entrant dans le niveau d'exécution 2, le dernier script d'init échoue. C'est parce que l'installeur a eu besoin de faire son travail auparavant, donc le système de fichiers qu'il tente de monter l'est déjà. C'est complètement inoffensif, ignorez-le.

Manux peut-il être installé dans une machine virtuelle?

Certainement, mais je n'ai jamais essayé.

Utilisation

Quel est mon mot de passe initial?

Laissez-moi deviner... Vous lisez cela sans l'avoir essayé, n'est-ce pas?

Comment peut-on passer root?

Manux n'a pas de notion d'utilisateur "root". Les privileges, actuellement non implémentés, pourront être donnés à n'importe quel utilisateur.

Cependant, sous Manux, le principe de base est que le droit d'accès implique le droit d'utilisation - c'est-à-dire que si vous pouvez accéder à une ressource, vous devriez pouvoir l'utiliser (pas forcément en écriture, mais c'est un autre problème).

A titre d'exemple, sous Manux, /etc/shadow est en mode 666. Cela peut sembler la chose la plus diabolique jamais réalisée dans le monde des démons UNIX, mais aucun utilisateur non privilégié n'a d'accès direct à ce fichier. Au lieu de cela, ils peuvent simplement le modifier par l'intermédiaire du programme "passwd", ce qui ne pose pas de problème. Et dans la mesure où la possibilité de lancer un programme n'implique pas l'accès à son chroot, ils ne peuvent pas s'en servir pour y faire des modifications arbitraires.

Au passage, ceci explique aussi pourquoi les bits SUID et SGID des exécutables sont ignorés : avec cette architecture, ils sont complètement inutiles.

Qu'en est-il de l'utilisateur "sys"?

L'UID 0 correspond à l'utilisateur "sys", et le GID 0 au groupe "sys". Ces identifiants correspondent au système d'exploitation, et ne doivent pas utilisés par qui que ce soit d'autre. Additionnellement, l'utilité de ces identifiants a été délibérément réduite : ils ne peuvent exécuter aucun programme ayant un cache dépendant de l'utilisateur ou des fichiers de configuration spécifiques à un utilisateur (comme vim ou less).

J'ai fait cela pour deux raisons. Premièrement, aucun programme du système d'exploitation ne devrait avoir un comportement influençable par des données spécifiques à un utilisateur; deuxièmenent, cela évite que des utilisateurs tentent d'utiliser l'UID 0 malgré tout, dans la mesure où sa réactivation complète requiert d'importantes modifications au système d'exploitation. Manux n'est pas un UNIX véritable, et ne peut pas être utilisé de la même façon - même s'il se trouve être en compatibilité binaire native avec Linux.

Une fois logué, comment dois-je procéder pour monter mon répertoire personnel Linux?

Supposons qu'il soit sur la partition que Linux nomme /dev/sda6. Tout d'abord, faites un point de montage

$ mkdir mnt5

Puis créez un fichier de périphérique en mode bloc représentant votre partition :

$ mknod hd0,5 b 0 0

Théoriquement, ici, vous devriez associer ce fichier au module gérant le périphérique, mais ce n'est pas encore programmé pour les partitions du disque dur, donc un bricolage du noyau les identifie à partir de leur nom - vous n'avez donc rien à faire. Passez ensuite administrateur:

$ admin

Montez cette partition :

# smount -t ext2 hd0,5 mnt5

Et quittez le mode administrateur :

# unadmin

Et si notre répertoire personnel n'est pas formatté en ext2?

Actuellement, Manux ne peut monter que des partitions ext2... Mais il se trouve qu'ext3 n'est autre qu'ext2j, une variante journalisée d'ext2. Vous pouvez sans danger la monter comme de l'ext2.

Les autres partitions, en revanche, demeureront immontables.

Qu'est-ce que c'est, ces commandes "admin" et "unadmin"?

De simples fonctions de l'interpréteur de commande (bash), conçues pour éviter les fautes de frappes. Elles se contentent d'ajouter /sbin et /usr/sbin à votre PATH et de changer votre invite de commande. En particulier, elles n'altèrent pas vos privilèges. Vous pouvez les modifier comme vous le souhaitez.

Qu'est-ce que c'est que "smount"?

"smount" est une variante de mount qui ne vérifie pas l'UID de son appelant. Oui, c'est sans danger - sous Manux du moins. Parce que si vous pouvez accéder à un fichier spécial représentant un disque dur en lecture-écriture, vous pouvez le monter.

Comment démonte-t-on une partition?

Euh... Désolé, ce n'est pas encore programmé.

Comment recompile-t-on le noyau Manux sous lui-même?

Il faut utiliser "./make" au lieu de "make". En effet, make étant chrooté, il n'a pas accès aux programmes requis pour le compiler (ou compiler quoi que ce soit d'autre); il faut donc les injecter dans son arborescence.

Vous voulez voir comment "./make" procède? Tapez "cat ./make" :-) .

Pourquoi "man" n'est-il pas porté?

Un problème technique. Tant que /dev/env/HOME n'existera pas, il sera impossible de faire dépendre le MANPATH de l'utilisateur. Or c'est indispensable, parce que nous ne pouvons pas donner accès à des pages arbitraires aux utilisateurs : cela constituerait une fuite d'information (les informant qu'un certain logiciel ou une certaine version à laquelle il ou elle n'a pas accès sont bel et bien installés).

Comment patche-t-on le noyau dynamiquement?

# patch_kernel <module>

Le script scripts/maj_noyau l'illustre bien (il met à jour le noyau à l'aide du code qui vient d'être compilé. Rassurez-vous, il n'est pas lancé automatiquement).

Si vous voulez vous amuser avec cela, essayez d'injecter l'éphémodule "hw" (éphémodules/divers/hw.c), puis d'utiliser "test_sys".

Comment arrête-t-on le système?

$ admin
# init 0 ; exit

Variante:

$ admin
# exec init 0

Comment peut-on utiliser un clavier non français?

Si vous utilisez un clavier allemand ou anglo-saxon standard, il y a déjà une carte du noyau prévue. À l'installation, sous Linux, précisez simplement --lang [de|en], et la carte requise sera chargée au démarrage.

Pour les autres, ou bien si vous repérez que j'ai fait une erreur dans l'une des cartes précédentes, je crains qu'il ne vous faille modifier ou reprogrammer votre carte du clavier vous-même. Les cartes des claviers sont situés dans le répertoire include/a0/kbd_maps du code source du noyau, et les éphémodules qui les chargent sont les fichiers ephemodules/misc/kbd_* . Une fois que vous avez créé une carte du clavier et compilé un nouvel éphémodule kbd_XX pour la charger, faites simplement un patch_kernel kbd_XX, et le clavier sera reconfiguré.

Quel est le risque de perte de données?

Bonne question. Distinguons trois cas de figure :

Le premier type de perte de données se produit, rarement, mais il se produit. Il peut être dû à des problèmes avec le pilote de disque dur, ide (ce problème a complètement disparu sur mes ordinateurs, mais évidemment, cela ne signifie rien quant au vôtres), ou à une panique du noyau survenant avant de sauvegarder un texte venant d'être tapé (ça, c'est devenu rarissime, et de toutes façons, ce n'est pas bien grave).

Le second type de perte de données m'est arrivé... Une fois, il y a des années, lorsque je déboguais le module ext2. Apparemment, j'ai perdu quelques fichiers dans ma distributions Linux, mais ils ne devaient pas être trop importants puisque je n'ai jamais trouvé quelle portion avait été endommagée. Depuis, non, je n'ai jamais rencontré de perte de données du second type.

Quant au troisième, ma foi, que dire... Prenez garde à rm -rf, cette commande est efficace sur les deux systèmes.

Cela dit, le fait que moi, je n'aie jamais rencontré de problèmes dans ce domaine ne garantit pas que vous, vous n'en rencontrerez pas. Et, dans la mesure où sauvegarder ses données est de toutes façon une bonne idée, si vous comptez l'utiliser sur une machine réelle, vous devriez penser à faire une sauvegarde (ou à utiliser une machine séparée si vous en avez une).

Divers

Pourquoi ne peut-on utiliser qu'un seul format de paquetages?

En fait, le système de paquetages est vraiment intégré à l'architecture du système. Par exemple, c'est à l'aide des dépendances des programmes que leurs chroots sont construits, en établissant des liens matériels vers les bons fichiers et répertoires dans leur racine. Par conséquent, aucun autre format de paquetage ne peut le remplacer.

Pourquoi rejeter toutes les interfaces graphiques existantes?

A nouveau pour des raisons techniques (bien que l'uniformité de la plateforme soit aussi une motivation). Si on ne place pas le serveur graphique en espace noyau, il devient impossible d'exprimer des contraintes du genre "l'application A a le droit de faire une copie d'écran, mais pas l'application B, et quant à C, elle en a le droit, mais lorsqu'elle en fait une, elle doit être falsifiée de telle sorte qu'elle se croie la seule application active".

De plus, les serveurs graphiques ont besoin d'interagir avec le matériel de façon bien trop importante pour qu'on les place en espace utilisateur.

Cependant, ces considérations n'excluent pas que ce serveur graphique soit rendu partiellement ou totalement compatible avec un autre, qu'il s'agisse d'X11, de Wayland, de Mir, ou autre. Sur ce point, je n'ai pas assez étudié leurs interfaces pour pouvoir me prononcer.

Manux est-il un système d'exploitation à capabilités?

Effectivement. Mais je ne l'ai remarqué qu'en lisant des documents à leur sujet, donc ce n'était pas le but. C'est aussi la raison pour laquelle il est si différent des autres systèmes d'exploitations à capabilités : il a plusieurs types de capabilités, et n'est pas strictement persistent. De plus, il ne vérifie pas certaines propriétés habituelles des systèmes d'exploitation à capabilités, parce que la détention d'une capabilité d'implique pas le droit d'en faire une copie. En effet, les capabilités ne sont pas évaluées in abstracto, mais en fonction de leur utilisateur.

Je croyais que les systèmes d'exploitation à capabilités ne pouvaient pas gérer de fichiers...

C'est une autre de ses particularités. Si on voulait le décrire en terme de capabilités, Manux considère les fichiers comme des ressources, les noms de fichiers comme des capabilités, les répertoires comme des ensembles de capabilités, et les arborescences de chroot comme l'ensemble des capabilités d'un programme.

Toutefois, certaines choses ne peuvent pas être gérées à l'aide de capabilités, comme le droit d'utiliser link(2), qui permettrait de copier les capabilités passées, ou le droit d'ignorer les UIDs/GIDs. Ces éléments seront implémentés à l'aide de capabilités de style UNIX, qui ne sont pas des vraies capabilités mais des privilèges.

Qu'en est-il de la documentation?

Ma foi, pour l'instant, il n'y en a pas beaucoup, parce que je n'en avais jamais besoin. Je compte y remédier, mais il y a tant de choses à faire...

Soit dit en passant, je considère que la documentation fait partie intégrante du logiciel, donc si vous souhaitez ne contribuer qu'en termes de documentation, je n'y ai aucune objection. Simplement, si vous rédigez un document complet, merci de mentionner explicitement que vous acceptez son inclusion dans mon logiciel et sa distribution sous la Licence Manux.

Autre remarque, j'ai lu quelque part que la documentation était la méthode recommendée pour permettre aux femmes de s'investir dans les projets libres. Je dois dire que je n'aime pas trop cela : les capacités de programmation des femmes ne sont pas intrinsèquement inférieures à celles des hommes, mais dans la mesure où la pratique est la meilleure façon de progresser dans ce domaine, une telle approche entraînera une infériorité de facto, ainsi qu'une exclusion du domaine intéressant réellement certaines d'entre elles. Par conséquent, mesdames et mesdemoiselles, si vous le souhaitez, faites de la documentation, mais si vous préferez la programmation, lancez gcc!

Pourquoi se focaliser sur les exploits jour zéro?

Qui peut le plus peut le moins. Si l'on peut encaisser un exploit jour zéro, alors on peut aussi encaisser un exploit publié ou gérer un logiciel agressif. Et, en tant que gagnant de l'édition 2007 du concours de programmation sournoise en C, je peux vous garantir que ce ne sont pas les relectures du code source qui peuvent protéger contre cela.

A part pour apprendre, pourquoi avoir créé ce logiciel?

Ma foi, soyons honnête : j'estime qu'en matière de sécurité, la situation de l'informatique actuelle est catastrophique. Le moindre problème dans le plus petit logiciel peut donner accès à l'ensemble des données d'une personne! Et tout le monde semble trouver cela normal, comme s'il n'y avait rien à faire.

En plus, le désordre dans l'organisation de l'espace utilisateur est frappant : un attaquant peut cacher un fichier n'importe où, il y a des fichiers hors paquetages un peu partout. Allez donc déterminer ce qui provient de quoi!

Et les problèmes de compatibilité entre logiciels et entre bibliothèques sont agaçants, et les incompatibilités entre distributions une très mauvaise chose pour le monde du libre.

Lorsque je m'y suis mis, je pensais que, puisque personne ne l'avait jamais fait, cela devait être impossible, et que lorsque je m'y essayerais, je découvrirais pourquoi. Et bien, rien du tout, ça marche très bien!

Lorsque j'ai réalisé cela, j'ai résolu de le finir, et de le rendre opérationnel. On verra bien s'il a du succès ou pas, mais dans tous les cas, je considère qu'il constitue une avancée suffisamment importante en matière d'architecture des systèmes d'exploitation pour justifier les efforts que je lui ai consacrés.

Index de la documentation
Page principale