Sur Arch, le principal problème est généralement entre la chaise et le clavier. Et si tu casses sans arrêt ton Arch, interroge-toi sur tes propres pratiques :
Si tu utilises l'option --force en routine, il y a un problème.
Si tu utilises l'option --force dans n'importe quel contexte, il y a probablement un problème.
Si tu utilises l'option --sucre de yaourt pour tes mises à jour, il y a un problème vu que c'est un alias de (entre autres) --force.
Mets archlinux.org (ou même .fr) dans tes flux RSS et oublie-le. Chez moi, il est dans mes flux RSS, 9 matins sur 10 il n'a rien de nouveau et je le vois en un coup d’œil en lisant le dernier XKCD, un jour sur 10 il y a une intervention manuelle requise et là encore, 3 fois sur 4 elle ne me concerne pas. Quand une intervention manuelle est requise, elle est tellement détaillée qu'il est difficile de se planter.
Honnêtement, en 3 ans d'utilisation d'Arch, j'ai eu 2 cassages complets. Un était dû à la bronsonisation de mon disque dur (j'avais un backup), l'autre à une ISO corrompue lors de la réinstall (ma faute, j'aurais dû vérifier le checksum). Au final, j'ai retéléchargé une archive propre et ça s'est installé en 20 minutes, lecture de la doc comprise (ok je triche un peu, je l'avais déjà lue une première fois pour installer mon ISO corrompue).
Bon après, c'est vrai que c'est facile de casser son Arch. En root, si on suit pas la doc ou qu'on fait n'importe quoi, on a vite fait de casser un truc. D'où l'intérêt de lire les bonnes pratiques et d'y coller. Arch est relativement stable, à l'utilisateur près.
Ça, ce sont les sources. Le mouton que tu veux est dedans.
En fait, ça crée un nouveau fichier nommé ls avec comme contenu l'unique ligne de code entre guillemets, du coup, quand on appellera la commande ls, ça aura pour seul effet d'afficher le contenu du fichier cat /challenge/binary/binary1/.passwd. Pourquoi on fait ça ? Je ne le sais pas, ça ne semble pas permettre une élévation de droits en soi. Peut-être que ça sert à contourner une limitation autre, mais dans ce cas autant appeler directement cat. Quoi qu'il en soit, ça ne change pas ma conclusion : n'exécute pas ces commandes (ou dans une machine virtuelle jetable :P).
(je voulais éditer mon commentaire mais pas eu le temps, d'où l'auto-réponse)
Ça, ce sont les sources. Le mouton que tu veux est dedans.
Je vais faire court : n'exécute pas ces commandes, ça pue le soft malveillant.
rm –rf ./ls
Ça supprime le fichier ls dans le répertoire courant. Si tu te trouves dans /bin, ls est un binaire essentiel, que tu appelles dans tous les cas où tu veux lister les fichiers d'un répertoire (y compris dans un paquet de scripts shell que tu n'as pas écrits toi-même). Si tu n'es pas dans /bin, ça ne trouvera pas le fichier et ça te retournera une erreur.
On lit le fichier /challenge/binary/binary1/.passwd et on colle son contenu dans un nouveau fichier appelé ls, qui se situe précisément à l'endroit où a été supprimé le fichier ls précédent. Pourquoi on fait ça ? En effet, on pourrait tout à fait, en théorie, modifier le fichier sans le supprimer avant. Sauf que c'est une modification du fichier et qu'on n'a pas les droits pour ce faire sans être root. Alors que si on supprime un fichier appartenant à root, rm affichera simplement une demande de confirmation, qu'on force via l'utilisation de -f à la ligne précédente. Ainsi, on a remplacé un binaire très fréquemment utilisé, protégé par le système de droits, par notre binaire à nous, en contournant le système de droits.
chmod+x ./ls
On a notre binaire, mais il n'est pas exécutable. Qu'à celà ne tienne ! On le rend exécutable. Comme on a créé le binaire nous-même, on en est propriétaire : on peut modifier les droits dessus. Tout le monde peut donc désormais exécuter le binaire pourri qu'on a collé sur notre disque, et pire : tout le monde l'appellera de fait quand il croira appeler la commande ls, commande innocente s'il en est.
cd ~
pwd
On retourne dans notre dossier /home. On ne remonte pas d'un cran : on va dans le répertoire personnel de l'utilisateur courant. pwd sert à vérifier qu'on est dans le /home de l'utilisateur courant, si on en doutait.
./binary1
On exécute binary1. Rien que cette ligne devrait te mettre la puce à l'oreille : tu es en présence d'un programme exécutable, dont tu ne sais rien. Cette ligne l'exécute, tout simplement. Ce que fait binary1 ? Je n'en sais strictement rien, c'est un binaire. Mais je n'irais pas le tester.
Ça, ce sont les sources. Le mouton que tu veux est dedans.
[^] # Re: Rolling release et Chakra Linux
Posté par Liorel . En réponse au journal Une idée de distribution Linux. Évalué à -1.
Sur Arch, le principal problème est généralement entre la chaise et le clavier. Et si tu casses sans arrêt ton Arch, interroge-toi sur tes propres pratiques :
--forceen routine, il y a un problème.--forcedans n'importe quel contexte, il y a probablement un problème.--sucrede yaourt pour tes mises à jour, il y a un problème vu que c'est un alias de (entre autres)--force.Honnêtement, en 3 ans d'utilisation d'Arch, j'ai eu 2 cassages complets. Un était dû à la bronsonisation de mon disque dur (j'avais un backup), l'autre à une ISO corrompue lors de la réinstall (ma faute, j'aurais dû vérifier le checksum). Au final, j'ai retéléchargé une archive propre et ça s'est installé en 20 minutes, lecture de la doc comprise (ok je triche un peu, je l'avais déjà lue une première fois pour installer mon ISO corrompue).
Bon après, c'est vrai que c'est facile de casser son Arch. En root, si on suit pas la doc ou qu'on fait n'importe quoi, on a vite fait de casser un truc. D'où l'intérêt de lire les bonnes pratiques et d'y coller. Arch est relativement stable, à l'utilisateur près.
Ça, ce sont les sources. Le mouton que tu veux est dedans.
[^] # Re: N'exécute pas ces commandes
Posté par Liorel . En réponse au message questions sur differentes commandes. Évalué à 3.
Je me suis planté dans l'interprétation de la ligne
En fait, ça crée un nouveau fichier nommé
lsavec comme contenu l'unique ligne de code entre guillemets, du coup, quand on appellera la commandels, ça aura pour seul effet d'afficher le contenu du fichiercat /challenge/binary/binary1/.passwd. Pourquoi on fait ça ? Je ne le sais pas, ça ne semble pas permettre une élévation de droits en soi. Peut-être que ça sert à contourner une limitation autre, mais dans ce cas autant appeler directementcat. Quoi qu'il en soit, ça ne change pas ma conclusion : n'exécute pas ces commandes (ou dans une machine virtuelle jetable :P).(je voulais éditer mon commentaire mais pas eu le temps, d'où l'auto-réponse)
Ça, ce sont les sources. Le mouton que tu veux est dedans.
[^] # N'exécute pas ces commandes
Posté par Liorel . En réponse au message questions sur differentes commandes. Évalué à 5.
Je vais faire court : n'exécute pas ces commandes, ça pue le soft malveillant.
Ça supprime le fichier
lsdans le répertoire courant. Si tu te trouves dans/bin,lsest un binaire essentiel, que tu appelles dans tous les cas où tu veux lister les fichiers d'un répertoire (y compris dans un paquet de scripts shell que tu n'as pas écrits toi-même). Si tu n'es pas dans/bin, ça ne trouvera pas le fichier et ça te retournera une erreur.On lit le fichier
/challenge/binary/binary1/.passwdet on colle son contenu dans un nouveau fichier appeléls, qui se situe précisément à l'endroit où a été supprimé le fichierlsprécédent. Pourquoi on fait ça ? En effet, on pourrait tout à fait, en théorie, modifier le fichier sans le supprimer avant. Sauf que c'est une modification du fichier et qu'on n'a pas les droits pour ce faire sans être root. Alors que si on supprime un fichier appartenant à root,rmaffichera simplement une demande de confirmation, qu'on force via l'utilisation de -f à la ligne précédente. Ainsi, on a remplacé un binaire très fréquemment utilisé, protégé par le système de droits, par notre binaire à nous, en contournant le système de droits.On a notre binaire, mais il n'est pas exécutable. Qu'à celà ne tienne ! On le rend exécutable. Comme on a créé le binaire nous-même, on en est propriétaire : on peut modifier les droits dessus. Tout le monde peut donc désormais exécuter le binaire pourri qu'on a collé sur notre disque, et pire : tout le monde l'appellera de fait quand il croira appeler la commande
ls, commande innocente s'il en est.On retourne dans notre dossier /home. On ne remonte pas d'un cran : on va dans le répertoire personnel de l'utilisateur courant.
pwdsert à vérifier qu'on est dans le /home de l'utilisateur courant, si on en doutait.On exécute
binary1. Rien que cette ligne devrait te mettre la puce à l'oreille : tu es en présence d'un programme exécutable, dont tu ne sais rien. Cette ligne l'exécute, tout simplement. Ce que faitbinary1? Je n'en sais strictement rien, c'est un binaire. Mais je n'irais pas le tester.Ça, ce sont les sources. Le mouton que tu veux est dedans.