FailFS rejoint le cycle de développement Linux 7.3 avec fchroot(). Il permet d’abandonner les points de départ habituels du système de fichiers, mais constitue une brique de confinement plutôt qu’un bac à sable complet.
Racine et répertoire courant ont des effets distincts
La demande d’intégration FailFS introduit un système interne qui rejette les opérations l’atteignant avec EOPNOTSUPP. L’espace utilisateur ne peut pas le monter comme un système ordinaire. La valeur spéciale FD_FAILFS_ROOT est reconnue par fchroot() et fchdir().
La documentation actuelle du noyau distingue les deux transitions. Déplacer la racine vers FailFS bloque les chemins absolus, dont les liens symboliques absolus et le chemin de l’interpréteur des exécutables dynamiques. Déplacer le répertoire courant bloque les recherches relatives partant d’AT_FDCWD. Modifier l’un ne modifie pas automatiquement l’autre.
Les recherches utilisant des descripteurs de répertoire conservés fonctionnent encore. Un tel descripteur autorise de nouvelles opérations sur des chemins ; il ne donne pas seulement accès à un fichier déjà ouvert. Le schéma montre ces chemins restants.
L’entrée sans privilège exige plusieurs conditions
Pour entrer via fchroot() sans privilège, la documentation impose no_new_privs, un appelant pas déjà chrooté et un état de système de fichiers non partagé. L’ancien article ne mentionnait que no_new_privs, omettant des conditions susceptibles de faire échouer l’appel.
La restriction sur le chroot existant est instructive : descripteurs de répertoire et parcours des parents peuvent invalider les hypothèses de confinement après un changement de racine. Examinez chaque descripteur conservé et la politique de résolution, pas seulement les chemins absolus. Réseau et autres capacités nécessitent des contrôles distincts.
La documentation précise également que sortir difficilement de FailFS relève de l’implémentation actuelle, pas d’une garantie d’interface définitive. L’entrée n’est donc pas universellement irréversible. Un protocole doit couvrir racine seule, répertoire courant seul, les deux, recherches par descripteur, exécution dynamique et refus d’entrée attendus. Ce sont des cas proposés, pas des tests noyau réalisés par PeopleAreGeek.
Deux anciens pilotes retirés séparément
Le retrait EFS concerne l’ancien format disque SGI IRIX, sans rapport avec Amazon Elastic File System. Le retrait FreeVxFS supprime le lecteur historique du format Veritas.
Si une archive dépend de l’un de ces lecteurs, conservez un environnement de récupération connu et travaillez sur une copie du support. Un noyau privé du pilote n’efface pas les données, mais change les outils permettant de les relire. Vérifiez noyau et configuration de la distribution réelle : l’évolution amont ne s’applique pas immédiatement à tous les Linux installés.
Revue du 8 septembre : annonce vérifiée, affirmations corrigées et illustration explicative originale ajoutée.