Seberapa jauh Anda akan mendapatkan dengan perintah 'rm -rf /'?

200

Saya sering bertanya-tanya seberapa jauh sistem akan benar-benar dapatkan jika Anda menjalankannya rm -rf /. Saya ragu OS akan dapat menghapus dirinya sendiri (?)

Pertanyaan Bonus : Setelah perintah dieksekusi, apakah rmsudah dihapus sendiri?

Pembaruan: Saya telah menguji ini di beberapa distribusi unix utama menggunakan VirtualBox dan jawabannya menggambarkan apa yang terjadi. Jika diberi parameter yang benar, rm akan menghapus setiap bit data fisik pada disk. Namun, saya mengalami beberapa masalah saat menggunakan versi rm selain dari GNU. Sebagai contoh, saya percaya BusyBox memiliki versi mereka sendiri dan tidak memungkinkan Anda menghapus sebanyak mungkin.

Pertanyaan ini adalah Pertanyaan Pengguna Super Minggu Ini .
Baca entri blog 7 Juli 2011 untuk perincian lebih lanjut atau kirimkan Pertanyaan Anda Minggu Ini.

unix  filesystems  rm 
— n0pe
sumber
8
Lucu sekali Anda menanyakan pertanyaan ini. Saya baru saja menjawab pertanyaan rm -f lain di forum lain dan mulai mengingat artikel yang saya baca beberapa waktu lalu. Untungnya saya menyimpannya untuk saat-saat seperti ini: THE horor klasik Unix selain fakta bahwa itu menarik untuk melihat sejauh mana itu akan pergi ... Saya pikir itu adalah artikel yang ditulis dengan sangat baik dan umumnya dibaca dengan baik!
— akseli
3
Saya baru saja mencoba sudo rm -rf /di linux tinycore / microcore dan tampaknya OS melindungi beberapa direktori (/ sys dan lainnya) agar tidak dihapus.
— n0pe
47
Saya mencoba rm -f /bin/rmsekali. Sayangnya, itu berhasil, dan saya menghabiskan satu jam berikutnya untuk mendapatkan versi yang tepat rmdari GNU coreutils.
— Tupai
17
Tunggu sebentar, saya akan coba ...
— Martijn Courteaux
38
Saya melakukan ini di toko apel sepanjang waktu
— eggie5

Jawaban:

188

Jika Anda memiliki rmdari GNU coreutils (kemungkinan besar jika itu adalah distro Linux biasa), rm -rf /akan ditolak oleh perlindungan bawaan (menurut manual dan Wikipedia, belum pernah mencobanya).

Anda dapat mengganti perlindungan ini dengan --no-preserve-root. rmkemudian akan menghapus semua yang mungkin bisa, tanpa berhenti setelah berusaha menghapus setiap file. Tentu saja itu tidak akan menghapus sistem file virtual seperti /procdan /sys, tapi itu tidak relevan - itu akan menghapus semua yang ada di disk Anda.

Setelah perintah selesai, disk Anda akan dihapus, termasuk OS. Kernel dan proses saat ini akan terus berjalan dari memori, tetapi banyak proses akan mati karena mereka gagal mengakses beberapa file. OS akan gagal mem-boot lain kali.

— Ambroz Bizjak
sumber
67
Persis apa yang saya cari. Sekarang gunakan kekuatan ini UNTUK MENGAMBIL DI DUNIA.
— n0pe
34
+1 terutama untuk --no-preserve-rootkarena itu biasanya tidak disebutkan.
— Matěj G.
22
@MaxMackie, perlu dicatat bahwa peretas sangat cepat menemukan ini sebagai hal paling tidak berguna yang bisa mereka lakukan kepada pengguna. Itu menghancurkan semua data yang dapat digunakan untuk mendapatkan uang tunai, dan mencegah peretas dari mengeksploitasi mesin lebih lanjut. Seperti kucing dengan serangga, Anda tidak ingin membunuhnya, Anda hanya ingin bermain dengannya sebentar karena itu menyenangkan.
— zzzzBov
5
Untuk menjawab pertanyaan OP lainnya, ya rm akan menghapus sendiri. Sangat mungkin untuk mengubah atau menghapus yang dapat dieksekusi bahkan ketika ada instance yang sedang dijalankan. Ini akan terus berjalan juga, dan tidak akan terpengaruh oleh perubahan.
— thomasrutter
3
Saya ingin menyebutkan "chmod -R user: user *" di /, karena ini juga merupakan kesalahan rekursif dan mahal. Saya melakukannya sekali, dan sudah setengah jalan / pulang pada saat saya bisa menggugurkan. / bin / boot / etc / dev dimiliki. Untungnya server terus berjalan sementara saya menghabiskan beberapa jam berikutnya secara manual dan mengatur ulang kepemilikan dari sistem referensi. Namun, tidak ada orang lain yang bisa menggunakan su atau sudo sesudahnya. Akhirnya menemukan bahwa / bin / su tidak lagi memiliki bit set setuid-nya. Perhatikan masa depan: chowning / bin / su me-reset bit setuid-nya!
— Andy Lee Robinson
22

