Jak daleko zajdziesz za pomocą polecenia „rm -rf /”?

200

Często zastanawiałem się, jak daleko zajdzie system, jeśli uciekniesz rm -rf /. Wątpię, aby system operacyjny mógł się skasować (?)

Pytanie dodatkowe : Czy po wykonaniu polecenia zostanie ono rmusunięte?

Aktualizacja: Przetestowałem to w kilku głównych dystrybucjach uniksowych za pomocą VirtualBox, a odpowiedzi dokładnie opisują, co się dzieje. Jeśli podano prawidłowe parametry, rm usunie każdy fizyczny bit danych z dysku. Jednak napotkałem pewne problemy podczas korzystania z wersji rm innej niż GNU. Na przykład uważam, że BusyBox ma swoją własną wersję i nie pozwala na usunięcie tak dużo, jak to możliwe.

To pytanie było pytaniem superużytkownika tygodnia .
Przeczytaj wpis na blogu z 7 lipca 2011 r., Aby uzyskać więcej informacji, lub prześlij własne pytanie tygodnia.

unix  filesystems  rm 
— n0pe
źródło
8
To zabawne, że zadałeś to pytanie. Właśnie odpowiadałem na inne pytanie rm-f na innym forum i zacząłem pamiętać artykuł, który czytałem jakiś czas temu. Na szczęście uratował go do takich momentach: THE klasyczny Unix horror Poza tym, że jest to interesujące zobaczyć, jak daleko będzie ona iść ... Myślę, że to bardzo dobrze napisany artykuł i jest ogólnie dobry czytać!
— akseli
3
Właśnie próbowałem sudo rm -rf /na Linuksie Tinycore / Microcore i wydaje się, że system operacyjny chroni kilka katalogów (/ sys i innych) przed usunięciem.
— n0pe
47
Próbowałem rm -f /bin/rmraz. Niestety, zadziałało, a następną godzinę spędziłem na otrzymywaniu właściwej wersji rmback z GNU coreutils.
— squircle 20.07.11
17
Chwileczkę, spróbuję ...
— Martijn Courteaux,
38
Cały czas robię to w sklepie z
— jabłkami

Odpowiedzi:

188

Jeśli masz rmz GNU coreutils (najprawdopodobniej jeśli jest to zwykła dystrybucja Linuksa), rm -rf /zostanie odrzucone przez wbudowaną ochronę (według strony man i Wikipedii, nie próbowałem tego).

Możesz zastąpić tę ochronę za pomocą --no-preserve-root. rmusunie wszystko, co możliwe, bez zatrzymywania się po próbie usunięcia każdego pojedynczego pliku. Oczywiście nie usunie wirtualnych systemów plików takich jak /proci /sys, ale to nie ma znaczenia - usunie wszystko z dysku.

Po zakończeniu polecenia dysk zostanie wyczyszczony pusty, w tym system operacyjny. Jądro i bieżące procesy będą nadal działać z pamięci, ale wiele procesów umrze, ponieważ nie uzyskają dostępu do niektórych plików. System operacyjny nie uruchomi się następnym razem.

