Que ce soit pour FUSE ou pour LUFS, vous songez sérieusement ajouter au VFS central de votre système, dans le noyau, un système de fichiers du style WebDAVfs, FTPfs ? Vous tenez à votre vie ou ? :-)
Plus sérieusement : LUFS comme FUSE agissent comme "proxy", c'est à dire qu'ils ajoutent une entrée pour chaque système de fichiers "virtuels" montés par ces systèmes, et qu'ils transmettent les requêtes que le VFS leur transmet au processus en espace utilisateur qui va bien.
Je pense que le problème fondamental qui devrait empêcher tout administrateur Unix censé d'autoriser ses utilisateurs non privilégiés à monter leurs propres volumes (qu'ils soient virtuels ou physiques) est qu'en aucun cas le VFS n'est fait pour être résistant lors de cas problématiques, comme des "backing store" (le FTP distant, le CDROM, ...) défectueux. Et Dieu sait qu'un CDROM défectueux sait faire planter un système, je vous en file un tout petit qui le fait à coup sur un 2.6.10.
FUSE n'est pas particulièrement résistant face à ce genre de problèmes. Il se veut juste un proxy favorisant la communication entre user space et kernel space pour ces cas particuliers. Et quand bien même il serait étudié pour être plus ou moins résistant, le problème fondamental resterait le même : un VFS centralisé n'est pas adapté à des systèmes de fichiers aussi susceptibles de provoquer des erreurs (error-prone, bordel, pas de jolie traduction en tête).
Le Hurd est conçu autour de cette idée que la sécurité passe par le fait de donner plus de pouvoirs aux utilisateurs. Un noyau de type Unix, avec un VFS centralisé, ne pourra pas fournir ces services que le Hurd fournit.
Concernant le reste de la question, à propos des bibliothèques partagées notamment. Sache d'abord que c'est le cas. Le Hurd est un ensemble de serveurs et de bibliothèques. Une grande partie du code des translators est assuré par netfs/diskfs/trivfs, qui se trouve être une bibliothèque. Mais même en dehors de ça, quand on parle de serveurs, on ne précise pas s'ils seront implémentés comme des processus à part ou comme des bibliothèques. C'est un choix d'implémentation qui dépend des caractéristiques du serveur, des nécessités de performances, et d'autres critères : je prends l'exemple du port du Hurd sur L4, où autant il y a bien un serveur "physmem" ou "task" indépendant, autant l'ensemble du système des "capabilities" - qui détermine toute la sécurité de l'IPC - est assuré par une bibliothèque répliquée dans chaque espace d'adressage. Pour remonter plus loin, Mach OS, un OS qui implémentait un serveur monolithique de compatibilité BSD (UX) par dessus un micro-noyau, Mach, greffait à tous ses espaces d'adressage un certains nombres de choses qui facilitaient grandement la vie de UX - et ses performances.
Les préoccupations du Hurd sont : sécurité, flexibilité, performances. Évidemment, le jeu de la conception est d'effectuer un éternel compromis entre ces trois là, tout en respectant nos priorités. Le choix de bibliothèque ou serveur à part tient compte des trois aspects. Il en va de même lorsqu'il s'agit de décider quels serveurs résideront ou non dans le même espace d'adressage. Il a par exemple été suggéré que 'proc' et 'task', bien qu'implémentés séparément, feraient bien de partager le même espace d'adressage : nul besoin de les réécrire, les IPCs sont alors ce qu'on appelle des LIPC (Local IPC), des communications entre threads d'une même "tâche", ce qui dans L4 ne passe jamais en espace noyau, et équivaut à à peine plus qu'un appel de fonction, en terme de temps. Selon l'expérience, les avis, les discussions, ces choix seront faits. En bref et en résumé, Le Hurd n'exige pas que tout soit séparé autant que possible : il le permet.
L'idée que tu évoques est effectivement l'idée des exonoyaux, ou systèmes d'exploitations "vertically structured" (je trouve le second terme beaucoup plus clair et précis) : c'est le cas de Nemesis que je citais dans un précédent commentaire sur cette même dépêche. C'est réellement un concept intéressant, que beaucoup de développeurs du Hurd apprécient. La question évidemment, c'est : comment assurer la sécurité d'un tel système ? Et les réponses à ça ne sont pas encore très claires. Les exonoyaux en sont là où les micro-noyaux en étaient il y a, disons, 20 ans. Je crois que le Hurd s'en inspire notamment avec le système de "capability" ou avec le gestionnaire de mémoire virtuelle que j'évoquais plus bas - chaque tâche dispose de son implémentation mais peut la changer en volonté -, mais essayer de s'aventurer totalement dans ce domaine serait complètement hasardeux, et inconsidéré. Je considère que le Hurd est déjà arrivé trop tôt, par rapport à la maturation des micro-noyaux : ne refaisons pas la même erreur.
[^] # Re: heeeuu
Posté par Manuel Menal . En réponse à la dépêche Hurd : nouvelle version de Debian GNU/Hurd et avancée du port sur L4. Évalué à 10.
Plus sérieusement : LUFS comme FUSE agissent comme "proxy", c'est à dire qu'ils ajoutent une entrée pour chaque système de fichiers "virtuels" montés par ces systèmes, et qu'ils transmettent les requêtes que le VFS leur transmet au processus en espace utilisateur qui va bien.
Je pense que le problème fondamental qui devrait empêcher tout administrateur Unix censé d'autoriser ses utilisateurs non privilégiés à monter leurs propres volumes (qu'ils soient virtuels ou physiques) est qu'en aucun cas le VFS n'est fait pour être résistant lors de cas problématiques, comme des "backing store" (le FTP distant, le CDROM, ...) défectueux. Et Dieu sait qu'un CDROM défectueux sait faire planter un système, je vous en file un tout petit qui le fait à coup sur un 2.6.10.
FUSE n'est pas particulièrement résistant face à ce genre de problèmes. Il se veut juste un proxy favorisant la communication entre user space et kernel space pour ces cas particuliers. Et quand bien même il serait étudié pour être plus ou moins résistant, le problème fondamental resterait le même : un VFS centralisé n'est pas adapté à des systèmes de fichiers aussi susceptibles de provoquer des erreurs (error-prone, bordel, pas de jolie traduction en tête).
Le Hurd est conçu autour de cette idée que la sécurité passe par le fait de donner plus de pouvoirs aux utilisateurs. Un noyau de type Unix, avec un VFS centralisé, ne pourra pas fournir ces services que le Hurd fournit.
Concernant le reste de la question, à propos des bibliothèques partagées notamment. Sache d'abord que c'est le cas. Le Hurd est un ensemble de serveurs et de bibliothèques. Une grande partie du code des translators est assuré par netfs/diskfs/trivfs, qui se trouve être une bibliothèque. Mais même en dehors de ça, quand on parle de serveurs, on ne précise pas s'ils seront implémentés comme des processus à part ou comme des bibliothèques. C'est un choix d'implémentation qui dépend des caractéristiques du serveur, des nécessités de performances, et d'autres critères : je prends l'exemple du port du Hurd sur L4, où autant il y a bien un serveur "physmem" ou "task" indépendant, autant l'ensemble du système des "capabilities" - qui détermine toute la sécurité de l'IPC - est assuré par une bibliothèque répliquée dans chaque espace d'adressage. Pour remonter plus loin, Mach OS, un OS qui implémentait un serveur monolithique de compatibilité BSD (UX) par dessus un micro-noyau, Mach, greffait à tous ses espaces d'adressage un certains nombres de choses qui facilitaient grandement la vie de UX - et ses performances.
Les préoccupations du Hurd sont : sécurité, flexibilité, performances. Évidemment, le jeu de la conception est d'effectuer un éternel compromis entre ces trois là, tout en respectant nos priorités. Le choix de bibliothèque ou serveur à part tient compte des trois aspects. Il en va de même lorsqu'il s'agit de décider quels serveurs résideront ou non dans le même espace d'adressage. Il a par exemple été suggéré que 'proc' et 'task', bien qu'implémentés séparément, feraient bien de partager le même espace d'adressage : nul besoin de les réécrire, les IPCs sont alors ce qu'on appelle des LIPC (Local IPC), des communications entre threads d'une même "tâche", ce qui dans L4 ne passe jamais en espace noyau, et équivaut à à peine plus qu'un appel de fonction, en terme de temps. Selon l'expérience, les avis, les discussions, ces choix seront faits. En bref et en résumé, Le Hurd n'exige pas que tout soit séparé autant que possible : il le permet.
L'idée que tu évoques est effectivement l'idée des exonoyaux, ou systèmes d'exploitations "vertically structured" (je trouve le second terme beaucoup plus clair et précis) : c'est le cas de Nemesis que je citais dans un précédent commentaire sur cette même dépêche. C'est réellement un concept intéressant, que beaucoup de développeurs du Hurd apprécient. La question évidemment, c'est : comment assurer la sécurité d'un tel système ? Et les réponses à ça ne sont pas encore très claires. Les exonoyaux en sont là où les micro-noyaux en étaient il y a, disons, 20 ans. Je crois que le Hurd s'en inspire notamment avec le système de "capability" ou avec le gestionnaire de mémoire virtuelle que j'évoquais plus bas - chaque tâche dispose de son implémentation mais peut la changer en volonté -, mais essayer de s'aventurer totalement dans ce domaine serait complètement hasardeux, et inconsidéré. Je considère que le Hurd est déjà arrivé trop tôt, par rapport à la maturation des micro-noyaux : ne refaisons pas la même erreur.