Bonjour,
le travaille sur un réseau, chaque ordinateur du réseau possède une liste d'utilisateur autorisés à se connecter sur les ordinateurs.
Certaines personnes s'amusent à créer des programmes destinés à faire planter un ordinateur et l'execute en ssh à partir d'un autre ordinateur du réseau.
Cela devient très génant lorsque l'on a pas sauvegarder son travail et qu'un utilisateur extérieur se connecte en ssh sur notre ordinateur et le fait planter.
Je n'ai malheureusement pas l'accès en root sur l'ordinateur.
 
J'ai élaboré un petit shell script, mais il ne fonctionne pas (car impossible de tuer le bash en non root):
 

 
Quelqu'un a-t-il une idée pour remedier à l'utilisation de la commande kill -9 ?

contact ton admin et voilà. Ton programme ne peut pas marcher sans droit.

ça aurait été interessant de trouver une solution en tant que simple utilisateur pour déconnecter l'utilisateur connecté en ssh.
Une astuce comme faire planter sshd pour déconnecter la personne malvaillante.

déjà, comment se fait il que cette "personne malveillante" arrive à te killer tes applications?

Il lui tue pas ses applis, il fait planter la machine si j'ai bien compris.

J'ai joue a ca pendant mes etudes. Une simple forkbomb suffit generalement a planter la machine ciblee.  
Le jour ou ce petit jeu s'est retourne contre moi, j'ai trouve une astuce pour me proteger : tu surveilles les utilisateurs sur ta machine. Des que tu en trouves un qui n'est pas toi, tu reperes la machine a partir de laquelle il se connecte, et tu la plantes de la meme facon (ssh+forkbomb). Un peu violent et facile a contourner. Ca m'a cependant permis de continuer a travailler, alors peut etre que ca pourra t'aider...

on peut facilement se proteger d'un forkbomb en limitant le nombre de processus max/utilisateur (ulimit), s'il est en réseau dans une boite, l'admin devrait penser à ca!
c'est plus simple que s'amuser à planter les autres machine, dans un environnement de boulot, c'est pas le top , par contre à l'école/fac ou autre, je dis pas, ca permet en même temps d'apprendre

un serveur bien param aura killé ton programme bien avant de planté.
 
a l'IUT j'avais un programme qui calculait les solution d'un sudoku et les gardait en memoire, j'avait tanté avec une grille vide (i.e. sans contrainte), et bien au bout d'un moment le programme a planté car j'occupait de trop de RAM. Idem pour le CPU, bien param tu peut pas monopolisé le serveur.
 
C'est sur que quand on a des admins en carton et des utilisateur un peu  débile ça peut pas marcher.
 
Ceci dit avant de vouloir faire ce genre de script faudrait deja connaitre/comprendre le fonctionnement d'un OS/d'Unix.

Merci pour vos réponses.
Les OS sont tous censés être "implantable" (vérification de la mémoire, pagination, limitation de ressource).
En réalité, ce n'est pas le cas, quelque soit l'OS évolué il y a des techniques plus ou moins sophistiquées pour faire planter le PC (forkbomb, ...).
Mes cours d'asm me l'on largement confirmé ...
 
Ayant pu intercepter une partie du programme de plantage sur le réseau, je pense effectivement qu'il sagit d'un forkbomb (allocation infini).
 
L'administrateur réseau est largement dépassé par la situation (il n'arrive même pas à créer correctement des comptes réseaux)
 

Et ben dans ce cas la on contacte la hiérarchie et on explique le problème.
Si les personnes se connectent avec leur propre compte pour pourrir une autre station la simple consultation des logs de la station victime donnera l'identité du coupable et ayant signé une charte d'utilisation des ressources informatique (si y a pas ca... faudrait quand meme penser a changer d'admin) il risque des sanctions.

Même avec un forkbomb, il suffit à l'admin de se connecter en root, de se donner un shell avec une super priorité (nice --20 bash par exemple) puis de traquer/killer le forkbomb (ps |grep)
 

Change d'admin... ou montre-lui comment faire => avec un peu de bol il pourrait à terme te laisser les droits d'admin...
 

Pourquoi ton script commence par faire un truc s'il a des arguments et s'il n'en a pas se relance lui-même avec un argument ? Déjà que ta machine est forkbombée toi tu lui mets un processus inutile en plus dans la tronche. Il te suffirait de traiter au départ le cas "je remplis une variable avec mes arguments ou un truc par défaut s'il n'y en a pas ; puis dans mon algo je traite ma variable qui contiendra soit mes arguments soit le truc par défaut" => ça se fait en une ligne => var=${*:-truc par defaut}
Ensuite pourquoi ton script cherche absolument à avoir un argument qu'il écrase ensuite par un "set" ???
 
Ah super le test 1 plus petit ou égal à 1... (tu veux une boucle infinie => tu tapes "while true" )

Le test de l'argument c'était pour forcer la redirection de sortie standart (execution silencieuse avec le & ), c'est un peu une bidouille et il y a des commandes qui le font automatiquement (>dev/null)...
En effet while true fonctionne sous le bash, mais comme je programme que très rarement sous shell (make...), je ne savais plus si le type booléen était bien implémenté (sachant que je ne me suis pas attardé à faire ce code).

le true ici n'est pas vraiment la valeur vrai d'un type booléen comme on le concoit dans un langage de programmation, c'est juste une commande qui retourne 0 comme code de retour.
le shell considère que la commande est un succés si le code de retour ($?) est égale à 0.