Menyiapkan VM dan mencoba bersenang-senang?

Ini akan berjalan cukup jauh ... jika Anda menggunakan gui, Anda mungkin akan senang melihat hal-hal menurun lebih terlihat. (Ikon pada menu berhenti memuat dll.)

Jika Anda membiarkannya pergi, OS akan cukup banyak di luar pemulihan meskipun Anda mungkin bisa mendapatkan kembali beberapa data dengan mudah.

Either way, Anda akan ingin melakukan instal ulang OS.

— PriceChild
sumber
7
Saya bahkan tidak berpikir untuk mencobanya di VM. Akan coba sekarang! ooo ini menyenangkan.
— n0pe
40
Secara keliru menulis perintah ke Terminal sistem host
— slhck
1
Lihat artikel yang saya posting. "Kisah Horor Unix Klasik!"
— akseli
1
Saya sedang bekerja sekarang dan tidak punya waktu untuk menginstal penuh distro populer (ubuntu / slack / suse / fedora). Jika orang lain dapat mengkloning file disk VM dan mencobanya untuk kita, itu akan luar biasa.
— n0pe
2
Dengan Amazon EC2 harus cepat untuk menjalankan salah satu AMI mereka yang sudah memiliki linux diinstal dan pergi ...
— David d C e Freitas
11

Ya, mencobanya di http://bellard.org/jslinux/ menghasilkan:

rm: tidak dapat menghapus '/ dev / pts': Perangkat atau sumber daya sibuk
rm: tidak dapat menghapus '/ dev': Direktori tidak kosong
rm: tidak dapat menghapus '/ proc / swaps': Operasi tidak diizinkan
rm: bisa 't remove' / proc / kallsyms ': Operasi tidak diizinkan
rm: tidak dapat menghapus' / proc / dma ': Operasi tidak diizinkan

Entri SNIP 881

rm: tidak dapat menghapus '/ proc / 149 / oom_adj': Izin ditolak
rm: tidak dapat menghapus '/ proc / 149': Operasi tidak diizinkan
rm: tidak dapat menghapus '/ proc': Perangkat atau sumber daya sibuk
rm: tidak dapat menghapus '/ tmp': Perangkat atau sumber daya sibuk
: tidak dapat menghapus '/': Perangkat atau sumber daya sibuk

— Halo71
sumber
1
Ya saya juga mendapatkan kesalahan / peringatan itu. Apakah standar ini menurut Anda?
— n0pe
5
/ proc, / sys, terkadang / dev, dan setiap mountpoints adalah properti dari sistem operasi dan tidak dapat dihapus.
— pjc50
1
Bersamaan dengan @ pcj50, itu bukan file pada hard disk, jadi "menghapus" itu tidak berarti.
— CarlF
7

Saya ingat ini sedang dikunyah pada alt.sysadmin.recoveryhari-hari dahulu kala, ketika tidak ada hal seperti itu /proc, dan /devhanya direktori biasa yang berisi entri untuk sekelompok inode yang tidak biasa ...

... tetapi, pada beberapa varian Unix (ingatan saya adalah HP-UX, tapi itu bisa saja salah), Anda tidak dapat menghapus entri direktori terakhir untuk program yang sedang berjalan. (Perpustakaan bersama? Apa itu?)

Pada sistem seperti itu, jika Anda memulai satu dalam mode pemeliharaan (jadi tidak ada yang berjalan kecuali shell Anda, bahkan init, dan tidak ada sistem file sekunder yang dipasang) dan melakukannya exec /bin/rm -rf /, Anda akan dibiarkan dengan sistem file root yang benar-benar kosong kecuali itu /bindan /bin/rmakan bertahan.

Para penghuni biara setan menakutkan menganggap ini pantas dan pantas.

— zwol
sumber
4

rm -rf / tidak boleh diizinkan pada implementasi terbaru karena telah disarankan itu melanggar standar POSIX:

" rm -rf /" perlindungan di blog Oracle

Bagaimanapun, pada akhirnya, kami mendapatkan spec yang dimodifikasi, dan Solaris 10 memiliki (sejak build 36) versi / usr / bin / rm (/ bin adalah sym-link ke / usr / bin pada Solaris) dan / usr / xpg4 / bin / rm yang berperilaku demikian:

