Ayant reçu un cable adéquat, je me suis lancé dans l'installation d'un
OpenBSD sur la SGI Octane.
A priori, tout s'est bien passé et j'arrive à booter en mode console, à
me connecter sur le compte root.
L'ennui c'est que, quand je veux l'interface graphique, qu'on lance avec
"startx", j'ai droit à une erreur avec "xauth". Sans doute des droits
d'accès ou un machine du genre. Je n'y connais rien sur ce système!
Si quelqu'un pouvait me guider pour compléter mon installation...
Voici le message d'erreur constaté:
http://gtello.pagesperso-orange.fr/temp_openbsd.jpg
L'ennui c'est que, quand je veux l'interface graphique, qu'on lance avec "startx", j'ai droit à une erreur avec "xauth". Sans doute des droits d'accès ou un machine du genre. Je n'y connais rien sur ce système!
Il n'y a pas encore de serveur X pour OpenBSD sur Octane.
L'ennui c'est que, quand je veux l'interface graphique, qu'on lance avec
"startx", j'ai droit à une erreur avec "xauth". Sans doute des droits
d'accès ou un machine du genre. Je n'y connais rien sur ce système!
Il n'y a pas encore de serveur X pour OpenBSD sur Octane.
L'ennui c'est que, quand je veux l'interface graphique, qu'on lance avec "startx", j'ai droit à une erreur avec "xauth". Sans doute des droits d'accès ou un machine du genre. Je n'y connais rien sur ce système!
Il n'y a pas encore de serveur X pour OpenBSD sur Octane.
Arachide
Le 22/03/2014 19:08, Miod Vallat a écrit :
L'ennui c'est que, quand je veux l'interface graphique, qu'on lance avec "startx", j'ai droit à une erreur avec "xauth". Sans doute des droits d'accès ou un machine du genre. Je n'y connais rien sur ce système!
Il n'y a pas encore de serveur X pour OpenBSD sur Octane.
Ceci explique cela...
Mais alors, il y a t-il un genre d'interface graphique quelconque?
Guillaume.
Le 22/03/2014 19:08, Miod Vallat a écrit :
L'ennui c'est que, quand je veux l'interface graphique, qu'on lance avec
"startx", j'ai droit à une erreur avec "xauth". Sans doute des droits
d'accès ou un machine du genre. Je n'y connais rien sur ce système!
Il n'y a pas encore de serveur X pour OpenBSD sur Octane.
Ceci explique cela...
Mais alors, il y a t-il un genre d'interface graphique quelconque?
L'ennui c'est que, quand je veux l'interface graphique, qu'on lance avec "startx", j'ai droit à une erreur avec "xauth". Sans doute des droits d'accès ou un machine du genre. Je n'y connais rien sur ce système!
Il n'y a pas encore de serveur X pour OpenBSD sur Octane.
Ceci explique cela...
Mais alors, il y a t-il un genre d'interface graphique quelconque?
Guillaume.
Arachide
Une autre question sur l'OpenBSD. J'ai un dossier /usr qui contient le dossier games qui contient des jeux. Le "hangman" par exemple (pendu).
Si je tape /usr/games/hangman, le jeu se lance bien.
Par contre, si je tape cd /usr/games (je vérifie bien avec ls que je suis dans le bon dossier), et que je tape hangman... il me dit qu'il ne trouve pas ce fichier !!!
même en étant dans le bon dossier, je suis obligé de taper tout le chemin d'accès.
Une idée?
Guillaume.
Une autre question sur l'OpenBSD.
J'ai un dossier /usr qui contient le dossier games qui contient des jeux.
Le "hangman" par exemple (pendu).
Si je tape /usr/games/hangman, le jeu se lance bien.
Par contre, si je tape cd /usr/games (je vérifie bien avec ls que je
suis dans le bon dossier), et que je tape hangman... il me dit qu'il ne
trouve pas ce fichier !!!
même en étant dans le bon dossier, je suis obligé de taper tout le
chemin d'accès.
Une autre question sur l'OpenBSD. J'ai un dossier /usr qui contient le dossier games qui contient des jeux. Le "hangman" par exemple (pendu).
Si je tape /usr/games/hangman, le jeu se lance bien.
Par contre, si je tape cd /usr/games (je vérifie bien avec ls que je suis dans le bon dossier), et que je tape hangman... il me dit qu'il ne trouve pas ce fichier !!!
même en étant dans le bon dossier, je suis obligé de taper tout le chemin d'accès.
Une idée?
Guillaume.
Tonton Th
On 2014-03-23, Arachide wrote:
Une idée?
:~$ cd /usr/games :/usr/games$ ./fortune In a museum in Havana, there are two skulls of Christopher Columbus, "one when he was a boy and one when he was a man." -- Mark Twain :/usr/games$
-- http://la.buvette.org/photos/communards/
On 2014-03-23, Arachide <houten.van@orange.fr> wrote:
Une idée?
tth@plop:~$ cd /usr/games
tth@plop:/usr/games$ ./fortune
In a museum in Havana, there are two skulls of Christopher Columbus,
"one when he was a boy and one when he was a man."
-- Mark Twain
tth@plop:/usr/games$
:~$ cd /usr/games :/usr/games$ ./fortune In a museum in Havana, there are two skulls of Christopher Columbus, "one when he was a boy and one when he was a man." -- Mark Twain :/usr/games$
-- http://la.buvette.org/photos/communards/
Th.A.C
Le 23/03/2014 10:32, Arachide a écrit :
Une autre question sur l'OpenBSD. J'ai un dossier /usr qui contient le dossier games qui contient des jeux. Le "hangman" par exemple (pendu).
Si je tape /usr/games/hangman, le jeu se lance bien.
Par contre, si je tape cd /usr/games (je vérifie bien avec ls que je suis dans le bon dossier), et que je tape hangman... il me dit qu'il ne trouve pas ce fichier !!!
même en étant dans le bon dossier, je suis obligé de taper tout le chemin d'accès.
Une idée?
Guillaume.
l'appli n'est pas dans le PATH (la liste des chemins ou le système va chercher l’application que tu lances).
si tu es dans le dossier de l'application, il suffit de rajouter ./ devant: ./hangman pour qu'il sache qu'il doit lancer l'application dans le dossier courant.
Ca fait parti des sécurité mises en place pour éviter de lancer une commande à la place d'une autre. Par exemple, mettre un programme ayant le même nom qu'une commande système dans le dossier de l'utilisateur (l'endroit ou l'utilisateur se trouve par défaut).
je n'ai jamais bossé sur OpenBSD, mais sous linux avec le bash (shell de commande), tu peux afficher les variables en tapant: set ou juste celle que tu veux: echo $PATH
Thierry
Le 23/03/2014 10:32, Arachide a écrit :
Une autre question sur l'OpenBSD.
J'ai un dossier /usr qui contient le dossier games qui contient des jeux.
Le "hangman" par exemple (pendu).
Si je tape /usr/games/hangman, le jeu se lance bien.
Par contre, si je tape cd /usr/games (je vérifie bien avec ls que je
suis dans le bon dossier), et que je tape hangman... il me dit qu'il ne
trouve pas ce fichier !!!
même en étant dans le bon dossier, je suis obligé de taper tout le
chemin d'accès.
Une idée?
Guillaume.
l'appli n'est pas dans le PATH (la liste des chemins ou le système va
chercher l’application que tu lances).
si tu es dans le dossier de l'application, il suffit de rajouter ./ devant:
./hangman
pour qu'il sache qu'il doit lancer l'application dans le dossier courant.
Ca fait parti des sécurité mises en place pour éviter de lancer une
commande à la place d'une autre.
Par exemple, mettre un programme ayant le même nom qu'une commande
système dans le dossier de l'utilisateur (l'endroit ou l'utilisateur se
trouve par défaut).
je n'ai jamais bossé sur OpenBSD, mais sous linux avec le bash (shell de
commande), tu peux afficher les variables en tapant:
set
ou juste celle que tu veux:
echo $PATH
Une autre question sur l'OpenBSD. J'ai un dossier /usr qui contient le dossier games qui contient des jeux. Le "hangman" par exemple (pendu).
Si je tape /usr/games/hangman, le jeu se lance bien.
Par contre, si je tape cd /usr/games (je vérifie bien avec ls que je suis dans le bon dossier), et que je tape hangman... il me dit qu'il ne trouve pas ce fichier !!!
même en étant dans le bon dossier, je suis obligé de taper tout le chemin d'accès.
Une idée?
Guillaume.
l'appli n'est pas dans le PATH (la liste des chemins ou le système va chercher l’application que tu lances).
si tu es dans le dossier de l'application, il suffit de rajouter ./ devant: ./hangman pour qu'il sache qu'il doit lancer l'application dans le dossier courant.
Ca fait parti des sécurité mises en place pour éviter de lancer une commande à la place d'une autre. Par exemple, mettre un programme ayant le même nom qu'une commande système dans le dossier de l'utilisateur (l'endroit ou l'utilisateur se trouve par défaut).
je n'ai jamais bossé sur OpenBSD, mais sous linux avec le bash (shell de commande), tu peux afficher les variables en tapant: set ou juste celle que tu veux: echo $PATH
Thierry
dodo
Arachide wrote:
Mais alors, il y a t-il un genre d'interface graphique quelconque?
Et ton install d'Irix ? :)
Arachide <houten.van@orange.fr> wrote:
Mais alors, il y a t-il un genre d'interface graphique quelconque?
Mais alors, il y a t-il un genre d'interface graphique quelconque?
Et ton install d'Irix ? :)
Gilbert VAISSIERE
Le 23/03/2014 10:32, Arachide a écrit :
Une autre question sur l'OpenBSD. J'ai un dossier /usr qui contient le dossier games qui contient des jeux. Le "hangman" par exemple (pendu).
Si je tape /usr/games/hangman, le jeu se lance bien.
Par contre, si je tape cd /usr/games (je vérifie bien avec ls que je suis dans le bon dossier), et que je tape hangman... il me dit qu'il ne trouve pas ce fichier !!!
même en étant dans le bon dossier, je suis obligé de taper tout le chemin d'accès.
Une idée?
Guillaume.
Bonjour,
Ce n'est pas vraiment une question sur OpenBSD, mais plutôt sur les bases Unix.
Dans la mesure où vous indiquiez dans un message précédent que vous n'êtes pas arrivé à lancer X sur ce serveur, il vous faudra vous habituer à utiliser le langage de commandes.
Il vous est donc INDISPENSABLE de vous familiariser avec UNIX tel qu'on l'utilisait au temps des terminaux texte (et encore de nos jours dans bien des cas). On trouve sur Internet profusion de documentations concernant Unix en général, et OpenBSD pour des points plus spécifiques liés à l'administration système.
Pour répondre plus précisément à votre question : Vous utilisez un interpréteur de commandes ou shell (csh ou équivalent pour les BSD en général, peut-être bash dans votre cas) C'est +/- l'équivalent de l'interpréteur de commandes DOS (en beaucoup plus riche)
Lorsque vous tapez un nom d'une commande : - soit vous indiquez le chemin (par exemple /usr/games/hangman) et l'interpréteur recherche la commande correspondante - soit vous indiquez juste le nom (par exemple hangman) et l'interpréteur recherche dans une liste de répertoires contenue dans la variable PATH
Généralement, le répertoire courant "." n'est pas présent dans le PATH Ce que vous pouvez vérifier en exécutant la commande : echo $PATH (qui signifie : affiche le contenu de la variable PATH). Vous y trouverez une liste de répertoires séparés par ":"
Donc lorsque vous êtes positionné dans le répertoire où se trouve la commande hangman (le programme hangman) : soit vous indiquez le chemin sous la forme : ./hangman soit vous indiquez le chemin absolu : /usr/games/hangman soit vous ajoutez le répertoire courant dans le PATH : PATH=$PATH:. ou, selon le shell, en utilisant "setenv" et, dans ce cas, vous pourrez ensuite taper juste : hangman
Si vous décidez d'ajouter le répertoire courant au PATH, il est fortement recommandé de l'ajouter à la fin et pas au début de la liste; vous trouverez des explications détaillées dans tout manuel de la sécurité sous Unix
Pour information, si vous avez besoin d'aide sur les commandes Unix, vous pouvez utiliser la commande "man", ou "info" si cette dernière commande est présente sur votre système. Exemples : man csh man bash info hangman
Dernier point particulièrement important pour les débutants (pour les autres aussi d'ailleurs) : - créez un compte "standard" (sans droit d'administrateur) - travaillez le plus possible sous ce compte - n'utilisez le compte "root" que lorsque c'est STRICTEMENT indispensable Les bonnes habitudes se prennent le plus tôt possible
Bonne lecture des documentations UNIX et bonne pratique. Il existe de nombreux forums UNIX, dont, probablement, certains pour les débutants.
Gilbert VAISSIERE
Le 23/03/2014 10:32, Arachide a écrit :
Une autre question sur l'OpenBSD.
J'ai un dossier /usr qui contient le dossier games qui contient des jeux.
Le "hangman" par exemple (pendu).
Si je tape /usr/games/hangman, le jeu se lance bien.
Par contre, si je tape cd /usr/games (je vérifie bien avec ls que je
suis dans le bon dossier), et que je tape hangman... il me dit qu'il ne
trouve pas ce fichier !!!
même en étant dans le bon dossier, je suis obligé de taper tout le
chemin d'accès.
Une idée?
Guillaume.
Bonjour,
Ce n'est pas vraiment une question sur OpenBSD, mais plutôt sur les
bases Unix.
Dans la mesure où vous indiquiez dans un message précédent que vous
n'êtes pas arrivé à lancer X sur ce serveur, il vous faudra vous
habituer à utiliser le langage de commandes.
Il vous est donc INDISPENSABLE de vous familiariser avec UNIX tel qu'on
l'utilisait au temps des terminaux texte (et encore de nos jours dans
bien des cas).
On trouve sur Internet profusion de documentations concernant Unix en
général, et OpenBSD pour des points plus spécifiques liés à
l'administration système.
Pour répondre plus précisément à votre question :
Vous utilisez un interpréteur de commandes ou shell (csh ou équivalent
pour les BSD en général, peut-être bash dans votre cas)
C'est +/- l'équivalent de l'interpréteur de commandes DOS (en beaucoup
plus riche)
Lorsque vous tapez un nom d'une commande :
- soit vous indiquez le chemin (par exemple /usr/games/hangman) et
l'interpréteur recherche la commande correspondante
- soit vous indiquez juste le nom (par exemple hangman) et
l'interpréteur recherche dans une liste de répertoires contenue dans la
variable PATH
Généralement, le répertoire courant "." n'est pas présent dans le PATH
Ce que vous pouvez vérifier en exécutant la commande :
echo $PATH
(qui signifie : affiche le contenu de la variable PATH).
Vous y trouverez une liste de répertoires séparés par ":"
Donc lorsque vous êtes positionné dans le répertoire où se trouve la
commande hangman (le programme hangman) :
soit vous indiquez le chemin sous la forme :
./hangman
soit vous indiquez le chemin absolu :
/usr/games/hangman
soit vous ajoutez le répertoire courant dans le PATH :
PATH=$PATH:.
ou, selon le shell, en utilisant "setenv"
et, dans ce cas, vous pourrez ensuite taper juste :
hangman
Si vous décidez d'ajouter le répertoire courant au PATH, il est
fortement recommandé de l'ajouter à la fin et pas au début de la liste;
vous trouverez des explications détaillées dans tout manuel de la
sécurité sous Unix
Pour information, si vous avez besoin d'aide sur les commandes Unix,
vous pouvez utiliser la commande "man", ou "info" si cette dernière
commande est présente sur votre système.
Exemples :
man csh
man bash
info hangman
Dernier point particulièrement important pour les débutants (pour les
autres aussi d'ailleurs) :
- créez un compte "standard" (sans droit d'administrateur)
- travaillez le plus possible sous ce compte
- n'utilisez le compte "root" que lorsque c'est STRICTEMENT indispensable
Les bonnes habitudes se prennent le plus tôt possible
Bonne lecture des documentations UNIX et bonne pratique.
Il existe de nombreux forums UNIX, dont, probablement, certains pour les
débutants.
Une autre question sur l'OpenBSD. J'ai un dossier /usr qui contient le dossier games qui contient des jeux. Le "hangman" par exemple (pendu).
Si je tape /usr/games/hangman, le jeu se lance bien.
Par contre, si je tape cd /usr/games (je vérifie bien avec ls que je suis dans le bon dossier), et que je tape hangman... il me dit qu'il ne trouve pas ce fichier !!!
même en étant dans le bon dossier, je suis obligé de taper tout le chemin d'accès.
Une idée?
Guillaume.
Bonjour,
Ce n'est pas vraiment une question sur OpenBSD, mais plutôt sur les bases Unix.
Dans la mesure où vous indiquiez dans un message précédent que vous n'êtes pas arrivé à lancer X sur ce serveur, il vous faudra vous habituer à utiliser le langage de commandes.
Il vous est donc INDISPENSABLE de vous familiariser avec UNIX tel qu'on l'utilisait au temps des terminaux texte (et encore de nos jours dans bien des cas). On trouve sur Internet profusion de documentations concernant Unix en général, et OpenBSD pour des points plus spécifiques liés à l'administration système.
Pour répondre plus précisément à votre question : Vous utilisez un interpréteur de commandes ou shell (csh ou équivalent pour les BSD en général, peut-être bash dans votre cas) C'est +/- l'équivalent de l'interpréteur de commandes DOS (en beaucoup plus riche)
Lorsque vous tapez un nom d'une commande : - soit vous indiquez le chemin (par exemple /usr/games/hangman) et l'interpréteur recherche la commande correspondante - soit vous indiquez juste le nom (par exemple hangman) et l'interpréteur recherche dans une liste de répertoires contenue dans la variable PATH
Généralement, le répertoire courant "." n'est pas présent dans le PATH Ce que vous pouvez vérifier en exécutant la commande : echo $PATH (qui signifie : affiche le contenu de la variable PATH). Vous y trouverez une liste de répertoires séparés par ":"
Donc lorsque vous êtes positionné dans le répertoire où se trouve la commande hangman (le programme hangman) : soit vous indiquez le chemin sous la forme : ./hangman soit vous indiquez le chemin absolu : /usr/games/hangman soit vous ajoutez le répertoire courant dans le PATH : PATH=$PATH:. ou, selon le shell, en utilisant "setenv" et, dans ce cas, vous pourrez ensuite taper juste : hangman
Si vous décidez d'ajouter le répertoire courant au PATH, il est fortement recommandé de l'ajouter à la fin et pas au début de la liste; vous trouverez des explications détaillées dans tout manuel de la sécurité sous Unix
Pour information, si vous avez besoin d'aide sur les commandes Unix, vous pouvez utiliser la commande "man", ou "info" si cette dernière commande est présente sur votre système. Exemples : man csh man bash info hangman
Dernier point particulièrement important pour les débutants (pour les autres aussi d'ailleurs) : - créez un compte "standard" (sans droit d'administrateur) - travaillez le plus possible sous ce compte - n'utilisez le compte "root" que lorsque c'est STRICTEMENT indispensable Les bonnes habitudes se prennent le plus tôt possible
Bonne lecture des documentations UNIX et bonne pratique. Il existe de nombreux forums UNIX, dont, probablement, certains pour les débutants.
Gilbert VAISSIERE
Tonton Th
On 2014-03-23, Gilbert VAISSIERE wrote:
soit vous ajoutez le répertoire courant dans le PATH : PATH=$PATH:. ou, selon le shell, en utilisant "setenv"
Et paf le chien ! Bon, pour cet exemple, il y a une parade :)
~$ aptitude search sl i sl - Correct you if you type `sl' by mistake
Sur ce, je retourne valgrinder...
Bonjour,
Au risque d'être H.S. sur cette liste :
Il n'est pas certain que le débutant qui avait posé la question initiale en soit au point de créer ce genre de script pour se faire un croc en jambe tout seul. S'il a laissé un "ami" lui tendre ce piège, il vaudrait mieux qu'il se méfie de ses amis.
Mais il est parfaitement capable de taper tout seul : "rm toto *" au lieu de "rm toto*" Qui ne l'a jamais fait ?
Pour notre ami qui a posé la question initiale, explications sur le script /tmp/sl L'idée est que, si "." est dans le PATH, et si on tape, par erreur, la commande sl au lieu de ls (voir commande man ls) à partir d'un répertoire où se trouve une commande sl (en l’occurrence le script ci-dessus), le résultat sera : - suppression de tous les fichiers du répertoire courant (commande rm *) - exécution de la commande ls qu'on souhaitait exécuter Ce script piège (sl) peut avoir été déposé dans /tmp soit par quelqu'un de malveillant en attendant que quelqu'un tombe dans le piège, soit, volontairement pour en illustrer l'effet
Quelques idées de défense :
1) ne travailler sous le compte root que lorsque c'est strictement indispensable Dans votre exemple, étant donné que le script a été créé sous /tmp (ce qui facilite la vie du plaisantin qui aurait voulu l'y déposer), et qu'il est lancé depuis ce répertoire, il aurait, au pire, supprimé ses propres fichiers dans ce répertoire ce qui n'est pas, à priori, catastrophique On suppose, bien sûr, que les droits du répertoire /tmp sont restés à la valeur adéquate pour un répertoire temporaire
2) configurer des alias, notamment, pour les commandes "dangereuses" comme "rm", "mv", ... : aliaser "rm" par "rm -i" qui demande confirmation avant de supprimer
Comment rendre ce script plus dangereux : /bin/rm -rf /* 2>/dev/null au lieu de : rm *
Explications pour le débutant : - exécuter la commande de suppression (sans aliasing) : /bin/rm - en récursif depuis le répertoire racine -r /* - sans confirmer pour les fichiers ou répertoires protégés : -f - ni afficher de message d'erreur pour les fichiers ou répertoires non accessibles : 2>/dev/null Effet dévastateur, surtout si on exécute cette commande avec les droits de root Il ne reste plus qu'à redémarrer le serveur et réinstaller le système Mais on dépasse la question initiale
Pour ajouter une note d'humour concernant l'erreur de l'ordre des caractères dans les commandes (sl au lieu de ls) : ce qu'on disait autrefois à celui qui avait supprimé des fichiers par erreur : Tu as tapé : rm * annule en tapant : mr *
Le 23/03/2014 14:28, Tonton Th a écrit :
On 2014-03-23, Gilbert VAISSIERE <gilbert.vaissiere@online.fr> wrote:
soit vous ajoutez le répertoire courant dans le PATH :
PATH=$PATH:.
ou, selon le shell, en utilisant "setenv"
Et paf le chien !
Bon, pour cet exemple, il y a une parade :)
~$ aptitude search sl
i sl - Correct you if you type `sl' by mistake
Sur ce, je retourne valgrinder...
Bonjour,
Au risque d'être H.S. sur cette liste :
Il n'est pas certain que le débutant qui avait posé la question initiale
en soit au point de créer ce genre de script pour se faire un croc en
jambe tout seul.
S'il a laissé un "ami" lui tendre ce piège, il vaudrait mieux qu'il se
méfie de ses amis.
Mais il est parfaitement capable de taper tout seul :
"rm toto *" au lieu de "rm toto*"
Qui ne l'a jamais fait ?
Pour notre ami qui a posé la question initiale, explications sur le
script /tmp/sl
L'idée est que, si "." est dans le PATH, et si on tape, par erreur, la
commande sl au lieu de ls (voir commande man ls) à partir d'un
répertoire où se trouve une commande sl (en l’occurrence le script
ci-dessus), le résultat sera :
- suppression de tous les fichiers du répertoire courant (commande rm *)
- exécution de la commande ls qu'on souhaitait exécuter
Ce script piège (sl) peut avoir été déposé dans /tmp soit par quelqu'un
de malveillant en attendant que quelqu'un tombe dans le piège, soit,
volontairement pour en illustrer l'effet
Quelques idées de défense :
1)
ne travailler sous le compte root que lorsque c'est strictement
indispensable
Dans votre exemple, étant donné que le script a été créé sous /tmp (ce
qui facilite la vie du plaisantin qui aurait voulu l'y déposer), et
qu'il est lancé depuis ce répertoire, il aurait, au pire, supprimé ses
propres fichiers dans ce répertoire ce qui n'est pas, à priori,
catastrophique
On suppose, bien sûr, que les droits du répertoire /tmp sont restés à la
valeur adéquate pour un répertoire temporaire
2)
configurer des alias, notamment, pour les commandes "dangereuses" comme
"rm", "mv", ... : aliaser "rm" par "rm -i" qui demande confirmation
avant de supprimer
Comment rendre ce script plus dangereux :
/bin/rm -rf /* 2>/dev/null
au lieu de :
rm *
Explications pour le débutant :
- exécuter la commande de suppression (sans aliasing) : /bin/rm
- en récursif depuis le répertoire racine -r /*
- sans confirmer pour les fichiers ou répertoires protégés : -f
- ni afficher de message d'erreur pour les fichiers ou répertoires non
accessibles : 2>/dev/null
Effet dévastateur, surtout si on exécute cette commande avec les droits
de root
Il ne reste plus qu'à redémarrer le serveur et réinstaller le système
Mais on dépasse la question initiale
Pour ajouter une note d'humour concernant l'erreur de l'ordre des
caractères dans les commandes (sl au lieu de ls) : ce qu'on disait
autrefois à celui qui avait supprimé des fichiers par erreur :
Tu as tapé :
rm *
annule en tapant :
mr *
Et paf le chien ! Bon, pour cet exemple, il y a une parade :)
~$ aptitude search sl i sl - Correct you if you type `sl' by mistake
Sur ce, je retourne valgrinder...
Bonjour,
Au risque d'être H.S. sur cette liste :
Il n'est pas certain que le débutant qui avait posé la question initiale en soit au point de créer ce genre de script pour se faire un croc en jambe tout seul. S'il a laissé un "ami" lui tendre ce piège, il vaudrait mieux qu'il se méfie de ses amis.
Mais il est parfaitement capable de taper tout seul : "rm toto *" au lieu de "rm toto*" Qui ne l'a jamais fait ?
Pour notre ami qui a posé la question initiale, explications sur le script /tmp/sl L'idée est que, si "." est dans le PATH, et si on tape, par erreur, la commande sl au lieu de ls (voir commande man ls) à partir d'un répertoire où se trouve une commande sl (en l’occurrence le script ci-dessus), le résultat sera : - suppression de tous les fichiers du répertoire courant (commande rm *) - exécution de la commande ls qu'on souhaitait exécuter Ce script piège (sl) peut avoir été déposé dans /tmp soit par quelqu'un de malveillant en attendant que quelqu'un tombe dans le piège, soit, volontairement pour en illustrer l'effet
Quelques idées de défense :
1) ne travailler sous le compte root que lorsque c'est strictement indispensable Dans votre exemple, étant donné que le script a été créé sous /tmp (ce qui facilite la vie du plaisantin qui aurait voulu l'y déposer), et qu'il est lancé depuis ce répertoire, il aurait, au pire, supprimé ses propres fichiers dans ce répertoire ce qui n'est pas, à priori, catastrophique On suppose, bien sûr, que les droits du répertoire /tmp sont restés à la valeur adéquate pour un répertoire temporaire
2) configurer des alias, notamment, pour les commandes "dangereuses" comme "rm", "mv", ... : aliaser "rm" par "rm -i" qui demande confirmation avant de supprimer
Comment rendre ce script plus dangereux : /bin/rm -rf /* 2>/dev/null au lieu de : rm *
Explications pour le débutant : - exécuter la commande de suppression (sans aliasing) : /bin/rm - en récursif depuis le répertoire racine -r /* - sans confirmer pour les fichiers ou répertoires protégés : -f - ni afficher de message d'erreur pour les fichiers ou répertoires non accessibles : 2>/dev/null Effet dévastateur, surtout si on exécute cette commande avec les droits de root Il ne reste plus qu'à redémarrer le serveur et réinstaller le système Mais on dépasse la question initiale
Pour ajouter une note d'humour concernant l'erreur de l'ordre des caractères dans les commandes (sl au lieu de ls) : ce qu'on disait autrefois à celui qui avait supprimé des fichiers par erreur : Tu as tapé : rm * annule en tapant : mr *
Arachide
Le 23/03/2014 12:11, dodo a écrit :
Arachide wrote:
Mais alors, il y a t-il un genre d'interface graphique quelconque?
Et ton install d'Irix ? :)
Lors de l'installation (vraiment pas facile, il a fallu que je lise et relise le petit manuel en anglais), il me signalait plein de conflits et je devais choisir quoi installer ou désactiver... N'y connaissant rien, j'ai fait ça un peu au pif jusqu'à ce qu'il n'y ait plus de conflits. Ensuite, l'installation a commencé et a fini sur une erreur pas du tout explicite et machine bloquée...
Bref... Peut être que j'avais été trop gourmand en voulant installer une grosse partie des CD du pack. J'aurai pu me contenter du minimum...
Guillaume.
Le 23/03/2014 12:11, dodo a écrit :
Arachide <houten.van@orange.fr> wrote:
Mais alors, il y a t-il un genre d'interface graphique quelconque?
Et ton install d'Irix ? :)
Lors de l'installation (vraiment pas facile, il a fallu que je lise et
relise le petit manuel en anglais), il me signalait plein de conflits et
je devais choisir quoi installer ou désactiver... N'y connaissant rien,
j'ai fait ça un peu au pif jusqu'à ce qu'il n'y ait plus de conflits.
Ensuite, l'installation a commencé et a fini sur une erreur pas du tout
explicite et machine bloquée...
Bref... Peut être que j'avais été trop gourmand en voulant installer une
grosse partie des CD du pack. J'aurai pu me contenter du minimum...
Mais alors, il y a t-il un genre d'interface graphique quelconque?
Et ton install d'Irix ? :)
Lors de l'installation (vraiment pas facile, il a fallu que je lise et relise le petit manuel en anglais), il me signalait plein de conflits et je devais choisir quoi installer ou désactiver... N'y connaissant rien, j'ai fait ça un peu au pif jusqu'à ce qu'il n'y ait plus de conflits. Ensuite, l'installation a commencé et a fini sur une erreur pas du tout explicite et machine bloquée...
Bref... Peut être que j'avais été trop gourmand en voulant installer une grosse partie des CD du pack. J'aurai pu me contenter du minimum...
