L'idée m'est donc venu d'essayer de faire la même chose sous GNU/Linux, et je n'ai pas trouvé.
Alors et vous, avez-vous une idée ?
Voici le code pré-cité :
#include <stdio.h>
int main (void) {
while (1)
printf("\t\b\b\b ") ;
return EXIT_SUCCESS ;
}
> Lire la dépêche (29 commentaires, moyenne: 3,5).
Vous avez demandé le commentaire #74679.
Run by 
Cette page a été générée par Templeet en 0.0795s (dont 0.0079 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Linux aussi
Ce programme ne plante pas sous Windows 98.
De plus, c'est un bug dans la console (hum) par défaut de Windows NT, puisque si le programme est lancé dans une autre console, ça ne plante plus.
Sous linux, un
while(fork()) ;
devrait faire l'affaire non ?
ça ne fait pas directement planter la machine, mais elle est inutilisable et il ne reste plus qu'à redémarer sauvagement.
[^]Re: Linux aussi
ça ne fait pas directement planter la machine, mais elle est inutilisable et il ne reste plus qu'à redémarer sauvagement.
Quand on administre une machine ou ce genre de chose est possible (je pense notamment aux écoles ou, a chaque cours sur le fork, ca arrive :) ), on commence par mettre un ulimit pour limiter le nombre de process par utilisateur. Ensuite, garder dans un coin une console root bien nice permet généralement de rattrapper le coup, a grand coup de killall.
[^]Re: Linux aussi
Et contre le while(malloc(42)); tu fais quoi ? :p
[^]Re: Linux aussi
1/ while(malloc(42)) s'arrêtera de lui-même quand malloc retournera NULL.
2/ ulimit permet aussi de limiter la consommation de mémoire.
[^]Re: Linux aussi
1/ while(malloc(42)) s'arrêtera de lui-même quand malloc retournera NULL.
J'ai un doute sur le fonctionnement de linux. Il me semble que la mémoire s'alloue par page, et que le mémoire n'est pas réellement allouée tant qu'il n'y a pas eut d'accès en écriture. C'est vrai ou j'ai révé ?
[^]Re: Linux aussi
En fait, tu peux allouer beaucoup plus de mémoire que tu n'en a (swap comprise) si tu ne l'utilise pas tout de suite, comme dans ce cas là.
C'est pourquoi il est recommandé de n'allouer de la mémoire que lorsqu'on en a besoin et seulement la quantité requise.
Donc cette boucle ne devrait pas faire grand chose de méchant, au bout d'un moment, malloc retournera quand même NULL mais je pense que, n'étant pas utilisée, reste de la mémoire pour les autres processus.
Etienne
PS: il me semble que ce sujet était abordé dans le livre de Christophe Blaise la programmaion système en C sous Linux (désolé pour la pub mais c'est un très bon livre)
[^]Re: Linux aussi
Christophe BLAESS bien sûr, je suis désolé d'avoir écorché son nom... Mea maxima culpa.
abracadabra *-1*
[^]Re: Linux aussi
Ceci dit, il faut aussi contrôler les sémaphores (semget, cf ipcs), la mémoire partagée (shmget, cf ipcs), les ports ouverts (tu peux ouvrir tous ceux au-dessus de 1024 si ça t'amuse), les inodes des systèmes de fichiers, l'espace disque des systèmes de fichier, le nombre de sockets... (en gros éviter de saturer les tables de taille fixe du noyau ou du système)
[^]Re: Linux aussi
moi quand je fais un while(malloc(10)) au bout d'un temps très court (qq sec), le kernel tue des process au hasard. Pour l'instant je l'ai toujours interrompu avant un éventuel plantage.
[^]Re: Linux aussi
contre les "trucalacon" genre while(fork()) ou while(malloc(42)) et contre toute autre pollution des ressources du systeme, il éxiste un fichier de limites soft et hard qui permet d'eviter toute saturation : /etc/security/limits.conf
exemple, en ayant vos utilisateurs font partie d'un groupe "users" et qques personnes dans le groupe "src" (compilations de source)
ca vous donne un fichier :
# /etc/security/limits.conf
# <domain> <type> <items> <value>
# ne deboggant pas les soft, on va éviter les coredumps pour tout le monde
* soft core 0
#j'ai 10 users en parallele, 1Go de RAM, donc pas plus de...
#on va dire 64MB sur 12 process par user (3 par connexion),
#sauf ceux qui compilent : 256MB sur un max de 32 :)
@staff hard rss 65536
@staff soft nproc 10
@staff hard nproc 20
@src hard rss 262144
@src soft nproc 16
@src hard nproc 32
#ce n'est pas un serveur de calcul, donc pas de process durant plus d'une heure (3600 secondes):
@staff hard cpu 3600
#les connections : 4 simultanée pour les users, 0 pour les daemons
@staff - maxlogins 4
@daemon - maxlogins 0
ftp - maxlogins 0
#EOF
Eet voilà... bon bien sûr ça se fignole, mais je vous laisse lire le man.
Sinon, il est possible de tuner ces limites directement dans le kernel comme le nombre de threads par user, limité à (d'après mes souvenirs) 256 en dur.
[^]Re: Linux aussi
C'est sur quelle distribution ?
Parce que le noyau ne permet pas de gérer les ulimit par user (pas encore et pas en standard).
Je pense que c'est un mécanisme d'une distribution qui lui permet de gérer ça pour le lancement des daemon.
Me trompe-je ?
[^]Re: Linux aussi
>C'est sur quelle distribution ?
C'est indépendant de la distribution. Sous linux, c'est PAM qui semble gérer ces limites.
Cette possibilité existe aussi sur d'autres unix, moi meme je l'ai découvert sur AIX.
Si vous avez vraiment envie/besoin de securiser votre serveur, je vous conseille cet excellent bouquin de G.Morani :
- C'est orienté RedHat, mais appliquable partout : http://www.linuxdoc.org/LDP/solrhe/Securing-Optimizing-Linux-RH-Edi(...)
- paragraphe su les limites en particulier : http://www.linuxdoc.org/LDP/solrhe/Securing-Optimizing-Linux-RH-Edi(...)
C'est dans ce bouquin que j'avais vu comment limiter le nombre de processes par user, et le nb de processes réservés à root, un peu comme des slots vides, directement dans le kernel :
"To increase the number of tasks allowed the maximum number of processes per user, you may need to edit the /usr/src/linux/include/linux/tasks.h file and change the following parameters. Edit the tasks.h file, vi +14 /usr/src/linux/include/linux/tasks.h and change the following parameters: NR_TASKS from 512 to 3072 and MIN_TASKS_LEFT_FOR_ROOT from 4 to 24"
[^]Re: Linux aussi
Tu peux limiter le nombre de process pour les users (avec ulimit) et donc ça ne fait pas forcément planter linux.
[^]Re: Linux aussi
Dans man bash, on trouve:
<CITATION>
ulimit [-SHacdfmstpnuv [limit]]
Ulimit provides control over the resources available to the shell and to processes started by it, on systems that allow such control.
The value of limit can be a number in the unit specified for the resource, or the value unlimited. The H and S options specify that
the hard or soft limit is set for the given resource. A hard limit cannot be increased once it is set; a soft limit may be increased
up to the value of the hard limit. If neither H nor S is specified, the command applies to the soft limit. If limit is omitted, the
current value of the soft limit of the resource is printed, unless the H option is given. When more than one resource is specified,
the limit name and unit is printed before the value. Other options are interpreted as follows:
-a all current limits are reported
-c the maximum size of core files created
-d the maximum size of a process's data segment
-f the maximum size of files created by the shell
-m the maximum resident set size
-s the maximum stack size
-t the maximum amount of cpu time in seconds
-p the pipe size in 512-byte blocks (this may not be set)
-n the maximum number of open file descriptors (most systems do not allow this value to be set, only displayed)
-u the maximum number of processes available to a single user
-v The maximum amount of virtual memory available to the shell
An argument of -- disables option checking for the rest of the arguments. If limit is given, it is the new value of the specified
resource (the -a option is display only). If no option is given, then -f is assumed. Values are in 1024-byte increments, except for
-t, which is in seconds, -p, which is in units of 512-byte blocks, and -n and -u, which are unscaled values. The return status is 0
unless an illegal option is encountered, a non-numeric argument other than unlimited is supplied as limit, or an error occurs while
setting a new limit.
</CITATION>
Comme quoi, grace a ulimit, on peut vraiment restreindre les possibilités des utilisateurs.
<PUB>
Pour peu qu'ils soient chrootés ... (voir schroot sur sourceforge)
</PUB>
[^]Re: Linux aussi
Alors en voila un qui est pas prévu par ulimit :
sursaturation de /tmp. Meme un reboot sauvage
ne rêgle pas le pb.
#include <stdio.h>
int main () {
unsigned long n;
char nz[1024], *n0="/tmp/.%ul";
while (1) {
sprintf (nz,n0,n); fclose(fopen(nz,"w+"));
}
en quelques secondes, plus un inode dispo dans /tmp. Merci qui?
[^]Re: Linux aussi
Sous mandrake (>=8.0) (je sais pas pour les autres mais tu peut toujours le faire à la main) tu peut la configurer pour vider automatiquement /tmp au démarrage.
Et hop problème envolé.
[+] [^]Re: Linux aussi
Oui, sous Debian c'est le cas par défaut.
-1, mais ceci n'est pas un troll
[^]Re: Linux aussi
Pour que ça marche, il faut combiner les deux:
while (42) { fork();malloc(420); }
Vu que la limite de mémoire s'applique par process, pour peu que la limite de process ne soit pas trop draconnienne, on peut ainsi bouffer toutes la mémoire dispo, swap comprise, ce qui fait bien un DoS. Par contre ça se rattrape à coup de SysRq, donc on est pas obliger de rebooter.