[28] /bin/rm -rf /
rm of / is not allowed
[29]
— Jlliagre
sumber
2
"menunjukkan bahwa jika seseorang mencoba untuk menghapus" / "secara rekursif, seseorang pada akhirnya akan berusaha untuk menghapus" .. "dan". ", dan bahwa semua yang kita lakukan adalah memungkinkan rm untuk menentukan sebelumnya secara heuristik. Hebatnya, mereka membeli itu ! "- eh, bukankah itu tidak diizinkan menghapus direktori apa pun ? Spesifikasi aktual hanya melarang .. dan. dalam argumen baris perintah yang sebenarnya, itu tidak mengatakan apa-apa tentang apa yang Anda "pada akhirnya berusaha untuk menghapus"
— Random832
1
Mengapa ia melarang menghapus direktori apa pun? Direktori root adalah satu-satunya yang terkait di sini dan menghapusnya jelas menyiratkan menghapus "." dan "..", apa pun direktori saat ini. Akal sehat tidak dilarang dalam interpretasi standar.
— jlliagre
1
Argumentasi itu sangat jenius.
— Nate CK
Standar menentukan bahwa rm tidak diizinkan untuk melanjutkan jika argumen memiliki string "." atau ".." sebagai komponen basename. Anda tidak dapat menghapus /foo/..bahkan jika Anda tidak masuk /foo. Itu tidak menentukan bahwa Anda tidak diperbolehkan untuk menghapus direktori saat ini (misalnya rm -r `pwd`) atau orang tua dari direktori saat ini.
— Acak 832
2
Memang, saya salah paham dengan pernyataan itu dan Anda benar. Mudah-mudahan, orang-orang standar menerima perilaku yang lebih pintar sebagai patuh pada standar. Menghapus sebagian besar jika tidak semua sistem file akan dengan cepat membuat OS tidak memenuhi standar.
— jlliagre
3

Satu hal yang saya lihat tidak dibuat oleh orang lain: file yang saat ini terbuka (misalnya rm itu sendiri), bahkan jika dihapus, tidak akan benar-benar hilang dari drive sampai ditutup.

— CarlF
sumber
Itu benar, karena mereka dimuat dalam memori, kan?
— n0pe
Saya tidak yakin apakah itu aman untuk diasumsikan; kernel bisa saja memuat file yang dihapus ke dalam memori dan segera menghapusnya di disk, dan simpan salinan di dalam memori ini sampai file terbuka (mis. sampai rm sedang berjalan).
— Ambroz Bizjak
Saya tidak berspekulasi. Jika suatu program sedang berjalan, menghapusnya tidak menghapusnya di kotak Linux saya, setidaknya. (Pikiran Anda, saya belum menguji ini dalam, oh, beberapa tahun.)
— CarlF
4
rm akan menghapus dirinya sendiri dari fs - program ini benar-benar dimuat dalam memori, bukan file
— warren
4
@ MaxMackie: bukan karena mereka dimuat dalam memori, tetapi karena referensi file terbuka memiliki kekuatan yang sama dengan hard-link (yaitu jika file memiliki setidaknya satu hard link, itu tidak akan dihapus dari disk).
— Lie Ryan
1

Karena pernah mencobanya sekali (pada server yang membuatku kesal), login sebagai root, di terminal, Anda akan kehilangan hampir semuanya. Satu-satunya hal yang tidak akan dihapus hanya proses yang penting untuk OS.

— Anarko_Bizounours
sumber
12
"[tidak terhapus] hanya proses yang penting untuk OS" - oh, jangan khawatir. Tidak seperti Windows, Linux akan dengan senang hati menghapus apa pun, bahkan jika file tersebut kritis terhadap OS dan sedang digunakan. /boot, /sbin, /etc, /bin, /vmlinuz? Bam, pergi. Selamat mencoba booting tanpa itu - pada kenyataannya, semoga berhasil melakukan apa saja setelah penghapusan selesai.
— Piskvor
Jika saya ingat ada beberapa file yang tidak dihapus, dan saya membiarkan linux saya berjalan lebih dari 4 jam. Tapi tetap saja, senang mengetahui apa yang terjadi, seperti melakukan chmod 777 / * -fR;)
— Anarko_Bizounours
3
"chmod 777 / * -fR" - Itu seharusnya membuat sistem sangat tidak aman, meskipun sangat user-friendly.
— Bart van Heukelom
1
@ BartvanHeukelom, beberapa alat akan melakukan swa-uji cepat, atau diuji oleh sistem untuk kepemilikan dan izin yang tepat dan menolak untuk bertindak jika tidak dikonfigurasi.
— killermist
1
chmod -fR 777 /berbahaya karena mematikan bit setuid dan setgid.
— G-Man
1

Seberapa jauh Anda bisa mendapatkan, itu pada dasarnya tergantung pada distribusi Unix / Linux tertentu.

Tetapi untuk menjawab pertanyaan dasar Anda, ya - rmperintah akan dihapus bersamanya serta perintah standar lainnya di /bindan folder lainnya.