— Ambroz Bizjak
źródło
67
Dokładnie tego szukałem. Teraz użyj tej mocy, aby przejąć władzę nad światem.
— n0pe
34
+1 szczególnie, --no-preserve-rootponieważ zwykle o tym nie wspomina.
— Matěj G.,
22
@MaxMackie, warto zauważyć, że hakerzy bardzo szybko stwierdzili, że jest to najmniej przydatna rzecz, jaką mogą zrobić użytkownikowi. Niszczy wszelkie dane, które mogłyby zostać wykorzystane do zysków gotówkowych, i uniemożliwia hakerowi dalsze wykorzystywanie maszyny. Jak kot z owadem, nie chcesz go zabić, po prostu chcesz się nim pobawić przez chwilę, bo jest fajnie.
— zzzzBov
5
Aby odpowiedzieć na inne pytanie PO, tak rm usunie się. Można całkowicie zmodyfikować lub usunąć plik wykonywalny, nawet jeśli jest uruchomiona jego instancja. Będzie również działał i zmiana nie wpłynie na niego.
— thomasrutter
3
Chciałbym wspomnieć o „chmod -R użytkownik: użytkownik *” w /, ponieważ jest to również rekurencyjny i kosztowny błąd. Zrobiłem to raz i do połowy czasu przeszedłem do domu. / bin / boot / etc / dev były własnością. Na szczęście serwer działał, podczas gdy następne kilka godzin spędziłem ręcznie i resetowałem prawa własności z systemu referencyjnego. Jednak nikt inny nie mógł później używać su ani sudo. W końcu odkryłem, że / bin / su nie ma już ustawionego bitu setuid. Uwaga na przyszłość: chowning / bin / su resetuje swój bit setuid!
— Andy Lee Robinson
22

Skonfigurować maszynę wirtualną i spróbować zabawy?

Posunie się to daleko ... jeśli używasz GUI, możesz dobrze się bawić, zauważając, że rzeczy ulegają degradacji w sposób bardziej widoczny. (ikony w menu przestają się ładować itp.)

Jeśli pozwolisz temu odejść, system operacyjny będzie prawie niemożliwy do odzyskania, chociaż możesz łatwo odzyskać niektóre dane.

Tak czy inaczej, będziesz chciał ponownie zainstalować system operacyjny.

— PriceChild
źródło
7
Nawet nie pomyślałem o wypróbowaniu go na maszynie wirtualnej. Idę spróbować teraz! ooo to jest fajne.
— n0pe
40
Błędnie zapisuje polecenie w terminalu systemu hosta
— slhck
1
Sprawdź artykuł, który opublikowałem. „The Classic Unix Horror Story!”
— akseli
1
Jestem teraz w pracy i nie mam czasu, aby przejść pełną instalację popularnej dystrybucji (ubuntu / slack / suse / fedora). Gdyby ktokolwiek inny mógł sklonować plik dysku VM i wypróbować go dla nas, byłoby świetnie.
— n0pe
2
Z Amazon EC2 powinno być szybkie odpalenie jednego z AMI, które mają już zainstalowany system Linux i odpalenie ...
— David d C e Freitas
11

Cóż, wypróbowanie go na http://bellard.org/jslinux/ daje:

rm: nie można usunąć '/ dev / pts': Urządzenie lub zasób zajęty
rm: nie można usunąć '/ dev': katalog nie jest pusty
rm: nie można usunąć '/ proc / swaps': Operacja niedozwolona
rm: może 't remove' / proc / kallsyms ': Operacja niedozwolona
rm: nie można usunąć' / proc / dma ': Operacja niedozwolona

Wpisy SNIP 881

rm: nie można usunąć '/ proc / 149 / oom_adj': Brak uprawnień
rm: nie można usunąć '/ proc / 149': Operacja niedozwolona
rm: nie można usunąć '/ proc': Urządzenie lub zasoby zajęte
rm: nie można usunąć „/ tmp”: urządzenie lub zasób zajęty
rm: nie można usunąć ”/”: urządzenie lub zasób zajęty

— Cześć71
źródło
1
Tak, dostaję te błędy / ostrzeżenia. Czy uważasz, że to standard?
— n0pe
5
/ proc, / sys, czasami / dev i wszelkie punkty montowania są właściwościami systemu operacyjnego i nie można ich usunąć.
— pjc50,
1
W przeciwieństwie do @ pcj50, nie są to dosłownie pliki na dysku twardym, więc ich „usunięcie” nie ma znaczenia.
— CarlF,
7

Pamiętam, jak to było przeżuwane alt.sysadmin.recoverydawno temu, kiedy nie było czegoś takiego /proc, a /devbył zwykłym katalogiem zawierającym wpisy dla kilku niezwykłych i-węzłów ...

