¿Puedes usar Terminal para bloquear tu computadora?

48

Las personas que no entienden Terminal a menudo tienen miedo de usarlo por temor a que puedan estropear su comando y bloquear su computadora. Aquellos que conocen Terminal mejor saben que ese no es el caso, por lo general, Terminal solo generará un error. Pero, ¿hay realmente comandos que bloqueen su computadora?

ADVERTENCIA: podría perder datos si escribe estos o copiar y pegar, especialmente sudoy de rmcomandos.

DonielF
fuente
Un tipo borró accidentalmente todas las computadoras de su compañía en una sola línea, lo vi en este sitio hace un par de años, era falso pero, todavía podría suceder fácilmente. Voy a vincular si puedo encontrarlo.
Noah Cristino
77
La Terminal es solo una interfaz de línea de comandos para ejecutar programas. Es una alternativa a una interfaz gráfica de usuario . Puede ejecutar programas arbitrarios desde cualquiera de los dos. Su pregunta, por lo tanto, realmente no tiene mucho sentido; deberías preguntarte: ¿Puedes bloquear tu computadora ejecutando un programa?
jamesdlin
¿Qué quieres decir con "choque"? Los comandos que se ejecutan en el terminal a menudo pueden ser potentes y a menudo "harán lo que dices y no lo que quieres decir" sin preguntar, a diferencia de la mayoría de los comandos de la GUI de Mac OS X. Pero a menos que lo intentes intencionalmente , es poco probable que bloquees la máquina. (Sin embargo, puedo pensar en algunas maneras de hacerlo intencionalmente)
Josh
1
Pegar comandos desde la web puede ser muy peligroso . Independientemente de la posibilidad de colgar su máquina. Sin embargo, escribir comandos que entiendes al menos vagamente no debería ser peligroso. De lo contrario, hay muchas maneras de atornillar su computadora. Es como hacer clic en la configuración aleatoria del sistema en la GUI, pero en la GUI al menos las posibilidades son más limitadas. wrt el peligro de pegar comandos: el texto que ve visualmente copiado puede ser diferente del texto real copiado, por lo tanto, puede contener comandos maliciosos entremezclados.
akostadinov
@ иσαнcяişтiпσ Quizás serverfault.com/questions/769357/recovering-from-a-rm-rf
wythagoras

Respuestas:

51

Una forma de bloquear una computadora es ejecutar una llamada bomba de horquilla .

Puede ejecutarlo en un sistema unix mediante:

:(){ :|: & };:

Es un comando que generará procesos de forma recursiva hasta que el sistema operativo esté tan ocupado que ya no responda a ninguna acción.

Rick van Hal
fuente
49
@bunyaCloven si entiendo su comando correctamente, entonces es un comando para eliminar todas las carpetas sin preguntar , lo cual es muy peligroso si funciona . Desearía que escribieras un aviso de advertencia para eso.
Andrew T.
80
@AndrewT. Las personas no deberían simplemente escribir comandos aleatorios que encontraron en Internet de todas formas. (especialmente en un hilo llamado "¿puedes bloquear tu computadora a través de la terminal")
John Hamilton
34
El OP solicitó un bloqueo desde la terminal, no un borrado.
piersb
16
La bomba tenedor realmente hará un daño mínimo en Mac OS X, ya que tiene límites superiores para la cantidad de procesos.
GDP2
77
@bunyaCloven reemplaza el ;con un &y puedes eliminar todos los archivos y la bomba tenedor al mismo tiempo, ¡y ver qué rompe primero el sistema!
Muzer
41

No estoy seguro de lo que quiere decir sobre 'bloquear' la computadora: si lo reformula para decir 'dejar la computadora inutilizable', entonces sí. Ciertamente, todo lo que se necesita es un solo comando perdido: solo un momento en el que no estás pensando claramente en lo que estás haciendo, de manera similar a cuando hablas sin pensar, y el daño puede ser inmenso y casi inmediato. El ejemplo clásico:

$ sudo rm -rf /

Si deja que ese comando se ejecute solo por un segundo, eso puede borrar lo suficiente de su sistema para que no se pueda arrancar y posiblemente causar una pérdida de datos irreversible. No lo hagas

