Tu l'as dit, c'est un abruti. Fout lui un coup pied au cul bien senti.
De plus, s'il est dans la salle d'info avec de mauvaises intentions, il n'a pas besoin de faire un fork bomb pour foutre le bordel. Il débranche une prise de courrant, une prise réseau, une prise clavier, pique 1 seconde la souris pour cliquer sur "fermeture" ou fait <alt><F4>, etc...
Le truc le plus "marrant" c'est lorsqu'un utilisateur n'a plus les yeux sur ça session (il discute, il est allé pisser, etc), c'est de changer son mot de passe. Même les connards y pensent.
> on est dans un contexte desktop, et pourtant.
Pas vraiment puisqu'il peut y avoir plusieurs utilisateurs (de plus simultanément) sur une même bécane. La bécane devient un serveur de session.
Enfin, les salle informatiques sont des lieux où on fédère. En un sens ça doit quasiment être considéré comme des serveurs. Or pour les serveurs je n'ai jamais dit qu'ulimit était inutile.
> Autre situation : t'es connecte a distance sur la machine et un connard la reboot.
C'est un connard. Tu peux interdire la commande reboot, même si c'est un connard, il va penser à débrancher la prise ou appuis sur le bouton reset. Même un connard profond peut penser ça et ulimit est en rien une solution à ce problème.
> Ben ouais, mais on est vendredi, 17h38, l'admin vient de partir en we, t'attendra lundi mon coco... Vecu par moi meme, et plusieurs fois.
Et oui, la vie est dure. Mais ulimit ne change rien dans ce que tu as dit et t'en es la preuve puisque tu utilises ulimit (si tu l'utilises, ce que maintenant j'en doute).
> Non. T'avais qu'a mettre un ulimit
La solution magique mais que ces abrutis de distributeur avec tous leurs experts ne mettent pas en oeuvre.
Oui, oui, oui, oui. C'est celà.
> DoS, encore une fois.
Pour info, en passant.
Si tu configure ulimit pour qu'il soit efficace il faut le configure à 100 voir 150 processus grand maximum. Un utilisateur peut légitiment atteindre cette limite. Dans ce cas c'est aussi un denial of service. Oui oui et avec presque les même conséquences.
Certe, ce n'est pas un denial of service attack. Mais pour l'utilisateur c'est un denial of service.
> on va pas embaucher un mec pour nous expliquer qu'il peut pas faire ce qu'il est cense faire.
C'est clair que toi vu le niveau élevé de tes analyses (même pas foutu d'imaginer ce que peut faire un connard), je ne risque pas de t'embaucher.
[^] # Re: public
Posté par IsNotGood . En réponse au journal De la confiance relative dans son produit. Évalué à 2.
Tu l'as dit, c'est un abruti. Fout lui un coup pied au cul bien senti.
De plus, s'il est dans la salle d'info avec de mauvaises intentions, il n'a pas besoin de faire un fork bomb pour foutre le bordel. Il débranche une prise de courrant, une prise réseau, une prise clavier, pique 1 seconde la souris pour cliquer sur "fermeture" ou fait <alt><F4>, etc...
Le truc le plus "marrant" c'est lorsqu'un utilisateur n'a plus les yeux sur ça session (il discute, il est allé pisser, etc), c'est de changer son mot de passe. Même les connards y pensent.
> on est dans un contexte desktop, et pourtant.
Pas vraiment puisqu'il peut y avoir plusieurs utilisateurs (de plus simultanément) sur une même bécane. La bécane devient un serveur de session.
Enfin, les salle informatiques sont des lieux où on fédère. En un sens ça doit quasiment être considéré comme des serveurs. Or pour les serveurs je n'ai jamais dit qu'ulimit était inutile.
> Autre situation : t'es connecte a distance sur la machine et un connard la reboot.
C'est un connard. Tu peux interdire la commande reboot, même si c'est un connard, il va penser à débrancher la prise ou appuis sur le bouton reset. Même un connard profond peut penser ça et ulimit est en rien une solution à ce problème.
> Ben ouais, mais on est vendredi, 17h38, l'admin vient de partir en we, t'attendra lundi mon coco... Vecu par moi meme, et plusieurs fois.
Et oui, la vie est dure. Mais ulimit ne change rien dans ce que tu as dit et t'en es la preuve puisque tu utilises ulimit (si tu l'utilises, ce que maintenant j'en doute).
> Non. T'avais qu'a mettre un ulimit
La solution magique mais que ces abrutis de distributeur avec tous leurs experts ne mettent pas en oeuvre.
Oui, oui, oui, oui. C'est celà.
> DoS, encore une fois.
Pour info, en passant.
Si tu configure ulimit pour qu'il soit efficace il faut le configure à 100 voir 150 processus grand maximum. Un utilisateur peut légitiment atteindre cette limite. Dans ce cas c'est aussi un denial of service. Oui oui et avec presque les même conséquences.
Certe, ce n'est pas un denial of service attack. Mais pour l'utilisateur c'est un denial of service.
> on va pas embaucher un mec pour nous expliquer qu'il peut pas faire ce qu'il est cense faire.
C'est clair que toi vu le niveau élevé de tes analyses (même pas foutu d'imaginer ce que peut faire un connard), je ne risque pas de t'embaucher.