web-dev-qa-db-fra.com

Pourquoi le déplacement de répertoires vers / dev / null est-il dangereux?

En essayant de déplacer un répertoire test_dir vers /dev/null, je reçois le message

mv: cannot overwrite non-directory ‘/dev/null’ with directory ‘test_dir/’

Alors pourquoi les gens disent-ils "N'exécutez pas la commande Sudo mv ~ /dev/null, elle déplacera votre répertoire personnel dans un trou?"

Lien

Mais /home est aussi un répertoire.

command-linefilesystem
26
Avinash Raj

Parce que les gens assument. J'étais une de ces personnes jusqu'à ce que je teste . Il est facile de comprendre pourquoi les gens supposent ... Cela semble dangereux ...

... mais vous ne pouvez pas réellement déplacer des éléments vers /dev/null - C'est un fichier spécial qui absorbe uniquement les redirections (et les envoie dans le néant). Si vous essayez de déplacer un répertoire vers celui-ci, le système de fichiers exploserait verbalement sur votre visage et si vous essayez de déplacer un fichier dessus, vous finirez probablement par le remplacer.

Le premier lien traitera des répertoires, mais voici un test séparé juste pour le remplacer par un fichier. Comme Rmano le souligne dans les commentaires, il s’agit probablement d’une chose à ne pas faire sans la surveillance d’un adulte. Il y a un risque impliqué.

$ echo "this is my file" > test
$ cat test
this is my file

$ Sudo mv test /dev/null
$ cat /dev/null
this is my file

# Fix this!
$ Sudo rm /dev/null
$ Sudo mknod -m 0666 /dev/null c 1 3
38
Oli

/dev/null est juste un fichier, c'est un fichier "caractère spécial" mais ce n'est pas moins lié par les règles que les fichiers doivent suivre. Cela étant dit, vous ne pourrez jamais exécuter cette commande:

$ mv ~ /dev/null

La commande mvn'autorisera pas cela car vous déplacez un répertoire dans un fichier, cela n'a pas de sens contextuellement et mvle sait.

Exemple

$ mkdir dir
$ touch afile
$ mv dir afile
mv: cannot overwrite non-directory ‘afile’ with directory ‘dir’

Vous ne pouvez pas copier non plus sur /dev/null, étant donné qu'il s'agit d'un fichier de caractères, si vous essayez de copier un fichier normal dessus.

$ cp ~/bzip2_1.0.6-4_AMD64.deb /dev/null
$ ls -l |grep null
crw-rw-rw-  1 root root        1,   3 Mar 16 14:25 null

La seule chose que vous puissiez faire avec ce fichier est de copier mvdans un autre fichier ou de le supprimer.

$ mv /path/to/afile /dev/null

Après cette commande, /dev/null est un fichier normal. L'effet le plus dangereux de ce changement est que /dev/null est supposé jamais générer toutes les données. Par conséquent, un certain nombre de scripts Shell suppose que

`... < /dev/null`

