Si tu parles du point (b), je veux bien le croire mais ca ne calme pas ma paranoia depressive. Pour le point (a), j'ai trouve ce passage page 278 de Les bases de l'adminstration système (AEleen Frish) http://www.editions-oreilly.fr/catalogue/esa2.html(...)
<<
[limit & ulimit]
Venons-en maintenant aux mauvaises nouvelles. Du point de vue de l'administration système, les limitations des ressources UNIX sont tout à fait inutiles. Tout d'abord, les limitations matérielles sont souvent cablées dans le noyau et ne peuvent être modifiées par l'administrateur système. De plus, les utilisateurs peuvent toujours modifier leurs propres limitations logicielles. Tout ce que peut faire un administrateur système est de placer les commandes désirées dans les fichiers .profile et .cshrc des utilisateurs en espérant qu'ils ne le modifieront pas. Par ailleurs, les limitations sont établies sur la base d'un seul processus. Malheureusement, de nombreuses taches comportent plusieurs processus et il n'existe aucun mecanisme pour imposer des limitations sur un processus pere et tous ses processus fils. Pour terminer, dans la plupart des cas, les limitations ne sont mises en vigueur; c'est particulièrement vrai pour les limitations importantes, à savoir la consommation de temps CPU et l'utilisation de la memoire.
>>
En bref, on est bien oblige de faire confiance aux users, on joue la carte Security Through Obscurity en modifiant en douce les .profiles, et on se doit de rester 24h/24 devant la console a faire des `ps' pour surveiller le moindre depart d'un process fou.
Ceci dit, ma version du bouquin est ancienne. Et il se pourrait peut etre qu'il soit apparu depuis d'autres mecanismes de limitations dont je n'ai pas encore eu vent.
[^] # Re: degat
Posté par T Sang Neuf . En réponse à la dépêche Linux est-il à l'abri des virus ?. Évalué à 1.
<<
[limit & ulimit]
Venons-en maintenant aux mauvaises nouvelles. Du point de vue de l'administration système, les limitations des ressources UNIX sont tout à fait inutiles. Tout d'abord, les limitations matérielles sont souvent cablées dans le noyau et ne peuvent être modifiées par l'administrateur système. De plus, les utilisateurs peuvent toujours modifier leurs propres limitations logicielles. Tout ce que peut faire un administrateur système est de placer les commandes désirées dans les fichiers .profile et .cshrc des utilisateurs en espérant qu'ils ne le modifieront pas. Par ailleurs, les limitations sont établies sur la base d'un seul processus. Malheureusement, de nombreuses taches comportent plusieurs processus et il n'existe aucun mecanisme pour imposer des limitations sur un processus pere et tous ses processus fils. Pour terminer, dans la plupart des cas, les limitations ne sont mises en vigueur; c'est particulièrement vrai pour les limitations importantes, à savoir la consommation de temps CPU et l'utilisation de la memoire.
>>
En bref, on est bien oblige de faire confiance aux users, on joue la carte Security Through Obscurity en modifiant en douce les .profiles, et on se doit de rester 24h/24 devant la console a faire des `ps' pour surveiller le moindre depart d'un process fou.
Ceci dit, ma version du bouquin est ancienne. Et il se pourrait peut etre qu'il soit apparu depuis d'autres mecanismes de limitations dont je n'ai pas encore eu vent.