Hi,
da wir uns ja gestern darüber unterhalten hatten wie sich "rm -rf /" verhält. Ich habe mal eine VM aufgesetzt und probiert(*):
------------------------
Debian GNU/Linux 11 debian tty1
Hint: Num Lock on
debian login: root Linux debian 5.10.0-16-amd64 #1 SMP Debian 5.10.12_-2 (2022-O_-23) x86_64
The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Thu Jul 28 17:44:44 CEST 2O22 on tty1 root@debian:~# rm -rf / rm: it is dangerous to operate recursively on '/' rm: use --no-preserve-root to override this failsafe root@debian:~#
----------------------
(*) Debian 11 via netinst, keine GUI, nur Basissystem. Läuft in VirtualBox. Screenshot per Virtualbox und dann durch gocr gejagt. Ich hoffe mal ich habe den Bildschirminhalt korrekt wiedergegeben, gocr hatte Probleme mit y, f und 7.
Wenn rm schon so nett bettelt, dann benutze ich natürlich diesen Parameter. Nach hunderten von Fehlern blieb das hier von der VM übrig:
----------------------
rm: cannot remove '/proc/402/attr/apparmor/current': Operation not permitted rm: cannot remove '/proc/402/attr/apparmor/prev': Operation not permitted rm: cannot remove '/proc/402/attr/apparmor/exec': Operation not permitted rm: cannot remove '/proc/402/wchan': Operation not permitted rm: cannot remove '/proc/402/stack': Operation not permitted rm: cannot remove '/proc/402/schedstat': Operation not permitted rm: cannot remove '/proc/402/cpuset': Operation not permitted rm: cannot remove '/proc/402/cgroup': Operation not permitted rm: cannot remove '/proc/402/cpu_resctrl_groups': Operation not permitted rm: cannot remove '/proc/402/oom_score': Operation not permitted rm: cannot remove '/proc/402/oom_adj': Operation not permitted rm: cannot remove '/proc/402/oom_score_adj': Operation not permitted rm: cannot remove '/proc/402/loginuid': Operation not permitted rm: cannot remove '/proc/402/sessionid': Operation not permitted rm: cannot remove '/proc/402/coredump_filter': Operation not permitted rm: cannot remove '/proc/402/io': Operation not permitted rm: cannot remove '/proc/402/uid_map': Operation not permitted rm: cannot remove '/proc/402/gid_map': Operation not permitted rm: cannot remove '/proc/402/projid_map': Operation not permitted rm: cannot remove '/proc/402/setgroups': Operation not permitted rm: cannot remove '/proc/402/timers': Operation not permitted rm: cannot remove '/proc/402/timerslack_ns': Operation not permitted rm: cannot remove '/proc/402/patch_state': Operation not permitted rm: cannot remove '/proc/402/arch_status': Operation not permitted rm: cannot remove '/dev/mqueue': Device or resource busy rm: cannot remove '/dev/hugepages': Device or resource busy rm: cannot remove '/dev/shm': Device or resource busy rm: cannot remove '/dev/pts/ptmx': Operation not permitted root@debian:~# ll -bash: ll: command not found root@debian:~# ls -l -bash: ls: command not found root@debian:~# cd /etc -bash: cd: /etc: No such file or directory root@debian:~# cd /tmp -bash: cd: /tmp: No such file or directory root@debian:~# halt -bash: halt: command not found root@debian:~#
----------------------------------
VBox sei Dank - snapshot restauriert und nochmal drauf hauen:
Das Kommando wird sogar ausgeführt wenn ich das als User aufrufe - nur bekomme ich dann haufenweise "Permission denied" bis rm mein Home-Directory findet...
Wie vermutet: Busybox hat keinerlei Bedenken gegen "rm -rf /" und braucht keine Spezialparameter.
Anders ausgedrückt: der Mercedes piepst kurz bevor man an die Garagen-Wand fährt, der Dacia fährt einfach dagegen ohne zu murren. Weder die teuren Alufelgen, noch die Nobel-Einfahrt mit Marmor-Split werden dich daran hindern. Auch die Garagenwand wird nicht einfach zur Seite springen, sondern stur stehen bleiben bis jemand genug Schwung hatte...
Konrad
Hi Konrad,
On Thu, Jul 28, 2022 at 18:42:25 +0200, Konrad Rosenbaum wrote:
root@debian:~# rm -rf / rm: it is dangerous to operate recursively on '/' rm: use --no-preserve-root to override this failsafe
Genau. So macht es das rm aus den coreutils, die ueblicherweise mit GNU-Erweiterungen angereichert sind.
Wie vermutet: Busybox hat keinerlei Bedenken gegen "rm -rf /" und braucht keine Spezialparameter.
Das ist das klassische Verhalten von Un*x-Kommandos: Kein Sicherheitsnetz, kein doppelter Boden. Man muss wissen, was man tut :)
Dann gab es gestern noch die etwas abenteuerliche Vermutung, der Kernel selbst wuerde die Aktionen von "rm -rf /" erkennen und abfangen. Das ist natuerlich nicht der Fall, allein schon weil sich die Aktionen auf verschiedene Syscalls verteilen:
openat(), getdents64(), unlinkat() bei coreutils-rm.
openat(), getdents64(), unlink(), rmdir() bei busybox-rm.
Gruss, Christian
Hoi,
root@debian:~# rm -rf / rm: it is dangerous to operate recursively on '/' rm: use --no-preserve-root to override this failsafe
Falls "rm -rf /" zu rabiat ist: Ebenfalls sehr bellebt und kann in einer Stressituation schonmal „passieren“: find /data/.* -delete Um dann festzustellen, dass „.." auch trifft. :)
Genau. So macht es das rm aus den coreutils, die ueblicherweise mit GNU-Erweiterungen angereichert sind.
Wie vermutet: Busybox hat keinerlei Bedenken gegen "rm -rf /" und braucht keine Spezialparameter.
Interessanterweise verhält sich rm mit .* anders. Ich bin mir aber sehr(!) sicher, dass es früher mal anders war.
rm -rf /data/.* rm: refusing to remove '.' or '..' directory: skipping '/data/.' rm: refusing to remove '.' or '..' directory: skipping '/data/..‘
Cheers,
Andreas
Hi,
Interessanterweise verhält sich rm mit .* anders. Ich bin mir aber sehr(!) sicher, dass es früher mal anders war.
für GNU rm wird da [1] von 1990/1991 gesprochen, gar so weit wird deine Erinnerung dann vielleicht doch nicht reichen? ;) Mglw. kennst du es aber von anderen Plattformen noch anders, auf denen das später oder vielleicht auch nie implementiert wurde. Seit 2017 ist das auch offiziell gefordertes Verhalten, mit . und .. doch bitteschön NICHTS zu machen.
Grüße Carsten
[1] https://unix.stackexchange.com/questions/90073/does-rm-ever-delete-the-paren...
lug-dd@mailman.schlittermann.de
-
Andreas Roth -
Carsten Weber -
Christian Perle -
Konrad Rosenbaum