est équivalent à dire "rien". Si cette hypothèse est brisée, des données aléatoires peuvent être insérées (ainsi, les données écrites par le dernier processus dans `/ dev/null ') insérées dans des fichiers système répartis dans tout le système, ce qui pourrait conduire à un système totalement inutilisable et irrécupérable.

18
slm

Vous pouvez écrire des fichiers ou d’autres flux d’entrée dans /dev/null, mais pas dans des répertoires. Si vous essayez de déplacer un répertoire vers /dev/null, une erreur sera signalée car /dev/null n'est pas un répertoire mais un fichier.

Toutefois, puisque vous souhaitez expérimenter avec /dev/null, vous devez d’abord connaître les conséquences du déplacement d’un fichier pour écraser /dev/null et savoir comment remédier à cette situation:

Comme suggéré par @ Rmano dans cette réponse à cette question, afin d'expérimenter avec /dev/null, nous devrions plutôt en créer une copie puis faire notre expérimentation. Créons donc /tmp/null et utilisons-le à des fins d'expérimentation:

Sudo mknod -m 0666 /tmp/null c 1 3

Désormais, /tmp/null est notre /dev/null à toutes fins utiles:

Créons un test_file et un test_dir dans un répertoire appelé ask_ubuntu.

$ mkdir ask_ubuntu
$ cd ask_ubuntu
$ touch test_file
$ mkdir test_dir
$ echo "Let us test if we can recover our test_file." > test_file

Ce qui suit montre le contenu du répertoire ask_ubuntu:

$ ls -la
total 12
drwxr-xr-x 3 aditya aditya 4096 Mar 18 17:10 .
drwxr-xr-x 4 aditya aditya 4096 Mar 18 17:10 ..
drwxr-xr-x 2 aditya aditya 4096 Mar 18 17:10 test_dir
-rw-r--r-- 1 aditya aditya    0 Mar 18 17:10 test_file

Maintenant, essayez de déplacer notre test_file dans /tmp/null et de voir le contenu de ask_ubuntu:

$ Sudo mv test_file /tmp/null   # This succeeds
$ ls -la
total 12
drwxr-xr-x 3 aditya aditya 4096 Mar 18 17:12 .
drwxr-xr-x 4 aditya aditya 4096 Mar 18 17:10 ..
drwxr-xr-x 2 aditya aditya 4096 Mar 18 17:10 test_dir

La commande réussit et test_file n'est plus disponible. Maintenant, essayez de déplacer test_dir vers /tmp/null qui ne réussit pas:

$ Sudo mv test_dir/ /tmp/null 
mv: cannot overwrite non-directory ‘/tmp/null’ with directory ‘test_dir/’

test_dir est toujours présent dans ask_ubuntu:

$ ls -la
total 12
drwxr-xr-x 3 aditya aditya 4096 Mar 18 17:12 .
drwxr-xr-x 4 aditya aditya 4096 Mar 18 17:10 ..
drwxr-xr-x 2 aditya aditya 4096 Mar 18 17:10 test_dir

Voyons maintenant si nous pouvons récupérer notre test_file à partir de /tmp/null:

$ cat /tmp/null
Let us test if we can recover our test_file.

Donc, il est toujours là et /tmp/null qui était un fichier spécial a été écrasé et il est devenu comme tout autre fichier normal. Nous pouvons récupérer notre fichier en copiant /tmp/null comme n'importe quel autre fichier:

$ cp /tmp/null our_test_file
$ cat our_test_file
Let us test if we can recover our test_file.

Fichier récupéré.

Remarque:

Si vous n'avez pas créé /tmp/null et essayé ces commandes directement à l'aide de /dev/null; assurez-vous de récupérer le fichier (si vous en avez besoin) en exécutant cp /dev/null our_test_file; et restaurez /dev/null aux fins pour lesquelles il existe sur notre système en lançant les commandes suivantes comme indiqué dans la question liée dès que possible:

$ Sudo rm /dev/null
$ Sudo mknod /dev/null c 1 3
$ Sudo chmod 666 /dev/null

Conclusion:

  • Donc, il est impossible de déplacer un répertoire vers /dev/null et il n’est donc pas question de récupérer le répertoire à partir de là.

  • En ce qui concerne les fichiers, si vous déplacez directement les fichiers vers /dev/null, vous pouvez toujours les récupérer comme indiqué ci-dessus. Cependant, il y a deux exceptions:

    1. Pendant la période où vous exécutez Sudo mv test_file /dev/null et cp /dev/null our_test_file, si un script racine du système l’écrase en exécutant echo "Whatever text the root script wants to send to /dev/null" > /dev/null (ou d’autres commandes similaires). Ensuite, nous n'avons pas de moyen facile de récupérer notre fichier.

    2. Si vous redémarrez le système entre l'exécution de ces deux commandes. /dev/null est recréé au démarrage, ainsi notre fichier est perdu lorsque nous éteignons l'ordinateur.

  • Mais si vous souhaitez récupérer des flux d'entrée tels que echo "Stream this line to /dev/null" > /dev/null, vous ne pouvez pas récupérer ce fichier, car /dev/null est un fichier spécial permettant de supprimer les fichiers et flux d'entrée non sollicités et, comme le mentionne l'article de Wikipedia, il ne fournit aucune donnée à un processus qui le lit. .

Référence: Article Wikipedia sur /dev/null

12
Aditya

Tout ce qui est envoyé à /dev/null est éliminé en silence. Si vous tapez:

echo "Hello World"

vous obtenez Hello World à l'écran. Si vous tapez:

echo "Hello World" >/dev/null

vous n'obtenez rien à l'écran.

Mais dans le cas de la commande move, la commande mv tente de remplacer le fichier/dev/null par le répertoire, ce qui n’est pas possible. Comme tout est un fichier sous Linux,/dev/null est un fichier. Un fichier spécial bien sûr (un fichier de périphérique), un fichier spécial permettant d’accéder à du matériel (comme des disques, des partitions, des cartes son, des ports série, ...). Dans le cas de/dev/null, celui-ci n'est lié à aucun matériel, les données qui lui sont envoyées sont donc ignorées. C'est pourquoi "ils" ont peut-être appelé cela un trou noir.

7
Benoit