Harv
fuente
2
Y solo para compartir por qué quería aclarar la reformulación ... para 'bloquear' la computadora en el sentido tradicional, para que se bloquee, tendrías que darle a la CPU suficiente trabajo para que no pueda responder de manera oportuna a otros trabajos ... como actualizar los gráficos y mover el cursor, por ejemplo. Estoy seguro de que hay una manera de hacerlo desde la línea de comandos.
Harv
66
@DonielF -rsignifica eliminar recursivamente archivos en un directorio. -fsignifica "forzar" ya que no solicite confirmación, independientemente de los permisos de un archivo determinado. /es el directorio raíz del sistema de archivos, lo que significa que destruirá cualquier cosa, excepto algunos archivos especiales que no se comportan como archivos típicos. Además, tendrá dificultades para encontrar un comando breve que bloqueará su sistema sin permisos de administrador / root.
GDP2
11
Lo intenté hace rm -rf /un tiempo y rmdije que si desea eliminar la raíz, use tal y tal bandera. No se perdieron datos. Parece que ahora hay una protección de seguridad contra la ejecución a ciegas rm -rf /.
alexyorke
27
- no se ha requerido la bandera de raíz de preservación desde 2006 para que esto funcione según lo previsto
Encaitar
66
Aquí hay un caso del mundo real en el que esto realmente sucedió, rm -rf muy similar a uno legal, que salió muy mal: /
mgarciaisaia
30

Suponga que no sabe qué está haciendo e intentando hacer una copia de seguridad de algún disco duro

dd if=/dev/disk1 of=/dev/disk2 

Bueno, si los mezcla (cambie si y de), sobrescribirá los datos nuevos con datos antiguos, sin hacer preguntas.

Pueden ocurrir mezclas similares con las utilidades de archivo. Y francamente con la mayoría de las utilidades de línea de comandos.

