je suis en train de créer un bloqueur de console pour GNU/Linux en Ruby.
Jusqu’a présent, le code source ressemble à ça :
[code]#!/usr/bin/ruby
This is free software, you have the right to use it and other rights granted by the GNU General
Public License, under the terms of this license.
def initialize
puts ‘Entrez le mot de passe pour bloquer la console’
$mdp=gets.chomp
puts “\n”*80
mot_de_passe
end # fin définition initialize
def mot_de_passe
puts ‘Entrez le mot de passe pour débloquer la console’
$mdpfourni=gets.chomp
if $mdpfourni==$mdp then exit
else begin
puts 'Mot de passe incorrect !'
mot_de_passe
end
end # fin définition mot_de_passe
end # fin de la zone définition.
initialize[/code]
Alors, comme vous pouvez le voir, ça bloque la console dans laquelle on lance le programme. Mais le problème, c’est qu’un simple CTRL+C permet de tuer le processus, et donc de débloquer la console. D’où problème de sécurité grave. Alors je me demandais si un guru sympa pouvait m’expliquer comment “capturer” les signaux à la CTRL+C pour les désactiver.
[quote name=‹ Tisspa › date=’ 15 Jun 2005, 07:52’]j’ai trouvé un ptit exemple qui illustre exactement ce que tu veux, ca se trouve là…
Je crois que y’a rien d’autre à dire, c’est vraiment tout simple…
Ah et au fait Ruby saibien…
[right][post=« 368337 »]<{POST_SNAPBACK}>[/post][/right][/quote]
C’est tellement bien que tu lui donne une solution en script shell…
[quote name=‘ZGoblin’ date=’ 15 Jun 2005, 07:40’]A mon avis ce n’est pas vraiment comme ça qu’il faut faire.
Je ne comprend pas pourquoi tu voudrais bloquer une console et la débloquer avec un mot de passe alors qu’il te suffit juste de te délogger.
[right][post=“368336”]<{POST_SNAPBACK}>[/post][/right][/quote]
Tout simplement parce que j’aime pas lancer 6 gettys en même temps (question de sécurité), que je me limite à 3 (dont 1 pour les sorties crades du X que j’arrive pas à rediriger vers /dev/null), que je compile pas mal de trucs avec redirection vers /dev/null , donc avec une console qui reste propre, et que j’ame pas que quand je vais chercher un aliment de type café/pizza/biscuit ou autre, mon frère se ramène et lance mp3blaster en root, m’obligeant après ça a faire un bon gros chmod -R 750 sur mon /donnees/musiqueetvideo (parce qu’il aime bien faire des playlists blindées), et que c’est le risque que je cours quand je m’éloigne de ma console root. En plus, je ne peux pas me permettre de laisser la compilation se dérouler tranquille dans sa fenêtre, parce qu’en même temps je bidouille le système. Donc des raisons très compliquées, mais qui justifient ce que je fais.
Voualah, saifini;
[quote name=‹ LoneWolf › date=’ 15 Jun 2005, 08:04’]C’est tellement bien que tu lui donne une solution en script shell…
LoneWolf
En meme temps, le shell, c’est top.
[right][post=« 368339 »]<{POST_SNAPBACK}>[/post][/right][/quote]
ouaip d’accords, mais comme tu dis le shell c’est bien aussi, et pour ce qu’il veut faire, ca suffit, mais bon ruby permet evidement(merci LoneWolf sans ton intervention j’aurais même pas cherché…) de gérer les signaux, avec la méthode trap, qui s’utilise comme-ceci :
trap(sig, cde)
trap(sig){ … }
ou sig correspond à ton signal, en l’occurence SIGINT et cde correspond à ce que tu veu en faire, soit IGNORE pour ignorer le signal, soit DEFAULT pour laisser l’os le gérer…
en l’occurence tu peux faire trap(« SIGINT », « IGNORE ») au début de ton code…
Je dis peut etre une connerie mais xlock, ça te suffirait pas ?
Tu tapes xlock avant de sortir du pc et tu tapes ton mdp de session pour te reloguer apres. Pedant ce temps t’as meme un screen saver pour eviter de tuer l’ecran avec des images quasi fixes.
Evidement, si tu lances pas de serveur x, xlock risque de pas beaucoup t’aider.
Un petit uppage pour vous annoncer que console_blocker 0.1 est out. Après une bonne grosse pause, j’ai remis les mains dans le cambouis, et le voila :P.