... ale na niektórych wariantów Uniksa (moja pamięć jest HP-UX, ale to może być całkowicie błędne), można nie usunąć ostatni wpis katalogu dla programu, który był uruchomiony. (Udostępniane biblioteki? Co to są?)

W takich systemach, jeśli rozpoczął na prowadzenie w trybie konserwacji (tak nic nie działa, ale swoją powłokę, nawet init, a żadne wtórne systemy plików zostały zamontowane) i nie exec /bin/rm -rf /można byłoby w lewo z całkowicie pustym systemie plików root wyjątkiem , że /bini /bin/rmbędzie przetrwać.

Mieszkańcy przerażającego diabelskiego klasztoru uważali to za właściwe i właściwe.

— zwol
źródło
4

rm -rf / nie powinno być dozwolone w najnowszych implementacjach, ponieważ sugerowano, że narusza standard POSIX:

rm -rf /ochrona „ ” na blogu Oracle

Ostatecznie zmodyfikowaliśmy specyfikację, a Solaris 10 ma (od wersji 36) wersję / usr / bin / rm (/ bin to sym-link do / usr / bin w Solarisie) i / usr / xpg4 / bin / rm, który zachowuje się w ten sposób:

[28] /bin/rm -rf /
rm of / is not allowed
[29]
— jlliagre
źródło
2
„wskazując, że jeśli ktoś spróbuje usunąć rekursywnie” / ”, ostatecznie spróbuje usunąć„ .. ”i„. ”, i że wszystko, co robimy, to pozwala rm wstępnie ustalić to heurystycznie. O dziwo, kupili to ! "- hmm, nie, że Disallow usunięcie dowolnego katalogu? Rzeczywista specyfikacja nie zezwala na ... w rzeczywistych argumentach wiersza poleceń nie mówi nic o tym, co „ostatecznie
— próbujesz
1
Dlaczego miałoby to uniemożliwiać usunięcie dowolnego katalogu? Jedynym problemem jest tutaj katalog główny, a usunięcie go oczywiście oznacza usunięcie „.” i „..”, niezależnie od bieżącego katalogu. W standardowej interpretacji zdrowy rozsądek nie jest zabroniony.
— jlliagre
1
Ta linia argumentacji jest czystym geniuszem.
— Nate CK,
Standard określa, że ​​rm nie może kontynuować, jeśli argument ma ciąg „.” lub „..” jako składnik basename. Nie możesz usunąć, /foo/..nawet jeśli Cię nie ma /foo. To ma nie określić, że nie wolno usunąć bieżący katalog (np rm -r `pwd`) lub rodzica aktualnego katalogu.
— Random832
2
Rzeczywiście, źle zrozumiałem to stwierdzenie i masz rację. Mamy nadzieję, że standardowi faceci zaakceptowali mądrzejsze zachowanie jako zgodne ze standardem. Usunięcie dużych części, jeśli nie cały system plików, sprawiłoby, że system operacyjny i tak byłby niezgodny ze standardem.
— jlliagre
3

Jeden punkt, którego nie widziałem, zrobiony przez nikogo innego: pliki, które są obecnie otwarte (np. Sam rm), nawet jeśli zostaną usunięte, nie znikną z napędu dopóki nie zostaną zamknięte.

— CarlF
źródło
Zgadza się, ponieważ są ładowane do pamięci, prawda?
— n0pe
Nie jestem pewien, czy można to bezpiecznie założyć; jądro bardzo dobrze może po prostu załadować usunięty plik do pamięci i natychmiast usunąć go z dysku i zachować tę kopię w pamięci do momentu otwarcia pliku (np. do uruchomienia rm).
— Ambroz Bizjak,
Nie spekuluję. Jeśli program jest uruchomiony, jego usunięcie nie usuwa go przynajmniej z moich komputerów z systemem Linux. (Pamiętaj, że nie testowałem tego przez kilka lat).
— CarlF
4
rm będzie usunąć się z fs - w programie jest całkowicie załadowany do pamięci, a nie pliku
— Warren
4
@MaxMackie: nie dlatego, że są załadowane do pamięci, ale dlatego, że otwarte odwołanie do pliku ma taką samą moc jak łącze twarde (tzn. Jeśli plik ma co najmniej jedno łącze twarde, nie zostanie usunięty z dysku).
— Lie Ryan,
1