Ini adalah tes sederhana yang telah saya lakukan di Linux Ubuntu 15.04 menggunakan VM.

  1. Inisialisasi mesin virtual melalui vagrant:

    vagrant init ubuntu/vivid64 && vagrant up --provider virtualbox && vagrant ssh

  2. Kemudian ketika Anda mencoba untuk menghapus semua file dengan cara standar, itu tidak memungkinkan Anda:

    vagrant@vagrant-ubuntu-vivid-64:~$ sudo rm -fr /
rm: it is dangerous to operate recursively on '/'
rm: use --no-preserve-root to override this failsafe

  3. Jadi mari kita coba --no-preserve-root. Selalu periksa ulang Anda masuk mesin virtual (jadi Anda mengalami vagrant@vagrant-ubuntu-vivid-64:~$), kemudian jalankan (jangan coba itu di rumah):

    vagrant@vagrant-ubuntu-vivid-64:~$ sudo rm -vfr --no-preserve-root /
removed directory: '/lost+found'
removed directory: '/opt'
removed '/bin/nc'
removed '/bin/less'
removed '/bin/wdctl'
removed '/bin/nano'
...
removed '/bin/rmdir'
removed '/bin/sh'
removed '/bin/rm'
...
removed directory: '/bin'
removed directory: '/usr/games'
removed '/usr/bin/byobu-launcher-install'
removed '/usr/bin/ipcmk'
removed '/usr/bin/sum'
removed directory: '/usr/bin'
removed '/usr/lib/gcc/x86_64-linux-gnu/4.9.2'
removed '/usr/lib/gcc/x86_64-linux-gnu/5.0.1'
removed directory: '/usr/lib/gcc/x86_64-linux-gnu/5'
removed '/usr/lib/gcc/x86_64-linux-gnu/4.9/libquadmath.so'
removed '/usr/lib/gcc/x86_64-linux-gnu/4.9/libgomp.so'
...
removed directory: '/run/initramfs'
removed directory: '/media'
rm: cannot remove '/proc/fb': Operation not permitted
rm: cannot remove '/proc/fs/ext4/sda1/options': Operation not permitted
...
removed '/vmlinuz'
removed '/boot/config-3.19.0-23-generic'
removed '/boot/grub/grubenv'
...
removed directory: '/boot'
removed '/lib64/ld-linux-x86-64.so.2'
rm: cannot remove '/dev/hugepages': Device or resource busy
rm: cannot remove '/dev/mqueue': Device or resource busy
rm: cannot remove '/dev/shm': Device or resource busy
removed '/dev/vcsa7'
...
removed '/dev/mem'
removed '/dev/rfkill'
removed '/dev/vga_arbiter'
...
rm: cannot remove '/sys/fs/ecryptfs/version': Operation not permitted
removed directory: '/etc'
removed directory: '/mnt'
removed '/vagrant/.vagrant/machines/default/virtualbox/action_provision'
removed '/vagrant/.vagrant/machines/default/virtualbox/action_set_name'
removed '/vagrant/.vagrant/machines/default/virtualbox/creator_uid'
removed '/vagrant/.vagrant/machines/default/virtualbox/id'
removed '/vagrant/.vagrant/machines/default/virtualbox/index_uuid'
removed '/vagrant/.vagrant/machines/default/virtualbox/private_key'
removed '/vagrant/.vagrant/machines/default/virtualbox/synced_folders'
removed directory: '/vagrant/.vagrant/machines/default/virtualbox'
removed directory: '/vagrant/.vagrant/machines/default'
removed directory: '/vagrant/.vagrant/machines'
removed directory: '/vagrant/.vagrant'
removed '/vagrant/Vagrantfile'
rm: cannot remove '/vagrant': Device or resource busy

    Setelah itu ia kembali ke shell prompt seperti tidak ada yang baru saja terjadi, tetapi Anda tidak dapat menjalankan perintah apa pun selain beberapa built in dan kill, sehingga Anda dapat menyelesaikan pekerjaan Anda dan membunuh sesi Anda :)

    Sebagai contoh:

    $ rm
rm: command not found
$ kill
kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill -l [sigspec]
$ which kill
-bash: /usr/bin/which: No such file or directory
$ kill -9 $$
Connection to 127.0.0.1 closed.

Jadi itu cukup menghapus semuanya, termasuk rm, lsdan semua perintah lain, tetapi Anda tetap masuk. Ada beberapa folder khusus yang tidak dihapus seperti beberapa perangkat dari /dev, /procatau /sysyang bukan direktori / file biasa, tetapi itu pseudo-filesystem yang menyediakan antarmuka untuk memproses dan data kernel.

Jika Anda tidak memiliki Vagrant atau Linux, Anda dapat bermain dengan beberapa emulator JavaScript Linux x86 .

Jika Anda tertarik pada kemungkinan pulih dari bencana seperti itu, periksa:

— kenorb
sumber
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.