Si, il l'est. D'abord, des crashes, ça arrive pour toutes les applications. Si par exemple il s'agit du serveur de fichiers servant pour une partition non-essentielle, comme /com, ou que sais-je, je pense qu'un administrateur système va préférer avoir un "down time" de /com qu'un down time général du serveur. Ne penses-tu pas ?
Ensuite, je te rappelle que ce ne sont pas que des parties essentielles qui se trouvent dans le noyau. Par exemple, le montage NFS du pauvre petit utilisateur à qui on a permis de se monter une partoche via NFS (déjà qu'il a fallu qu'il demande à root, parce qu'évidemment seul root peut faire ça, et à raison en ce qui concerne les systèmes à noyau monolithique[1]) doit-il permettre de faire tomber l'ensemble du système ? Je ne le pense *vraiment* pas.
Même chose pour un serveur essentiel pour fournir les tâches imparties à la box, mais pas essentiel au système, comme par exemple, la pile TCP/IP. Je sais pas pour vous, mais j'en ai quand même vu crasher après un slashdottage. D'ailleurs, c'est bien la pile TCP/IP de Linux 2.2.14, qui est la base de pfinet actuellement (en cours de redesign) qui avait crashé plusieurs fois lors d'un /.age d'un serveur web sous GNU/Hurd (et c'était, on l'a découvert ensuite, bien lié à un bug de cette pile, qui a été rapporté par la suite). La différence étant que sur un système basé sur un noyau monolithique, ça veut dire plantage général et redémarrage (donc downtime assez important), alors que sous GNU/Hurd, ça veut dire pile TCP/IP qui crashe et qui est redémarrée automatiquement dans la seconde qui suit. (donc, des conséquences mais bien moins importantes)
Pour prendre l'analogie avec la sécurité, le Hurd ne prétend pas résoudre les problèmes de sécurité. Il prétend fournir des mécanismes de sécurité qui permettent aux développeurs de minimiser les conséquences de tels problèmes[2]. De même, il ne prétend pas résoudre tous les problèmes de stabilité. Mais, partant du principe qu'a priori, un programme a toujours des bugs potentiels, surtout lorsqu'il s'agit de programmes relativement complexes comme ceux s'occupent d'un système de fichier, il prétend minimiser les conséquences de tels plantages.
Enfin, pour avoir suivi le développement de Linux depuis assez longtemps, et avoir eu moi-même quelques expériences avec, je sais que les bugs sont loin d'être tout le temps dans la partie où ils apparaissent. S'il est vrai qu'il a été nécessaire de « cloisonner » Linux, comme le disait JJB (encore un pote à JJB!), créer un énorme logiciel qui contient des tas de parties différentes amène naturellement plus de risques de se planter, en ne connaissant pas bien ce que fait telle autre partie, en se gourrant sur un lock, ou que sais-je. De plus, une inversion de paramètres est vite arrivé, et si les changement dans les interfaces externes de Linux sont déjà fréquents, les changements dans les interfaces internes sont plus que monnaie courante, causant donc de nouveaux problèmes potentiels. Comme le disait JJB, si Linux tient, c'est par le plus grand des miracles, et quelques fois ça fait quand même badaboom. Entendez-moi bien, je ne critique pas non plus les « irresponsables » développeurs de Linux, etc. : une grande partie du miracle grâce auxquels ces sources tiennent s'appelle Alan Cox, Linus Torvalds, Rik Van Riel, Harald Welte, et autres personnes extrêmement douées du genre. Mais je persiste à croire que si ces ressources étaient mises à disposition d'un projet ne posant pas ces problèmes de bases, elles seraient mieux utilisées. (NB: et Harald est pas très loin de penser la même chose :-)
Au fait, de façon évidente, si ces « processus » (processi? processus? (4ème F/M) processa? (3ème neutre) (latin roxor (lisp aussi))) sont appelés serveurs, c'est par analogie avec le fameux modèle client-serveur (qui a dit buzzword?). Je tiens également à revenir sur la composition d'un noyau monolithique. En tant que fourre-tout officiel de tout ce qui n'est pas « bibliothéquisifiable » (j'adore ce mot. pas vous? ah bon[3]), il n'est pas évident de définir ce qu'il contient dans un système « Unix » (non, nous ne reprendrons pas le troll, j'ai déjà donné mon point de vue). Mais il ne contient certainement pas que des parties essentielles au système: il contiendrait plutôt tout ce qui doit être commun à toutes les applications et peut poser un quelconque de sécurité, ou que sais-je. Plus récemment, la manie a été d'intégrer dans le noyau tout ce qui peut se rapprocher du « bas-niveau » (PPPoE, etc.). Il est donc loin d'autant moins évident de garantir la stabilité de ces parties non-essentielles, et il me semble dément qu'ils puissent faire tomber l'ensemble du système. Enfin, vous me direz, ça ne s'applique pas forcément aux serveurs de production. Mais je crois que la stabilité n'intéresse pas que ces premiers.
[1]: mon expérience de ce genre d'explications m'a montré que ce point là était en général un des moins bien compris, et que la question « Et pourquoi on pourrait pas monter des trucs en user sur mon Unix? Moi je peux avec users dans le fstab ! ». Répondons directement. Oui, on le peut: via le setuid root. Je pense que rien que l'invocation de cette fonctionnalité devrait faire frémir tous ceux qui se sont un jour préoccupé de sécurité. :-)
Sous Unix, si on autorise tous les utilisateurs à effectuer l'appel système `mount', rien ne les empêche de créer une image d'un système de fichiers reconnu par le noyau contenant des programmes « setuid root » (justement!) qui seraient alors intégrés tels quels dans le VFS, sans distinction d'utilisateur avec les autres partitions (il n'y a pas ce genre de notions avec Unix), permettant ainsi à n'importe quel utilisateur de devenir root. Sous GNU/Hurd en revanche, le « serveur » s'occupant du système de fichier (on parle de « traducteur » ou « translator » pour le Hurd, en raison de ses spécificités) est une application _comme_ _les_ _autres_, qui tourne en mode utilisateur avec les droits de l'utilisateur qui l'a lancé. Il ne peut donc *rien* faire de plus que cet utilisateur. Tiré d'un document écrit par Marc, Kilobug et moi-même:
(jvous jure, l'idée de pinger hurdfr.org était de KB :-p)
Même si c'est franchement hors-sujet, j'espère que cela aura su répondre aux interrogations de certains. (et puis même si vous vous posiez pas la question, vous savez maintenant! :-)
[2]: Je tiens à citer Wolfgang Jährling, qui commençait son (excellente) conférence sur les mécanismes d'authentification du Hurd, dont un court résumé est disponible sur http://www.gnu.org/software/hurd/auth.html(...) , par un retentissant « security is just a bad hack ». En effet, n'oublions pas que la vraie réponse à la sécurité est de rendre les gens bons, de telle façon que tout le monde reporte les problèmes de sécurité sans jamais les utiliser à des fins malhonnêtes - et que personne n'ait même de buts qui ne soient pas louables! Mais malheureusement, cette tâche est quelque peu difficile à accomplir en écrivant des logiciels. Nous sommes donc condamnés à se limiter à ce bad hack qu'est la « sécurité » :-)
[3]: j'espère que les amateurs auront reconnu une fine allusion à Renaud, et pourront donc me dire de quelle chanson je parle :-p
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par Manuel Menal . En réponse à la dépêche Bitkeeper, RMS et PLONK.. Évalué à 1.
Ensuite, je te rappelle que ce ne sont pas que des parties essentielles qui se trouvent dans le noyau. Par exemple, le montage NFS du pauvre petit utilisateur à qui on a permis de se monter une partoche via NFS (déjà qu'il a fallu qu'il demande à root, parce qu'évidemment seul root peut faire ça, et à raison en ce qui concerne les systèmes à noyau monolithique[1]) doit-il permettre de faire tomber l'ensemble du système ? Je ne le pense *vraiment* pas.
Même chose pour un serveur essentiel pour fournir les tâches imparties à la box, mais pas essentiel au système, comme par exemple, la pile TCP/IP. Je sais pas pour vous, mais j'en ai quand même vu crasher après un slashdottage. D'ailleurs, c'est bien la pile TCP/IP de Linux 2.2.14, qui est la base de pfinet actuellement (en cours de redesign) qui avait crashé plusieurs fois lors d'un /.age d'un serveur web sous GNU/Hurd (et c'était, on l'a découvert ensuite, bien lié à un bug de cette pile, qui a été rapporté par la suite). La différence étant que sur un système basé sur un noyau monolithique, ça veut dire plantage général et redémarrage (donc downtime assez important), alors que sous GNU/Hurd, ça veut dire pile TCP/IP qui crashe et qui est redémarrée automatiquement dans la seconde qui suit. (donc, des conséquences mais bien moins importantes)
Pour prendre l'analogie avec la sécurité, le Hurd ne prétend pas résoudre les problèmes de sécurité. Il prétend fournir des mécanismes de sécurité qui permettent aux développeurs de minimiser les conséquences de tels problèmes[2]. De même, il ne prétend pas résoudre tous les problèmes de stabilité. Mais, partant du principe qu'a priori, un programme a toujours des bugs potentiels, surtout lorsqu'il s'agit de programmes relativement complexes comme ceux s'occupent d'un système de fichier, il prétend minimiser les conséquences de tels plantages.
Enfin, pour avoir suivi le développement de Linux depuis assez longtemps, et avoir eu moi-même quelques expériences avec, je sais que les bugs sont loin d'être tout le temps dans la partie où ils apparaissent. S'il est vrai qu'il a été nécessaire de « cloisonner » Linux, comme le disait JJB (encore un pote à JJB!), créer un énorme logiciel qui contient des tas de parties différentes amène naturellement plus de risques de se planter, en ne connaissant pas bien ce que fait telle autre partie, en se gourrant sur un lock, ou que sais-je. De plus, une inversion de paramètres est vite arrivé, et si les changement dans les interfaces externes de Linux sont déjà fréquents, les changements dans les interfaces internes sont plus que monnaie courante, causant donc de nouveaux problèmes potentiels. Comme le disait JJB, si Linux tient, c'est par le plus grand des miracles, et quelques fois ça fait quand même badaboom. Entendez-moi bien, je ne critique pas non plus les « irresponsables » développeurs de Linux, etc. : une grande partie du miracle grâce auxquels ces sources tiennent s'appelle Alan Cox, Linus Torvalds, Rik Van Riel, Harald Welte, et autres personnes extrêmement douées du genre. Mais je persiste à croire que si ces ressources étaient mises à disposition d'un projet ne posant pas ces problèmes de bases, elles seraient mieux utilisées. (NB: et Harald est pas très loin de penser la même chose :-)
Au fait, de façon évidente, si ces « processus » (processi? processus? (4ème F/M) processa? (3ème neutre) (latin roxor (lisp aussi))) sont appelés serveurs, c'est par analogie avec le fameux modèle client-serveur (qui a dit buzzword?). Je tiens également à revenir sur la composition d'un noyau monolithique. En tant que fourre-tout officiel de tout ce qui n'est pas « bibliothéquisifiable » (j'adore ce mot. pas vous? ah bon[3]), il n'est pas évident de définir ce qu'il contient dans un système « Unix » (non, nous ne reprendrons pas le troll, j'ai déjà donné mon point de vue). Mais il ne contient certainement pas que des parties essentielles au système: il contiendrait plutôt tout ce qui doit être commun à toutes les applications et peut poser un quelconque de sécurité, ou que sais-je. Plus récemment, la manie a été d'intégrer dans le noyau tout ce qui peut se rapprocher du « bas-niveau » (PPPoE, etc.). Il est donc loin d'autant moins évident de garantir la stabilité de ces parties non-essentielles, et il me semble dément qu'ils puissent faire tomber l'ensemble du système. Enfin, vous me direz, ça ne s'applique pas forcément aux serveurs de production. Mais je crois que la stabilité n'intéresse pas que ces premiers.
[1]: mon expérience de ce genre d'explications m'a montré que ce point là était en général un des moins bien compris, et que la question « Et pourquoi on pourrait pas monter des trucs en user sur mon Unix? Moi je peux avec users dans le fstab ! ». Répondons directement. Oui, on le peut: via le setuid root. Je pense que rien que l'invocation de cette fonctionnalité devrait faire frémir tous ceux qui se sont un jour préoccupé de sécurité. :-)
Sous Unix, si on autorise tous les utilisateurs à effectuer l'appel système `mount', rien ne les empêche de créer une image d'un système de fichiers reconnu par le noyau contenant des programmes « setuid root » (justement!) qui seraient alors intégrés tels quels dans le VFS, sans distinction d'utilisateur avec les autres partitions (il n'y a pas ce genre de notions avec Unix), permettant ainsi à n'importe quel utilisateur de devenir root. Sous GNU/Hurd en revanche, le « serveur » s'occupant du système de fichier (on parle de « traducteur » ou « translator » pour le Hurd, en raison de ses spécificités) est une application _comme_ _les_ _autres_, qui tourne en mode utilisateur avec les droits de l'utilisateur qui l'a lancé. Il ne peut donc *rien* faire de plus que cet utilisateur. Tiré d'un document écrit par Marc, Kilobug et moi-même:
(mmenal@drizzt, 25) ~ $ sudo chown mmenal /dev/hd0s3
(mmenal@drizzt, 26) ~ $ settrans -cgap foo /hurd/ext2fs -r /dev/hd0s3
(mmenal@drizzt, 27) ~ $ cd foo/bin
(mmenal@drizzt, 28) ~/foo/bin $ ls -l ping
-rwsr-xr-x 1 root root 15368 May 23 18:27 ping
(mmenal@drizzt, 29) ~/foo/bin $ ./ping hurdfr.org
bash: ./ping: Operation not permitted
(jvous jure, l'idée de pinger hurdfr.org était de KB :-p)
Même si c'est franchement hors-sujet, j'espère que cela aura su répondre aux interrogations de certains. (et puis même si vous vous posiez pas la question, vous savez maintenant! :-)
[2]: Je tiens à citer Wolfgang Jährling, qui commençait son (excellente) conférence sur les mécanismes d'authentification du Hurd, dont un court résumé est disponible sur http://www.gnu.org/software/hurd/auth.html(...) , par un retentissant « security is just a bad hack ». En effet, n'oublions pas que la vraie réponse à la sécurité est de rendre les gens bons, de telle façon que tout le monde reporte les problèmes de sécurité sans jamais les utiliser à des fins malhonnêtes - et que personne n'ait même de buts qui ne soient pas louables! Mais malheureusement, cette tâche est quelque peu difficile à accomplir en écrivant des logiciels. Nous sommes donc condamnés à se limiter à ce bad hack qu'est la « sécurité » :-)
[3]: j'espère que les amateurs auront reconnu une fine allusion à Renaud, et pourront donc me dire de quelle chanson je parle :-p