Za wypróbowanie tego raz (na serwerze, co mnie wkurza), zalogowanego jako root, w terminalu stracisz prawie wszystko. Jedyną rzeczą, która nie zostanie usunięta, będzie tylko proces niezbędny dla systemu operacyjnego.

— Anarko_Bizounours
źródło
12
„[nie usunięty] tylko proces niezbędny dla systemu operacyjnego” - och, nie martw się. W przeciwieństwie do systemu Windows, Linux z przyjemnością usunie wszystko, nawet jeśli plik jest krytyczny dla systemu operacyjnego i jest w użyciu. /boot, /sbin, /etc, /bin, /vmlinuz? Bam, odszedł. Życzymy powodzenia podczas uruchamiania bez nich - w rzeczywistości powodzenia w robieniu czegokolwiek po zakończeniu usuwania.
— Piskvor
Jeśli pamiętam, był jakiś plik, który nie został usunięty, i pozwalałem linuxowi działać przez ponad 4 godziny. Ale dobrze jest wiedzieć, co się dzieje, na przykład wykonując chmod 777 / * -fR;)
— Anarko_Bizounours
3
„chmod 777 / * -fR” - To powinno uczynić system bardzo niepewnym, choć bardzo przyjaznym dla użytkownika.
— Bart van Heukelom
1
@BartvanHeukelom, niektóre narzędzia przeprowadzą szybki autotest lub zostaną przetestowane przez system pod kątem właściwej własności i uprawnień i odmawiają działania w przypadku nieprawidłowej konfiguracji.
— killermist
1
chmod -fR 777 /jest szkodliwy, ponieważ wyłącza bity setuid i setgid.
— G-Man,
1

Jak daleko można się dostać, zależy to w zasadzie od konkretnych dystrybucji Unix / Linux.

Ale aby odpowiedzieć na podstawowe pytanie, tak - rmpolecenie zostanie z nim usunięte, podobnie jak każde inne standardowe polecenie w /bini inne foldery.

Oto prosty test, który przeprowadziłem w systemie Linux Ubuntu 15.04 przy użyciu maszyny wirtualnej.

  1. Zainicjuj maszynę wirtualną poprzez vagrant:

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

  2. Następnie, gdy próbujesz usunąć wszystkie pliki w standardowy sposób, nie pozwala to na:

    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. Więc spróbujmy --no-preserve-root. Zawsze dwukrotnie sprawdź, czy jesteś zalogowany na maszynie wirtualnej (więc masz vagrant@vagrant-ubuntu-vivid-64:~$), a następnie uruchom (nie próbuj tego w domu):

    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

    Następnie wraca do wiersza poleceń, jakby nic się nie wydarzyło, ale nie możesz już wykonywać żadnych poleceń oprócz kilku wbudowanych i kill, dzięki czemu możesz zakończyć pracę i zabić sesję :)

    Na przykład:

    $ 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.

Więc to całkiem usunięto wszystko, w tym rm, lsi wszystkie inne polecenia, ale nadal jesteś zalogowany. Istnieją pewne specjalne foldery, które nie zostały usunięte, takich jak niektóre z urządzeń /dev, /proclub /sysktóre nie są regularne katalogów / plików, ale to jest pseudo-systemem plików zapewniając interfejsy do procesu oraz dane jądra.

Jeśli nie masz Vagrant lub Linux, możesz grać z niektórymi emulatorami JavaScript Linux x86 dla JavaScript .

Jeśli interesują Cię możliwości powrotu do zdrowia po takiej katastrofie, sprawdź:

— kenorb
źródło
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.