Si desea un ejemplo de una mezcla de un carácter que bloqueará su sistema, eche un vistazo a este escenario: Desea mover todos los archivos del directorio actual a otro:

 mv -f ./* /path/to/other/dir

Aceptemos el hecho de que aprendió a usar ./para denotar el directorio actual. (Sí) Bueno, si omite el punto, comenzará a mover todos sus archivos. Incluidos los archivos de su sistema. Tienes suerte de que no sudaste esto. Pero si lees en alguna parte que con 'sudo -i' nunca más tendrás que escribir sudo, ahora estás conectado como root. Y ahora su sistema se está comiendo frente a sus propios ojos.

Pero nuevamente, creo que cosas como sobrescribir mis preciosos archivos de código con basura, porque confundí un personaje o porque mezclé el orden de los parámetros, es más problema.

Digamos que quiero ver el código de ensamblador que genera gcc:

gcc -S program.c > program.s

Supongamos que ya tengo un program.s y uso la finalización de TAB. Tengo prisa y olvido TAB dos veces:

gcc -S program.c > program.c

Ahora tengo el código ensamblador en mi program.c y ya no tengo código c. Lo cual es al menos un verdadero revés para algunos, pero para otros es un tiempo de inicio desde cero.

Creo que estos son los que causarán un "daño" real. Realmente no me importa si mi sistema falla. Me importaría que mis datos se pierdan.

Lamentablemente, estos son los errores que deberán cometerse hasta que aprenda a utilizar el terminal con las precauciones adecuadas.

MrPaulch
fuente
16
Su último punto es una de las muchas razones por las cuales todos deberían usar el control de versiones
Darren H
44
Una vez destruí un programa en el que estaba trabajando, gcc program.c -o program.cgracias precisamente a la finalización de la pestaña. Aprendí a usar el control de versiones religiosamente después de eso.
nneonneo
2
La mejor respuesta hasta ahora, publicar comandos de aspecto legítimo que podrían ser el resultado de un simple error tipográfico y, sin embargo, pueden provocar un daño importante.
gaazkam
1
"Ahora tengo el código ensamblador en mi programa.c" No, no. No tienes nada. La redirección truncó el archivo incluso antes de que GCC lo abriera.
muru
1
Oh hombre, estoy realmente feliz de que hayan agregado esa mejora en la interfaz de usuario en GCC. Ha pasado un tiempo desde mi último error, pero es bueno ver que tendré un poco de protección contra eso la próxima vez.
nneonneo
28

Causar un pánico en el núcleo es más parecido a estrellarse que las otras respuestas que he visto aquí hasta ahora:

sudo dtrace -w -n "BEGIN{ panic();}"

(código tomado de aquí y también encontrado en la documentación de Apple )

También puedes probar:

sudo killall kernel_task

No he verificado que el segundo allí realmente funcione (y no tengo la intención de hacerlo, ya que tengo algo de trabajo abierto en este momento).

PIB2
fuente
2
Acabo de probar el segundo en una máquina virtual 10.12.3, y solo dice:No matching processes were found
Alexander O'Mara
3
Además, el primero no parece funcionar, al menos si SIP está habilitado,dtrace: system integrity protection is on, some features will not be available dtrace: description 'BEGIN' matched 1 probe dtrace: could not enable tracing: Permission denied
Alexander O'Mara
@ AlexanderO'Mara No muy sorprendido con sus resultados en el segundo comando; Pensé que Mac OS X no le permitiría eliminar el proceso del kernel de esa manera. Los resultados para el primer comando también son de esperar, como dtracefue efectivamente neutralizado por SIP.
GDP2
1
kernel_taskNo es un proceso normal. Es inmortal; No se puede matar excepto a través de un error propio (y eso se llamaría un KP y derriba toda la máquina). kernel_taskEl PID es nominalmente 0, pero si proporciona eso a la kill(pid, sig)llamada al sistema, la página del manual dice que si pides igual a 0, sigse envía a cada proceso en el grupo de procesos del proceso de llamada. . Entonces simplemente no puedes enviar kernel_taskuna señal.
Iwillnotexist Idonotexist
@IwillnotexistIdonotexist Sí, pensé que sería el caso; Gracias por la informacion sin embargo. Cosas buenas para tener en cuenta.
GDP2
19

MacOS moderno hace que sea realmente difícil bloquear su máquina como un usuario no privilegiado (es decir, sin usar sudo), porque los sistemas UNIX están destinados a manejar miles de usuarios sin permitir que ninguno de ellos rompa todo el sistema. Entonces, afortunadamente, por lo general, se le pedirá que lo indique antes de hacer algo que destruya su máquina.

Desafortunadamente, esa protección solo se aplica al sistema mismo. Como ilustra xkcd, hay muchas cosas que le interesan que no están protegidas por la Protección de integridad del sistema, los privilegios de root o las solicitudes de contraseña:

XKCD 1200

Entonces, hay toneladas de cosas que puede escribir que arruinarán su cuenta de usuario y todos sus archivos si no tiene cuidado. Algunos ejemplos:

  • rm -rf ${TEMPDIR}/*. Esto parece totalmente razonable, hasta que te das cuenta de que la variable de entorno está escrita TMPDIR. TEMPDIRgeneralmente no está definido, lo que hace que esto sea así rm -rf /. Incluso sin sudoesto, esto eliminará felizmente todo lo que tenga permisos de eliminación, que generalmente incluirá toda su carpeta de inicio. Si deja que esto se ejecute el tiempo suficiente, también destruirá cualquier unidad conectada a su máquina, ya que generalmente tiene permisos de escritura.
  • find ~ -name "TEMP*" -o -print | xargs rm. findnormalmente ubicará archivos que coincidan con ciertos criterios y los imprimirá. Sin -oesto, hace lo que esperaría y elimina todos los archivos que comienzan con TEMP*( siempre que no tenga espacios en la ruta ). Pero, -osignifica "o" (¡no "salida" como lo hace para muchos otros comandos!), Lo que hace que este comando elimine todos sus archivos. Gorrón.
  • ln -sf link_name /some/important/file. Ocasionalmente, la sintaxis de este comando es incorrecta, y con mucho gusto sobrescribirá su archivo importante con un enlace simbólico inútil.
  • kill -9 -1 matará a todos sus programas, cerrándolo con bastante rapidez y posiblemente causando pérdida de datos.
nneonneo
fuente
3
FYI (para otros que lean esto) findtiene un -deleteargumento que es mucho más seguro que contarloxargs rm
Josh el
¿Es el MacOS moderno realmente más a prueba de choques? La mayoría de estos sistemas son para un solo usuario. ¿Realmente tienen maxprocs / cpulimits sanos? ¿Me puede proporcionar una referencia?
user2497
1
Usted, de todas las personas, sabría bien el daño ln -sfpuede hacer ... y cómo recuperarse de ella :-)
Iwillnotexist Idonotexist
1
@ Josh: gracias por señalarlo. Y, en el caso general, uno debe usar find -print0 | xargs -0para manejar con seguridad caracteres extraños en los nombres de archivo.
nneonneo
1
Convenido. Más consejos útiles sobre xargs: use <whatever> | xargs echo <something>primero, para obtener una vista previa de los comandos que realmente ejecutará xargs. xargs es un gran ejemplo de por qué la CLI es tan poderosa: puede operar en muchos, muchos artículos a la vez sin una molesta confirmación y agarre de la mano ... solo asegúrese de decirle que haga lo que quiere.
Josh
16

Otra que puedes hacer (que he hecho por error antes) es:

sudo chmod 0 /

Esto hará que todo su sistema de archivos (que significa todos los comandos y programas) sea inaccesible ... excepto por el usuario root. Esto significa que necesitaría iniciar sesión directamente como usuario root y restaurar el sistema de archivos, PERO no puede acceder al sudocomando (o cualquier otro comando, para el caso). Puede restaurar el acceso a comandos y archivos iniciando en modo de usuario único, montando y restaurando el sistema de archivos chmod 755 /.

Si esto se hace de forma recursiva, chmod -R 0 /entonces el sistema quedará inutilizable. La solución adecuada en ese punto es utilizar la Utilidad de Discos de la partición de recuperación para reparar los permisos del disco . Es mejor que solo restaure una instantánea o una copia de seguridad de su sistema de archivos si se ejecutó de forma recursiva.

musicman523
fuente
8
"Puedes arreglarlo con ... chmod 755 /" - No, no puedes. Muchos archivos requieren diferentes permisos de 755, ya sea por seguridad o para funcionar. chmod 755 /dejará su sistema inseguro y roto de manera sutil. La única recuperación completa de chmod 0 /es a través de la restauración de instantáneas, restauración de copia de seguridad y / o reinstalación.
marcelm
2
@marcelm Buen punto. Mi sugerencia fue solo restaurar el acceso a los comandos, no como una solución permanente. He actualizado mi respuesta para reflejar eso. Hasta donde yo sé, chmod no es recursivo a menos que use la -Rbandera, así que pensé que los permisos de los subdirectorios no se verían afectados.
musicman523
55
@marcelm tiene razón, pero el comando que se muestra no es recursivo, por lo que solo /se ve afectado.
Andrea Lazzarotto
Una vez tuve una sudo chmod -R 700 /computadora nueva, pensando que sería mucho más seguro si lo hiciera. Sorprendentemente, arrancó y terminó con una barra de menú vacía y un escritorio en blanco. Nada más funcionó, ¡pero los permisos de restauración de la utilidad de disco de la partición de recuperación lograron configurar casi todo correctamente!
nneonneo
2
La utilidad de disco @marcelm tiene una opción de "Arreglar permisos" que debería corregir esto sin una restauración completa del sistema
Josh
10

Las respuestas a esa llamada sudodeben considerarse inválidas. Estos ya suponen acceso administrativo al sistema.

Tratar perl -e 'exit if fork;for(;;){fork;}'. OSX puede tener alguna protección contra esto ahora. Si aparece una burbuja de manzana que le pregunta si desea finalizar la aplicación Terminal y los subprocesos, está (casi) bien.

while true ; do cat /dev/zero > /dev/null & doneTambién es muy útil, especialmente. Si usted no tiene perl.

for i in 1 2 3 4 ; do cat /dev/zero > /dev/null & donesolo hará una pequeña y divertida prueba de carga de CPU. Muy bueno para verificar si su disipador térmico y ventilador están a la altura.

user2497
fuente
Esto se conoce como una bomba de horquilla y probablemente inutilizará el sistema (podría considerarse un "bloqueo"), pero probablemente no causará ningún daño permanente. Pero es desagradable!
Josh
@Josh "pero probablemente no causará ningún daño permanente" Excepto para cualquier trabajo no guardado actualmente abierto.
reirab
@reirab Josh agregó el 'todo probable' a su declaración. Pero MacOS es principalmente para editar fotos y videos ahora. ¿Los programas de Adobe no tienen guardado automático automático?
user2497
1
Además, el trabajo no guardado siempre está en riesgo hasta que se guarde. Si su computadora queda inutilizable, entonces no puede guardar nada que haya abierto :)
Josh
@Josh MacOS es muy fácil de guardar. Siempre es 🍎-S. No deberías haber escrito 'probable' 👋🏾
user2497
7

Claro, asegúrese de tener una copia de seguridad y guarde los archivos que le interesen, luego escriba halt

Suponiendo que luego se utiliza sudopara ser root, la Mac se bloqueará.

El mayor riesgo de la línea de comando es la pérdida de datos. La interfaz macOS está diseñada durante décadas para no sorprender a las personas y destruir sus datos, configuraciones o aplicaciones. La interfaz gráfica de macOS también existe para eliminar la curva de aprendizaje (una empinada) para que sea segura y domine las secuencias de comandos de shell.

Pierdes esas protecciones, por eso advierto a las personas que comienzan con la aplicación de terminal o ssh. Si tiene una copia de seguridad que sabe que funciona y tiene el tiempo y la confianza / habilidad para realizar una restauración, entonces debe sumergirse y aprender e incluso romper cosas.

bmike
fuente
3
Usted dijo: "... e incluso romper cosas", que es un buen caso de uso para hacer cosas arriesgadas en una máquina virtual. :)
user3439894
1
¿Cómo va a colapsar esto? Simplemente apaga el sistema de inmediato. Incluso vacía las memorias intermedias del núcleo para que no haya pérdida de datos (guardados). developer.apple.com/legacy/library/documentation/Darwin/…
Josh
7
sudo kill -9 -1  

Accidentalmente realicé un kill -9 -1script en perl, ejecutándome como root. Eso fue tan rápido como tirar del cable de alimentación. Al reiniciar, el servidor realizó una comprobación del sistema de archivos y continuó ejecutándose correctamente.

Nunca probé ese sudo kill -9 -1comando en la línea de comandos. Es posible que no funcione, porque el ID de proceso "-1" significa "matar todos los procesos que pertenecen al grupo de procesos del llamador".

No estoy seguro, si con sudo, eso también significa init y todas las cosas del kernel ... Pero si eres root, kill -9 -1definitivamente harás una parada inmediata, al igual que tirar del cable de alimentación. Por cierto, ¡nada aparecerá en los archivos de registro, porque ese comando es el asesino más rápido en el oeste!

En realidad, para recuperarme, fui a nuestros administradores de sistemas y les dije lo que hice. Hicieron un reinicio completo, porque no había forma de iniciar sesión en ese servidor (RHEL6).

A kill -9 -1como root mata todos los procesos, que se ejecuta como root. Es decir, sshd. Eso me desconectó de inmediato e impidió que alguien volviera a iniciar sesión. Cualquier proceso iniciado por init, incluido init, se ha eliminado, a menos que hayan cambiado UID o GID. Incluso iniciar sesión a través de la consola en serie ya no era posible. ps -eaf | grep rootmuestra algunos procesos sofisticados que, si reaccionan en un SIGKILL de la manera predeterminada, prácticamente detendrían incluso la escritura básica en HD.

No intentaré esto ahora en mi computadora portátil :-) No tengo la curiosidad de descubrir si un kill -9 165([ext4-rsv-conver]) realmente dejaría de escribir en el HD.

bubi6608
fuente
No puede "matar" el kernel, y esto no debería causar un chequeo del sistema de archivos en sí mismo. ¿Cómo te recuperaste de la situación? ¿Hiciste un reinicio duro? Porque eso es probablemente lo que causó la verificación del sistema de archivos :)
Josh
Tu respuesta editada tiene sentido. En realidad no puede matar initnormalmente, pero puede matar todas las sesiones gettys y SSH y dejar la máquina inutilizable. Un Magic SysRq debería haber permitido un reinicio limpio, pero a menudo es más fácil simplemente reiniciar y confiar en el diario FS :)
Josh
5

Sí, puedes destruir completamente tu sistema. Hacer accidentalmente algo con sudoprivilegios es un ejemplo que se ha publicado, ya sea olvidando algunos caracteres que le indican al terminal que haga algo completamente diferente de lo que pretendía. rming en /lugar de /tmp/\*es solo una diferencia de 5 caracteres. Poner un espacio en el lugar equivocado también podría hacer algo completamente diferente. Otras veces, las instrucciones aparentemente bien intencionadas podrían tener código malicioso ofuscado. Algunas personas en Internet son muy buenas para ofuscar el código.

También hay comandos que, usando html, pueden hacer que el tamaño de fuente sea cero, por lo que algo completamente inocuo, cuando se copia en el portapapeles, de hecho podría estar instalando el repositorio git de alguien como una fuente confiable y descargando malware.

Y hay comandos que puede ejecutar que lo abren para explotar, o que podrían ser perfectamente bien intencionados pero eliminan archivos o programas importantes o corrompen su disco. De hecho, el uso incorrecto de herramientas podría hacer algo tan básico como escribir accidentalmente sobre su sector de arranque, o la cabeza de su disco, o muchos otros problemas.

Un ejemplo de algo menos destructivo que no se ha publicado es abrir archivos binarios vi. Si alguna vez lo ha intentado, sabrá que puede dañar su terminal hasta el punto de que no se puede usar hasta que lo sea reset.

Alternativamente, hay comandos que atascarán su máquina, como:

yes >> /dev/null & yes >> /dev/null & yes >> /dev/null & yes >> /dev/null & 

Puedes probarlo, no hará daño, pero atascará tu procesador y tendrás que matar cada proceso que hayas generado.

Dicho esto, en informática generalmente se considera que no se puede hacer una tortilla sin romper algunos huevos. Debe ser cauteloso en la terminal, pero la única forma de mejorar el uso del sistema operativo es aprendiendo y practicando.

JFA
fuente
Tu primer ejemplo es apenas dañino. Vim es bastante sensato cuando edita archivos binarios. Y en el peor de los casos, puede cerrar la ventana. El segundo ejemplo con "sí" es molesto y usará una buena cantidad de CPU de usuario, pero el sistema seguirá respondiendo y puede eliminar fácilmente la ventana de terminal principal.
nneonneo
1
No estoy de acuerdo con "desordenar su terminal hasta el punto de que no se puede usar hasta que reinicie" - intente reset, eso debería aclarar un terminal que tiene una salida binaria impresa. o simplemente genera un nuevo TTY
Josh
1
Genial, nw @JFA. ¡Realmente me llevó años aprender el resettruco! Para más información: unix.stackexchange.com/questions/79684
Josh
1
@ Josh, gracias por eso, fue de gran ayuda. De hecho, han pasado muchos años para mí: P
JFA
1
@Josh Entonces 'stty sane ^ M' y 'tput reset' también deberían ser emocionantes para ti.
user2497
4

Solo soy un principiante, pero puedes establecer un tiempo Verdadero; hacer MANDO; hecho; La mayoría de las personas probarían Ctrl + C que detendrá el comando, no el proceso externo (ctrl + Z, que luego debe eliminarse). Supongo que si el comando es una operación pesada, como multiplicar un gran número a su propio poder, eso podría interferir con sus recursos. Pero, de hecho, el sistema operativo moderno generalmente está protegido contra tal desorden.

Ando Jurai
fuente
2
Simplemente funciona muy rápido, no se bloqueará nada. Solo tienes que bifurcar algunos cálculos intensivos para que kernel maxprocs no te entristezca. trywhile true do cat /dev/zero > /dev/null & done
user2497
Gracias. Hubiera esperado manejar grandes números para hacer que la computadora funcionara lentamente, a veces sucedió con programas java / python muy simples que utilicé para el aprendizaje automático.
Ando Jurai
1
El gato cero a bit nulo es una operación de gran número, al menos en E / S. Utilizo uno de estos por núcleo de una CPU para hacer pruebas térmicas.
user2497
1
Y ^C también matará el ciclo while, pero simplemente se repite demasiado rápido para que se detecte la interrupción. Mantener presionado ^Cpuede salir del circuito. El cierre de la terminal también lo hará :)
Josh
2
@ Josh Es más fácil atrapar INT si hay una pequeña pausa, como dormir 0.1, después de la tarea intensiva de la CPU.
user2497
3

Seguramente aún puede causar un bloqueo del sistema usando los comandos ingresados ​​con Terminal.

Con los años se está volviendo más difícil, probablemente debido a todo tipo de límites y medidas de protección aplicadas, pero como dice la ley de Murphy: "Nada es infalible para un tonto lo suficientemente capaz".

Las "bombas de horquilla" y todas esas rm -rfcosas de script kiddies son cosas conocidas para UNIX. Con Mac OS X puede divertirse más usando sus partes del subsistema GUI ( WindowServerpor mencionar) o algo así como el firewall de OpenBSD, también conocido por PFlos ingenieros de Apple, pero que nunca logró actualizar desde su estado de 2008. PFobras en el kernel por lo que cuando atrapa una peculiaridad que es hora de Apple te dice " que reinicia la computadora debido a un pánico" o cosas como esta.

La peor parte de esto es que nunca puedes tener una idea de dónde y por qué entró en pánico, porque Apple no proporciona ningún rastro significativo de la pila; solo puede tener números hexadecimales de las direcciones de retorno del marco de la pila.

poige
fuente
Buena respuesta y excelentes puntos. Me gustaría agregar a su lista de buenas maneras de hacer que OS X entre en pánico en la pista de baile, mi favorito personal, pero sin términos explícitos para evitar las estupideces de los guiones infantiles. Descargo una extensión de kernel relevante para NFC. Funciona todo el tiempo, al instante. Uno puede fácilmente convertir esto en un DOS programando esto en un número divisible de 5 minutos. Por lo tanto, se iniciará y luego se zambullirá. Esto requiere una reinstalación del sistema operativo dado que la mayoría de los administradores e incluso los técnicos se lo perderán ...
Francis de ResponseBase
3

Es un poco ambiguo lo que quieres decir con "bloquear" tu computadora ... y no hay una respuesta correcta definitiva para eso, aunque hay algunos ejemplos útiles en otras respuestas. Como su pregunta es más ambigua y general, me gustaría centrarme en la naturaleza de la pregunta y darle una respuesta más general.

Las personas que no entienden Terminal a menudo tienen miedo de usarlo por temor a que puedan estropear su comando y bloquear su computadora

Creo que la línea de comando es una espada de doble filo y, a menudo, muy afilada. Su mayor fortaleza es también su mayor debilidad para los nuevos usuarios: los programas CLI hacen lo que usted dice, sin preguntar si realmente es lo que quería decir. A menudo no piden confirmación, no brindan ayuda manual o interactiva, y sus opciones son breves, a menudo breves, a veces confusas cadenas basadas en texto. Tenga en cuenta que generalmente están muy bien documentados, uno solo tiene que leer el manual (que es casi siempre man <command you are about to run>) y tomarse el tiempo para comprender qué hará la línea de comando que van a ejecutar.

Este modo de operación es poderoso : significa que los usuarios experimentados de CLI pueden crear "canales" de comandos largos que realizan tareas complejas con comandos únicos. Esto se debe a que la tarea no preguntará "¿Estás seguro?" A cada paso del camino, hace lo que se le dice. Pero para un usuario que no está familiarizado con este modo, y está acostumbrado a una GUI donde la ayuda en línea está a un clic de distancia, no es familiar y da miedo.

Pero, ¿hay realmente comandos que bloqueen su computadora?

¿Puedes "bloquear" tu computadora usando la CLI? Tal vez. Ciertamente puede causar pérdida de datos si utiliza un comando destructivo incorrectamente. Por ejemplo, muchas de las respuestas aquí mencionadas rm, un comando que elimina archivos. Obviamente, puede causar pérdida de datos con ese comando, para eso fue diseñado el comando.

Como han señalado otras respuestas, puede usar la línea de comando para dejar su máquina prácticamente inutilizable durante un período de tiempo: puede apagarla sin confirmación, hacer que un proceso use el 100% de sus recursos disponibles sin confirmación, eliminar todos sus programas o destruir su sistema de archivos. Si realmente quisiera, podría usar la CLI para crear una extensión del núcleo que haga que el núcleo entre en pánico (que es lo más parecido a un "bloqueo" que se me ocurre).

La línea de comando (a la que se accede a través de la Terminal) es una herramienta poderosa. A menudo es más rápido resolver un problema usando Terminal que la GUI. Algunas soluciones solo están disponibles con los comandos de Terminal. Sin embargo, la clave de la CLI es la comprensión . No ejecute comandos aleatorios que vea en línea. Lea las páginas de manual y comprenda qué hacen los comandos. Si no está seguro, pregúntele a alguien u obtenga más información sobre un comando antes de ejecutarlo.

Josh
fuente