260 meneos
2392 clics
Ejecutar el comando “rm -rf /” en un Linux arrancado con UEFI puede dejar inservible el equipo de forma permanente [ENG]
Ejecutar el comando “rm -rf /” en un Linux que use UEFI puede dejar inservible el equipo de forma permanente. Cabe decir que borrar de forma recursiva todos los archivos y directorios no es recomendable. Pero si se hace en un sistema en el que la variables de EFI están montadas en modo lectura-escritura en “/sys”, puede llevar a inutilizar la implementación de UEFI, lo que llevaría a tener un sistema completamente inservible. [El error se reporta en el GitHub de ‘systemd’: github.com/systemd/systemd/issues/2402 ]
|
comentarios cerrados
-- Rich Cook
Premio
como saltáis algunos....
Si, no tenia ni que poner el /, ni tampoco le dio al tab.
Y todo que si que si que si...
Edit: Perdón "sudo rm -rf /"
También conozco a otro que con un editor de disco, cambió en el sector de arranque la palaba "WINDOWS" por su nombre. Tuvo que sacar el disco duro y ponerlo en otro equipo para volver a ponerlo bien.
Así que, sí, me lo creo.
-- Rich Cook
A mi me pasó una vez estudiando mecanografía en la consola.
news.softpedia.com/news/Steam-for-Linux-Can-Delete-Home-Folder-with-rm
De todas formas casi todas estas cosas pasan por no trabajar con linux (o cualquier Unix) como debe trabajarse. Es decir, importándote todo una mierda y sin tomar precauciones ni leer lo que sale por pantalla. Más o menos es como conducir un coche y pensar que puedes prepararte un chocolate con churros porque tienes las rodillas libres para mover el volante.
Eso nos pasa a todos. A todos. Y mejor antes que después.
Imagina ahora que eres "creativo" y tienes un directorio llamado /sus/ y te equivocas al teclear la orden para borrarlo porque la "u" y la "y" estan juntas en el QWERTY de mierda...
Pero en un mundo en el que la última moda son containers corriendo microservicios, irremediablemente vamos de cabeza a que una mierda como systemd se implemente en todas partes, para que así en el microcontainer todo se pueda gestionar fácilmente.
Y al que todavía ande con servidores, pues a ese que le den morcilla (o que se pase a OpenBSD, que es un buen momento).
# rm -rf /
rm: it is dangerous to operate recursively on ‘/’
rm: use --no-preserve-root to override this failsafe
La UEFI no vive en el disco duro junto al sistema operativo, sino en memoria ROM solo de lectura, y la configuración y actualizaciones de esta, se almacenan en la memoria CMOS, que va alimentada por la pila de la placa base.
Esto que quiere decir? Que te puedes cargar la parte del sistema operativo encargada de arrancar desde UEFI, y te veras obligado a reinstalar el sistema operativo, pero en ningún caso supone un "perma-brick" como ellos dicen.
El problema puede ser en todo caso, que algún fabricante no monte la UEFI sobre memoria ROM, y permita sobrescribirla, pero esto no es lo habitual.
¿te refieres a algo así?
rm -rf / tmp
Eso si puede pasar, solo es poner un espacio por error donde no debías. Combinaciones donde puedes borrar / o * (estando en /) cambiando solo un espacio hay a patadas
Todavía hace no mucho lance un rm -rf que por error se comia todo *
(Algo como rm -rf ~/folder/anotherFolder/* me salio rm -rf ~/folder/anotherFolder/ *). Vale que no era root, pero aun asi, como root o sudo si que lanzas rm -rf a veces
El cachondo te dejaba, y no pasaba nada, todo seguía funcionanod. Hasta que reiniciabas y te decía que no encontraba al sistema
Si borras todo el sistema de archivos afecta al directorio /sys/firmware/efi/efivars
De todas formas, no se puede hacer un rm -rf / desde hace mucho tiempo, porque rm da error, como ha dicho #47. Pero el problema está ahí, lo de menos es como se haga.
$ rm -rf /*
Y ya me cuentas
"Matthew says with about 20 lines of code on Windows, you can cause the same havoc."
rm -rf ./
Imagínate que se te olvida o te falla el punto.
"sudo su -"
y a continuación, todos los comandos.
Yo ya trabajo con Debian 8 en servidores y usando gestión de servicios al 100% usando systemd y sigo sin comprender el odio que le teneis algunos. De hecho ahora mismo facilita mucho más el control del sistema aparte de que ahora está integrado con el kernel. El journal que tiene es simplemente fantástico y no el síndrome de diógenes que generaba SysVinit que te volvias hasta loco.
rm -rf . /
eso también funciona... pero no borra sólo el directorio actual...
Más o menos por ahí van las mayores quejas sobre la implementación de systemd.
rm -rf *
Ejecutado como root y desde el raíz.
Lo gracioso es que el terminal SSH siguió funcionando, aunque me quedé casi sin comandos ni para hacer el shutdown final. Si luego arrancaba o no, ya sería cosa de preguntarle al siguiente usuario...
En otro Ubuntu 14.04:
root@archivos:~# ls -lisa /sys
total 4
1 0 dr-xr-xr-x 13 root root 0 feb 1 20:08 .
2 4 drwxr-xr-x 22 root root 4096 ene 24 06:09 ..
Ta vez no es UEFI, pero /sys (.) está sin permisos W y en /etc/fstab no figura como punto de montaje nada relacionado, puede que haya algo que desconozco al respecto.
Incluso con el warning que comenta #47, puedo tener un motivo legitimo para querer borrar todos los ficheros de / pero no soy consciente que borrando /sys puedo dañar la placa. Y hay formas de lanzar esto sin que aparezca el warning:
Pongamos este ejemplo:
mkdir /tmp/chroot/sys
mount -o bind /sys /tmp/chroot/sys (o cualquier otra variante para replicar sys para el chroot)
chroot /tmp/chroot
... do stuff
exit (exit the chroot)
rm -rf /tmp/chroot
Esto parece seguro, pero si no me equivoco, podríamos acabar dañando la placa (igual no pasa al borrar los ficheros de /tmp/chroot/sys, pero al ser un bind, imagino que si
Los script para borrar instalaciones/archivos temporales salen almacenar el path en una variable, y a veces por error esa variable puede estar en blanco (o mal escrita). Asi un "rm -rf /<path>" se convierte en un "rm -rf /", durante la carrera de informática a toda nuestra clase le paso una vez con un makefile del profesor (mas concretamente fue un rm -rf ./<variable en blanco>) que nos ventilo todo el codigo.
También pasa a veces cuando estas usando muchos "rm -rf /<lo que sea>" (para borrar temporales tras experimentos, por ejemplo) y sin querer se presiona la tecla intro mientras estas editando el path en consola. O metes un espacio en blanco sin querer.
#10 Eso también lo he visto en persona, y mas de una vez.
sudo shred -n 10 -u /sys/firmware/efi/efivars
rm -rf /$VAR y... Var era nula
Systemd es horrible simeplemente porque tira a la basura toda la lógica de los sistemas Unix, reinventa la rueda, la reinventa MAL, introduce varios órdenes de complejidad innecesaria en algo que no debería tenerla y, de paso, añade con ello miles de puertas y agujeros en lo que antes era simple, sencillo y seguro.
Systemd es una aberración, así de claro. Que haga "más fácil" una o dos cosas (no veo en qué puede ser "más fácil" gestionar servicios de una máquina con systemd, la verdad, aunque tampoco soy sysadmin... ) no significa que sea un buen sustituto a los anteriores inits ni mucho menos "algo que necesitábamos", como te lo quiere vender el Poettering quien, por cierto además, es un puto maleducado de mierda y un insolente que va por las listas de correo de desarrolladores hablándole a la gente como si estuviera en el Menéame o el Barrapunto y a veces hasta insultando o diciéndole a desarrolladores de sistemas que llevan toda la vida programando que "no tienen ni idea", literalmente.
Los sistemas de tipo Unix están diseñados separando claramente el userspace del kernelspace y este tío ha arrejuntado todo en un mondongo que en ocasiones ni siquiera es capaz de explicar con qué motivo ni por qué. Se dedica a cacarear por ahí que "ahora todo es más fácil" y cuando se le hacen preguntas comprometidas acerca de las brechas de seguridad que pueden haber con tal o cual, se limita a dar la callada por respuesta o a decir que "ya te lo miro".