Bonjour. Je viens d'effacer de mon disque ce cheval de Troie détecté par
Virus Barrier X. J'ai été averti automatiquement par Otego.
Est-ce que de nombreuses personnes ont eu cette peste, apparue le 10
Mai, et qui est très dangereuse sur OS X, car elle efface
irrémédiablement tout le dossier Users?
http://www.intego.com/news/pr42.html
--
J. Pelmont
http://perso.wanadoo.fr/pelmont/index.html
for mail remove "aky"
Du style, n'afficher un message que si le fichier effacé semble bizarre. (Par exemple, afficher une boîte de dialogue si l'argument de rm est « ~ » ou « / »)
Quand on fait un rm -rf ~ dans le terminal, n'y a t il pas une demande
Non. Sauf si on a cree un alias a rm ou rm serait remplace par "rm -i". En tout cas si tu penses que tu vas avoir une jolie fenetre qui te dit: Etes-vous sur de vouloir effacer tout votre repertoire? La reponse est non.
-- Saïd.
Fra :
Julien Salort <lists@juliensalort.org> wrote:
Du style, n'afficher un message que si le fichier effacé semble bizarre.
(Par exemple, afficher une boîte de dialogue si l'argument de rm est
« ~ » ou « / »)
Quand on fait un rm -rf ~ dans le terminal, n'y a t il pas une demande
Non. Sauf si on a cree un alias a rm ou rm serait remplace par "rm -i". En
tout cas si tu penses que tu vas avoir une jolie fenetre qui te dit:
Etes-vous sur de vouloir effacer tout votre repertoire?
La reponse est non.
Du style, n'afficher un message que si le fichier effacé semble bizarre. (Par exemple, afficher une boîte de dialogue si l'argument de rm est « ~ » ou « / »)
Quand on fait un rm -rf ~ dans le terminal, n'y a t il pas une demande
Non. Sauf si on a cree un alias a rm ou rm serait remplace par "rm -i". En tout cas si tu penses que tu vas avoir une jolie fenetre qui te dit: Etes-vous sur de vouloir effacer tout votre repertoire? La reponse est non.
-- Saïd.
jim
Fra wrote:
Ca existe déjà, c'est même mon processus qui a le plus long uptime chez moi, ça s'appelle le cerveau...
Je pense que Jim entendait par "tape" : "lancer sans le savoir" (?)
C'est en effet ce que je disais, et je demandais s'il n'y avait pas une possibilité d'y remédier grâce à l'Unix embarqué sous le capot. Une enfilade m'a donné quelques explications.
-- Jim jeune morveux sans cerveau en puissance
Fra <fra@alussinan.org> wrote:
Ca existe déjà, c'est même mon processus qui a le plus long uptime chez
moi, ça s'appelle le cerveau...
Je pense que Jim entendait par "tape" : "lancer sans le savoir" (?)
C'est en effet ce que je disais, et je demandais s'il n'y avait pas une
possibilité d'y remédier grâce à l'Unix embarqué sous le capot. Une
enfilade m'a donné quelques explications.
Ca existe déjà, c'est même mon processus qui a le plus long uptime chez moi, ça s'appelle le cerveau...
Je pense que Jim entendait par "tape" : "lancer sans le savoir" (?)
C'est en effet ce que je disais, et je demandais s'il n'y avait pas une possibilité d'y remédier grâce à l'Unix embarqué sous le capot. Une enfilade m'a donné quelques explications.
-- Jim jeune morveux sans cerveau en puissance
nospam
Saïd wrote:
Fra :
Julien Salort wrote:
Du style, n'afficher un message que si le fichier effacé semble bizarre. (Par exemple, afficher une boîte de dialogue si l'argument de rm est « ~ » ou « / »)
Quand on fait un rm -rf ~ dans le terminal, n'y a t il pas une demande
Non. Sauf si on a cree un alias a rm ou rm serait remplace par "rm -i". En tout cas si tu penses que tu vas avoir une jolie fenetre qui te dit: Etes-vous sur de vouloir effacer tout votre repertoire? La reponse est non.
On peut pas remplacer /bin/rm par une appli cocoa ? ;-)
Remplacez nospam par mon prénom pour me contacter par email
Saïd <said@brian.lan> wrote:
Fra :
Julien Salort <lists@juliensalort.org> wrote:
Du style, n'afficher un message que si le fichier effacé semble bizarre.
(Par exemple, afficher une boîte de dialogue si l'argument de rm est
« ~ » ou « / »)
Quand on fait un rm -rf ~ dans le terminal, n'y a t il pas une demande
Non. Sauf si on a cree un alias a rm ou rm serait remplace par "rm -i". En
tout cas si tu penses que tu vas avoir une jolie fenetre qui te dit:
Etes-vous sur de vouloir effacer tout votre repertoire?
La reponse est non.
On peut pas remplacer /bin/rm par une appli cocoa ? ;-)
Du style, n'afficher un message que si le fichier effacé semble bizarre. (Par exemple, afficher une boîte de dialogue si l'argument de rm est « ~ » ou « / »)
Quand on fait un rm -rf ~ dans le terminal, n'y a t il pas une demande
Non. Sauf si on a cree un alias a rm ou rm serait remplace par "rm -i". En tout cas si tu penses que tu vas avoir une jolie fenetre qui te dit: Etes-vous sur de vouloir effacer tout votre repertoire? La reponse est non.
On peut pas remplacer /bin/rm par une appli cocoa ? ;-)
Remplacez nospam par mon prénom pour me contacter par email
Éric Lévénez
Le 21/05/04 20:11, dans <1ge5jbr.1ahl60pxov79N%, « Romuald Brunet » a écrit :
Saïd wrote:
Fra :
Julien Salort wrote:
Du style, n'afficher un message que si le fichier effacé semble bizarre. (Par exemple, afficher une boîte de dialogue si l'argument de rm est « ~ » ou « / »)
Quand on fait un rm -rf ~ dans le terminal, n'y a t il pas une demande
Non. Sauf si on a cree un alias a rm ou rm serait remplace par "rm -i". En tout cas si tu penses que tu vas avoir une jolie fenetre qui te dit: Etes-vous sur de vouloir effacer tout votre repertoire? La reponse est non.
On peut pas remplacer /bin/rm par une appli cocoa ? ;-)
Cela dépend de ce que tu entends par Cocoa. Si cela signifie une application graphique, la réponse est non car unix ne l'accepterait pas. Mais "rm" peut être écrit en C, C++, Objective-C, Perl... tout ce que l'on veut. Il faut juste que la commande soit utilisable seule et en tâche de fond.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 21/05/04 20:11, dans <1ge5jbr.1ahl60pxov79N%nospam@chivil.com>, « Romuald
Brunet » <nospam@chivil.com> a écrit :
Saïd <said@brian.lan> wrote:
Fra :
Julien Salort <lists@juliensalort.org> wrote:
Du style, n'afficher un message que si le fichier effacé semble bizarre.
(Par exemple, afficher une boîte de dialogue si l'argument de rm est
« ~ » ou « / »)
Quand on fait un rm -rf ~ dans le terminal, n'y a t il pas une demande
Non. Sauf si on a cree un alias a rm ou rm serait remplace par "rm -i". En
tout cas si tu penses que tu vas avoir une jolie fenetre qui te dit:
Etes-vous sur de vouloir effacer tout votre repertoire?
La reponse est non.
On peut pas remplacer /bin/rm par une appli cocoa ? ;-)
Cela dépend de ce que tu entends par Cocoa. Si cela signifie une application
graphique, la réponse est non car unix ne l'accepterait pas. Mais "rm" peut
être écrit en C, C++, Objective-C, Perl... tout ce que l'on veut. Il faut
juste que la commande soit utilisable seule et en tâche de fond.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 21/05/04 20:11, dans <1ge5jbr.1ahl60pxov79N%, « Romuald Brunet » a écrit :
Saïd wrote:
Fra :
Julien Salort wrote:
Du style, n'afficher un message que si le fichier effacé semble bizarre. (Par exemple, afficher une boîte de dialogue si l'argument de rm est « ~ » ou « / »)
Quand on fait un rm -rf ~ dans le terminal, n'y a t il pas une demande
Non. Sauf si on a cree un alias a rm ou rm serait remplace par "rm -i". En tout cas si tu penses que tu vas avoir une jolie fenetre qui te dit: Etes-vous sur de vouloir effacer tout votre repertoire? La reponse est non.
On peut pas remplacer /bin/rm par une appli cocoa ? ;-)
Cela dépend de ce que tu entends par Cocoa. Si cela signifie une application graphique, la réponse est non car unix ne l'accepterait pas. Mais "rm" peut être écrit en C, C++, Objective-C, Perl... tout ce que l'on veut. Il faut juste que la commande soit utilisable seule et en tâche de fond.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
benoit.sansspam
Julien Salort wrote:
Du style, n'afficher un message que si le fichier effacé semble bizarre. (Par exemple, afficher une boîte de dialogue si l'argument de rm est « ~ » ou « / »)
Oui mais non car si je sais le faire en script alors c'est faisable en commande : demander la liste des dossiers contenus dans ~ puis les effacer les uns après les autres avec une boucle. Il ne restera que les fichiers non contenus dans un dossiers = pas grand chose.
-- Benoît Leraillez
La douleur des autres est tout à fait supportable, hors les cris.
Julien Salort <lists@juliensalort.org> wrote:
Du style, n'afficher un message que si le fichier effacé semble bizarre.
(Par exemple, afficher une boîte de dialogue si l'argument de rm est
« ~ » ou « / »)
Oui mais non car si je sais le faire en script alors c'est faisable en
commande : demander la liste des dossiers contenus dans ~ puis les
effacer les uns après les autres avec une boucle. Il ne restera que les
fichiers non contenus dans un dossiers = pas grand chose.
--
Benoît Leraillez
La douleur des autres est tout à fait supportable, hors les cris.
Du style, n'afficher un message que si le fichier effacé semble bizarre. (Par exemple, afficher une boîte de dialogue si l'argument de rm est « ~ » ou « / »)
Oui mais non car si je sais le faire en script alors c'est faisable en commande : demander la liste des dossiers contenus dans ~ puis les effacer les uns après les autres avec une boucle. Il ne restera que les fichiers non contenus dans un dossiers = pas grand chose.
-- Benoît Leraillez
La douleur des autres est tout à fait supportable, hors les cris.
lists
Éric Lévénez wrote:
Cela dépend de ce que tu entends par Cocoa. Si cela signifie une application graphique, la réponse est non car unix ne l'accepterait pas. Mais "rm" peut être écrit en C, C++, Objective-C, Perl... tout ce que l'on veut. Il faut juste que la commande soit utilisable seule et en tâche de fond.
Est-ce que unix accepterait que /bin/rm envoie et reçoive des AppleEvents ?
Si oui, il suffit d'avoir une autre application, graphique elle, qui s'occupe d'ouvrir la boîte de dialogue. Elle envoie alors la réponse (oui ou non) à rm par un autre AppleEvent.
Bien entendu, cela suppose qu'une session soit ouverte. Mais l'idée c'est de contrecarrer les chevaux de Troie « graphiques ».
-- R: Parce que ça renverse bêtement l'ordre naturel de lecture! Q: Mais pourquoi citer en fin d'article est-il si effroyable? R: Citer en fin d'article Q: Quelle est la chose la plus désagréable sur les groupes de news?
Éric Lévénez <news@levenez.com> wrote:
Cela dépend de ce que tu entends par Cocoa. Si cela signifie une application
graphique, la réponse est non car unix ne l'accepterait pas. Mais "rm" peut
être écrit en C, C++, Objective-C, Perl... tout ce que l'on veut. Il faut
juste que la commande soit utilisable seule et en tâche de fond.
Est-ce que unix accepterait que /bin/rm envoie et reçoive des
AppleEvents ?
Si oui, il suffit d'avoir une autre application, graphique elle, qui
s'occupe d'ouvrir la boîte de dialogue. Elle envoie alors la réponse
(oui ou non) à rm par un autre AppleEvent.
Bien entendu, cela suppose qu'une session soit ouverte. Mais l'idée
c'est de contrecarrer les chevaux de Troie « graphiques ».
--
R: Parce que ça renverse bêtement l'ordre naturel de lecture!
Q: Mais pourquoi citer en fin d'article est-il si effroyable?
R: Citer en fin d'article
Q: Quelle est la chose la plus désagréable sur les groupes de news?
Cela dépend de ce que tu entends par Cocoa. Si cela signifie une application graphique, la réponse est non car unix ne l'accepterait pas. Mais "rm" peut être écrit en C, C++, Objective-C, Perl... tout ce que l'on veut. Il faut juste que la commande soit utilisable seule et en tâche de fond.
Est-ce que unix accepterait que /bin/rm envoie et reçoive des AppleEvents ?
Si oui, il suffit d'avoir une autre application, graphique elle, qui s'occupe d'ouvrir la boîte de dialogue. Elle envoie alors la réponse (oui ou non) à rm par un autre AppleEvent.
Bien entendu, cela suppose qu'une session soit ouverte. Mais l'idée c'est de contrecarrer les chevaux de Troie « graphiques ».
-- R: Parce que ça renverse bêtement l'ordre naturel de lecture! Q: Mais pourquoi citer en fin d'article est-il si effroyable? R: Citer en fin d'article Q: Quelle est la chose la plus désagréable sur les groupes de news?
Dans ce cas, il ne faut pas être restrictif et mettre un avertissement à chaque fois.
Y a-t-il un moyen pour savoir qui a lancé /bin/rm ? Si oui, on peut avoir une liste des applications en qui on a confiance. (On a, en particulier, confiance dans le système... )
-- R: Parce que ça renverse bêtement l'ordre naturel de lecture! Q: Mais pourquoi citer en fin d'article est-il si effroyable? R: Citer en fin d'article Q: Quelle est la chose la plus désagréable sur les groupes de news?
Dans ce cas, il ne faut pas être restrictif et mettre un avertissement à
chaque fois.
Y a-t-il un moyen pour savoir qui a lancé /bin/rm ? Si oui, on peut
avoir une liste des applications en qui on a confiance. (On a, en
particulier, confiance dans le système... )
--
R: Parce que ça renverse bêtement l'ordre naturel de lecture!
Q: Mais pourquoi citer en fin d'article est-il si effroyable?
R: Citer en fin d'article
Q: Quelle est la chose la plus désagréable sur les groupes de news?
Dans ce cas, il ne faut pas être restrictif et mettre un avertissement à chaque fois.
Y a-t-il un moyen pour savoir qui a lancé /bin/rm ? Si oui, on peut avoir une liste des applications en qui on a confiance. (On a, en particulier, confiance dans le système... )
-- R: Parce que ça renverse bêtement l'ordre naturel de lecture! Q: Mais pourquoi citer en fin d'article est-il si effroyable? R: Citer en fin d'article Q: Quelle est la chose la plus désagréable sur les groupes de news?
listes
Julien Salort wrote:
(On a, en particulier, confiance dans le système... )
Dangereux, ça. Une vraie crasse ne pourrait-elle pas dire "moi, je suis une partie de l'OS?
-- Olivier Goldberg, étudiant, macmaniaque, plongeur CMAS *** Pour le courrier personnel, remplacer dans le From: listes par olivier AIM/iChat: Nept47
Julien Salort <lists@juliensalort.org> wrote:
(On a, en
particulier, confiance dans le système... )
Dangereux, ça. Une vraie crasse ne pourrait-elle pas dire "moi, je suis
une partie de l'OS?
--
Olivier Goldberg, étudiant, macmaniaque, plongeur CMAS ***
Pour le courrier personnel, remplacer dans le From: listes par olivier
AIM/iChat: Nept47
Dans ce cas, il ne faut pas être restrictif et mettre un avertissement à chaque fois.
Y a-t-il un moyen pour savoir qui a lancé /bin/rm ? Si oui, on peut avoir une liste des applications en qui on a confiance. (On a, en particulier, confiance dans le système... )
Bon alors il faut expliquer un peu tout cela. "rm" est un exécutable unix qui peut être lancé par tout shell script, comme par exemple les shells de démarrage rc du système. Mais en plus de cela, la fonction "rm" a aussi un équivalent en tant qu'appel système : unlink. Tout programme peut donc faire la même chose que rm, sans appeler l'exécutable unix. Tout programme qui gère des fichiers appelle des fonctions pour créer et parfois supprimer des fichiers, alors tout programme peut potentiellement utiliser l'équivalent de "rm". Essayer de bidouiller l'exécutable rm ne sert ainsi pas à grand chose.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 22/05/04 9:40, dans <1ge6lgr.149ywcmrv10n4N%lists@juliensalort.org>,
« Julien Salort » <lists@juliensalort.org> a écrit :
Dans ce cas, il ne faut pas être restrictif et mettre un avertissement à
chaque fois.
Y a-t-il un moyen pour savoir qui a lancé /bin/rm ? Si oui, on peut
avoir une liste des applications en qui on a confiance. (On a, en
particulier, confiance dans le système... )
Bon alors il faut expliquer un peu tout cela. "rm" est un exécutable unix
qui peut être lancé par tout shell script, comme par exemple les shells de
démarrage rc du système. Mais en plus de cela, la fonction "rm" a aussi un
équivalent en tant qu'appel système : unlink. Tout programme peut donc faire
la même chose que rm, sans appeler l'exécutable unix. Tout programme qui
gère des fichiers appelle des fonctions pour créer et parfois supprimer des
fichiers, alors tout programme peut potentiellement utiliser l'équivalent de
"rm". Essayer de bidouiller l'exécutable rm ne sert ainsi pas à grand chose.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Dans ce cas, il ne faut pas être restrictif et mettre un avertissement à chaque fois.
Y a-t-il un moyen pour savoir qui a lancé /bin/rm ? Si oui, on peut avoir une liste des applications en qui on a confiance. (On a, en particulier, confiance dans le système... )
Bon alors il faut expliquer un peu tout cela. "rm" est un exécutable unix qui peut être lancé par tout shell script, comme par exemple les shells de démarrage rc du système. Mais en plus de cela, la fonction "rm" a aussi un équivalent en tant qu'appel système : unlink. Tout programme peut donc faire la même chose que rm, sans appeler l'exécutable unix. Tout programme qui gère des fichiers appelle des fonctions pour créer et parfois supprimer des fichiers, alors tout programme peut potentiellement utiliser l'équivalent de "rm". Essayer de bidouiller l'exécutable rm ne sert ainsi pas à grand chose.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Éric Lévénez
Le 22/05/04 9:40, dans <1ge6l98.vythba1p1do6gN%, « Julien Salort » a écrit :
Est-ce que unix accepterait que /bin/rm envoie et reçoive des AppleEvents ?
Pas sûr car "rm" doit pouvoir marcher avec un système minimum et pour les AppleEvents, je suppose qu'il faut un démon de lancé pour que cela marche.
Si oui, il suffit d'avoir une autre application, graphique elle, qui s'occupe d'ouvrir la boîte de dialogue.
Au boot, rm est beaucoup utilisé par le système. Il n'y a pas d'interface graphique à ce moment. De plus unix est multitâche et multiutilisateur, ainsi plusieurs utilisateurs peuvent utiliser "rm" en même temps, mais si la version actuelle de Mac OS X n'en accepte qu'un en mode Aqua (mais n en ssh, telnet, X11...)
Elle envoie alors la réponse (oui ou non) à rm par un autre AppleEvent.
Marchera pas. Il ne faut pas se focaliser sur rm.
Bien entendu, cela suppose qu'une session soit ouverte. Mais l'idée c'est de contrecarrer les chevaux de Troie « graphiques ».
Marchera pas. Cela supposerait que ces chevaux de Troie utilisent le programme "rm" alors qu'il y a l'appel système remove beaucoup plus rapide et qui ne lance pas un process en plus.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 22/05/04 9:40, dans <1ge6l98.vythba1p1do6gN%lists@juliensalort.org>,
« Julien Salort » <lists@juliensalort.org> a écrit :
Est-ce que unix accepterait que /bin/rm envoie et reçoive des
AppleEvents ?
Pas sûr car "rm" doit pouvoir marcher avec un système minimum et pour les
AppleEvents, je suppose qu'il faut un démon de lancé pour que cela marche.
Si oui, il suffit d'avoir une autre application, graphique elle, qui
s'occupe d'ouvrir la boîte de dialogue.
Au boot, rm est beaucoup utilisé par le système. Il n'y a pas d'interface
graphique à ce moment. De plus unix est multitâche et multiutilisateur,
ainsi plusieurs utilisateurs peuvent utiliser "rm" en même temps, mais si la
version actuelle de Mac OS X n'en accepte qu'un en mode Aqua (mais n en ssh,
telnet, X11...)
Elle envoie alors la réponse
(oui ou non) à rm par un autre AppleEvent.
Marchera pas. Il ne faut pas se focaliser sur rm.
Bien entendu, cela suppose qu'une session soit ouverte. Mais l'idée
c'est de contrecarrer les chevaux de Troie « graphiques ».
Marchera pas. Cela supposerait que ces chevaux de Troie utilisent le
programme "rm" alors qu'il y a l'appel système remove beaucoup plus rapide
et qui ne lance pas un process en plus.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 22/05/04 9:40, dans <1ge6l98.vythba1p1do6gN%, « Julien Salort » a écrit :
Est-ce que unix accepterait que /bin/rm envoie et reçoive des AppleEvents ?
Pas sûr car "rm" doit pouvoir marcher avec un système minimum et pour les AppleEvents, je suppose qu'il faut un démon de lancé pour que cela marche.
Si oui, il suffit d'avoir une autre application, graphique elle, qui s'occupe d'ouvrir la boîte de dialogue.
Au boot, rm est beaucoup utilisé par le système. Il n'y a pas d'interface graphique à ce moment. De plus unix est multitâche et multiutilisateur, ainsi plusieurs utilisateurs peuvent utiliser "rm" en même temps, mais si la version actuelle de Mac OS X n'en accepte qu'un en mode Aqua (mais n en ssh, telnet, X11...)
Elle envoie alors la réponse (oui ou non) à rm par un autre AppleEvent.
Marchera pas. Il ne faut pas se focaliser sur rm.
Bien entendu, cela suppose qu'une session soit ouverte. Mais l'idée c'est de contrecarrer les chevaux de Troie « graphiques ».
Marchera pas. Cela supposerait que ces chevaux de Troie utilisent le programme "rm" alors qu'il y a l'appel système remove beaucoup plus rapide et qui ne lance pas un process en plus.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
