Pour un truc hyper sécurisé, des fois, ça me laisse songeur... Regardez le code par ici de init. BSD n'est pas SystemV, donc ça ne marche pas comme un Linux de base : il ne fait que lancer le script /etc/rc (codé en dur) ; il n'y a pas d'inittab. De fait, la présence de login via getty est déduite en fonction du fichier /etc/ttys, qui par défaut en met un sur tty00, la première console (on remarquera que getty est dans /usr/libexec, encore une des plaisanteries pas drôle de cet OS mal fichu ; à remarquer que c'est pareil sur MacOS, d'après ce que j'ai vu).

Sauf que si l'on regarde dans le code, la lecture de ce fichier se fait via la fonction "read_ttys()", qui elle-même appelle "start_session_db()" ; si cela échoue, c'est "single_user()" qui est appelé (par pointeur de fonction), sinon plus bas, c'est "multi_user()" (idem). multi_user, c'est le truc standard, avec un login/mot de passe demandé pour se logguer. Tout ceci se passe évidemment après avoir lu et entièrement exécuté le fichier /etc/rc (fonction "runcom()" ; à remarquer que c'est le même script qui est exécuté lorsque l'on arrête ou que l'on reboote la machine, pratique non ? Heureusement, un argument "shutdown" est passé dans ce cas, fonction "nice_death()"), tout ce qui doit être démarré pour avoir un système viable (un serveur apache, par exemple) est donc démarré. Notamment, on a depuis longtemps dépassé la fonction "main()" qui avec son while sur getopt en tête, vérifie que l'on n'a pas explicitement demandé un single mode dans le sens unixien/linuxien du terme, c'est-à-dire le fameux démarrage en mode dégradé directement sur shell (remarquons d'ailleurs que de plus en plus de distribution Linux semblent désactiver cette fonction du kernel par défaut : sinon avec un accès physique à un portable, il suffit d'éditer la ligne de conf avant démarrage, sous grub, et ajouter "single" à la liste des arguments, avant de changer le mot de passe root et redémarrer, par exemple) ; sous bsd, ça s'appelle en mettant un argument "-s" au noyau (stocké usuellement dans /bsd, soit à la racine, tout est simpliste dans ce monde).

Résumons : le single user est comme sous Linux, et tout aussi dangereux ; il n'est pas désactivable, sauf à compiler le kernel sans support de la ligne de commande (la gestion de la compilation de bsd est d'ailleurs des plus folkloriques ; à noter que la notion de modules n'est pas encore au goût du jour, et que désactiver le support d'une carte pcmcia dont on n'a que faire peut avoir des conséquences fâcheuses inattendues -- j'ai fini par la remettre, j'étais prévenu -- ah, si vous trouvez la faq austère, sachez qu'elle est en réalité fort complexe, si si, et que c'est pour ça qu'elle n'est pas aux standards w3c). C'est-à-dire que s'il est déclenché, on se loggue sans mot de passe en root, et l'on peut faire la fête sur le système. Parlons donc de cette fonction "start_session_db()"...

Il semble que bien des choses reposent sur db, la base de donnée antédiluvienne, notamment la gestion des mots de passe (pas de shadow mais un pwd.db). Et apparemment pour la gestion des ttys aussi. Or, db a besoin de son répertoire /var/db. Que se passe-t-il si le disque est plein, ou si /var est read-only ou du moins non inscriptible, par exemple parce que le file system de sa partoche (enfin, slice, je passe sur les détails...), est corrompu et automatiquement monté en ro ? (ce qui peut avoir des conséquences tragi-comiques : ayant un fichier sur lequel j'ai créé par virtual node -- le loopback du pauvre sur bsd -- un système bsd complet, et notamment une partition primaire bootable, le fait de vouloir la monter alors qu'un qemu fermé un peu trop vite m'avait un peu pourri le file system -- qui n'est pas journalisé, sous bsd --, a fait détecter au système que je voulais remonter une partition système avec bootloader et certainement noyau alors que celle-ci n'était pas nettoyé : refus catégorique et affichage de warning sur toutes les consoles ! Ou comment une mesure de sécurité légèrement pensé mène à du grand n'importe quoi) Ou encore que /var ou /var/db n'existe plus ? (imaginons qu'une coupure de courant fasse rebooter violement la machine, et que certains dossiers soient perdus ou fichier de création dynamique de répertoires corrompu)

Eh bien tout simplement, la fonction échoue, et on se retrouve, alors que login et getty peuvent se lancer tout à fait correctement, avec le prompt "Enter pathname of shell or RETURN for sh: ", ce qui en appuyant sur Entrée donne directement sur un shell root, sans passer par l'étape habituelle de la demande de mot de passe.

"Ah bein bravo", comme on dit...

(en l'occurrence, cette enquête a été mené parce que /var était par erreur un répertoire sur un file system / RO par mesure de sécurité, au lieu d'être un lien vers /tmp/var, lui-même monté en RAMdisk, ou "mfs" sous bsd -- d'ailleurs le "mount_mfs" reste un processus lancé, c'est-à-dire en toute rigueur une gestion en userland via allez-retour kernel/processus pour de la mémoire que l'on veut la plus rapide possible -- contrairement à un FUSE linux qui de toute façon a toujours été un gros hack, bien inférieur à ce que ferait un hurd --, et en plus non déboulonnable ensuite, du moins un kill -9 n'y fait rien... Magnifique design, pour la peine)