Désolé, j'avais mal compris. J'étais dans le cas de l'utilisation d'ulimit pour limité l'utilisation de la mémoire.
> Toute la table de processus est prise par tes fork bomb , et si tu arrive trop tard (cad 3 sec apres le lancement) tu ne pourras strictement plus rien faire. Meme pas lancé un kill, car le temps qu'une place se libere dans la table des processus , il sera repris par un autre fils.
Certe, il faut rebooter. La grande affaire. Oui, c'est une grande affaire pour un serveur. Mais pour un serveur je n'ai jamais dit que ulimit n'avait pas de sens, bien au contraire.
> Le plus drole c'est que c'est toi qui prone l'interdiction pur et dur de compilation/execution de binaire non approuvé par l'administration ,
J'ai dit ça pour le cas d'une bécane qui est adminitrée par un administrateur. On n'est plus dans le cas de monsieur tout le monde qui installe une Ubuntu pour son usage personnel.
Ceci pour des raisons de sécurité et notamment de confidentialité. Dans une entreprise (puisque la bécane est administrée) c'est IMPORTANT ! C'est 8 millions de fois plus important que le reboot d'une bécane (qui de plus n'est pas un serveur) tous les 3 ans car on n'a pas configuré ulimit.
Avec un programme malintentionné que l'utilisateur a lancé par mégarde, depuis l'extérieur tu peux avoir un accès à la bécane qui est dans l'entreprise ! Oui oui !
Ce programme peut aussi s'amuser à envoyer des documents de l'utilisateur (en fait, de l'entreprise) sur internet !
C"est 80 milliard de milliard de fois plus grave qu'un improbable reboote d'une bécane qui n'est pas un serveur.
Et pourtant je ne suis pas si tyranique que ça. Ça dépend des données sur la bécane, des accès réseaux qu'elle a etc... Mais si c'est la secrétaire du boss par exemple, je vais être assez intransigeant.
Ça montre a quel point j'en ai rien à foutre d'ulimit pour un desktop.
Ulimit est vachement bien, même pour un desktop, dans un cas que je connais : pour gpg. Aujourd'hui beaucoup de distributions *autorisent* (et non restraindre ; car par défaut sur Linux on ne peut pas le faire) via pam/ulimit 32 ko de mémoire verrouillable (c'est-à-dire non swappable). C'est utilisé par gpg pour que le mot de passe qui est tapé ne se retrouve pas dans le swap. C'est une excellente idée. Ça devrait aussi être utilisé pas ssh, etc...
> mais la mise en place d'un limits.conf par défaut dans les distribs, ah ca non surtout pas...
Qu'un admin le fasse dans son entreprise, pourquoi pas, c'est rapide. Pour une distribution qui va être utilisé par une personne (c'est-à-dire que ce n'est pas un serveur) je n'en vois pas l'intérêt. Et le seul intérêt jusqu'à maintenant avancé est d'éviter un reboot. Ça n'empêche pas l'exploitation de faille de récurité ni rien, ça permet d'éviter un reboot de plus fort improbable. Ici il y a des gens qui parle d'"expérience" avec un "fork bomb", mais en général le "fork bomb" ils se le sont fait eux même, pour le "fun".
Tu parles d'une grande affaire...
Pour le desktop, il y a bien d'autre domaine a améliorer avant de s'occuper d'ulimit. Par exemple OOo. Dans un document OOo on peut mettre des macro qui écrivent sur le disque, etc...
On pourrait, par exemple, dans le cas où le document est ouvert depuis un navigateur ou un client mail (donc en général quand le document vient d'internet), qui lance OOo, avoir une option du type "sandbox" où toutes les lectures/écriture du document y seront faites.
Ça c'est un plus en sécurité et je serait ravis que toutes les distributions l'implémente. De plus ça ne limite pas l'utilisateur. Il peut ouvrir les documents, même ceux compliqué qui nécessite l'écrite sur un périphérique de stockage.
Un autre domaine d'amélioration dans le desktop, est la "généralisation" de la crypto pour les clées USB qu'on ballade partout. Ça implique que toutes les distributions se mettent d'accord sur un standard trivial à utiliser.
Ça aussi c'est un vrai plus. Si t'oublies ta clée chez un pote ou dans un lieu public, et qu'il y avait des documents importants dessus, ça peut faire une différence énorme et qui n'a rien à voir avec un reboot.
[^] # Re: public
Posté par IsNotGood . En réponse au journal De la confiance relative dans son produit. Évalué à 2.
Désolé, j'avais mal compris. J'étais dans le cas de l'utilisation d'ulimit pour limité l'utilisation de la mémoire.
> Toute la table de processus est prise par tes fork bomb , et si tu arrive trop tard (cad 3 sec apres le lancement) tu ne pourras strictement plus rien faire. Meme pas lancé un kill, car le temps qu'une place se libere dans la table des processus , il sera repris par un autre fils.
Certe, il faut rebooter. La grande affaire. Oui, c'est une grande affaire pour un serveur. Mais pour un serveur je n'ai jamais dit que ulimit n'avait pas de sens, bien au contraire.
> Le plus drole c'est que c'est toi qui prone l'interdiction pur et dur de compilation/execution de binaire non approuvé par l'administration ,
J'ai dit ça pour le cas d'une bécane qui est adminitrée par un administrateur. On n'est plus dans le cas de monsieur tout le monde qui installe une Ubuntu pour son usage personnel.
Ceci pour des raisons de sécurité et notamment de confidentialité. Dans une entreprise (puisque la bécane est administrée) c'est IMPORTANT ! C'est 8 millions de fois plus important que le reboot d'une bécane (qui de plus n'est pas un serveur) tous les 3 ans car on n'a pas configuré ulimit.
Avec un programme malintentionné que l'utilisateur a lancé par mégarde, depuis l'extérieur tu peux avoir un accès à la bécane qui est dans l'entreprise ! Oui oui !
Ce programme peut aussi s'amuser à envoyer des documents de l'utilisateur (en fait, de l'entreprise) sur internet !
C"est 80 milliard de milliard de fois plus grave qu'un improbable reboote d'une bécane qui n'est pas un serveur.
Et pourtant je ne suis pas si tyranique que ça. Ça dépend des données sur la bécane, des accès réseaux qu'elle a etc... Mais si c'est la secrétaire du boss par exemple, je vais être assez intransigeant.
Ça montre a quel point j'en ai rien à foutre d'ulimit pour un desktop.
Ulimit est vachement bien, même pour un desktop, dans un cas que je connais : pour gpg. Aujourd'hui beaucoup de distributions *autorisent* (et non restraindre ; car par défaut sur Linux on ne peut pas le faire) via pam/ulimit 32 ko de mémoire verrouillable (c'est-à-dire non swappable). C'est utilisé par gpg pour que le mot de passe qui est tapé ne se retrouve pas dans le swap. C'est une excellente idée. Ça devrait aussi être utilisé pas ssh, etc...
> mais la mise en place d'un limits.conf par défaut dans les distribs, ah ca non surtout pas...
Qu'un admin le fasse dans son entreprise, pourquoi pas, c'est rapide. Pour une distribution qui va être utilisé par une personne (c'est-à-dire que ce n'est pas un serveur) je n'en vois pas l'intérêt. Et le seul intérêt jusqu'à maintenant avancé est d'éviter un reboot. Ça n'empêche pas l'exploitation de faille de récurité ni rien, ça permet d'éviter un reboot de plus fort improbable. Ici il y a des gens qui parle d'"expérience" avec un "fork bomb", mais en général le "fork bomb" ils se le sont fait eux même, pour le "fun".
Tu parles d'une grande affaire...
Pour le desktop, il y a bien d'autre domaine a améliorer avant de s'occuper d'ulimit. Par exemple OOo. Dans un document OOo on peut mettre des macro qui écrivent sur le disque, etc...
On pourrait, par exemple, dans le cas où le document est ouvert depuis un navigateur ou un client mail (donc en général quand le document vient d'internet), qui lance OOo, avoir une option du type "sandbox" où toutes les lectures/écriture du document y seront faites.
Ça c'est un plus en sécurité et je serait ravis que toutes les distributions l'implémente. De plus ça ne limite pas l'utilisateur. Il peut ouvrir les documents, même ceux compliqué qui nécessite l'écrite sur un périphérique de stockage.
Un autre domaine d'amélioration dans le desktop, est la "généralisation" de la crypto pour les clées USB qu'on ballade partout. Ça implique que toutes les distributions se mettent d'accord sur un standard trivial à utiliser.
Ça aussi c'est un vrai plus. Si t'oublies ta clée chez un pote ou dans un lieu public, et qu'il y avait des documents importants dessus, ça peut faire une différence énorme et qui n'a rien à voir avec un reboot.