Как защитить потенциально деструктивные параметры командной строки?

Asumo que está viendo esto desde el punto de vista del programador de utilidades. Esto es lo suficientemente amplio como para que no haya (y no pueda haber )una sola respuesta correcta, pero me vienen a la mente algunas cosas.

Creo que la mayoría de las utilidades solo tienen un único indicador de "forzar" (-f), que anula la mayoría de las comprobaciones de seguridad. Por otra parte, p. dpkgtiene un modificador -más detallado --force-things, donde cosas pueden ser varias palabras clave diferentes.

Y apt-gette hace escribir una oración completa para verificar en algunos casos, como eliminar paquetes "esenciales". Vea abajo. (Creo que no es solo una opción de línea de comando aquí, ya que los paquetes esenciales son, p. aquellos que se requieren para instalar paquetes, por lo que deshacer una acción errónea puede ser muy difícil. Además, es posible que no se conozca toda la operación por adelantado, antes de que apthaya tenido la oportunidad de calcular las dependencias del paquete.)

Luego, creo que cdrecordsolía hacer que el usuario esperara un par de segundos antes de comenzar el trabajo, para que tuviera la oportunidad de verificar que la configuración era correcta mientras los números se estaban agotando.

Esto es lo que obtienes si intentasapt-get remove bash:

WARNING: The following essential packages will be removed.
This should NOT be done unless you know exactly what you are doing!
  bash
0 upgraded, 0 newly installed, 2 to remove and 2 not upgraded.
After this operation, 2,870 kB disk space will be freed.
You are about to do something potentially harmful.
To continue type in the phrase 'Yes, do as I say!'
 ?] ^C

Cuál elegir depende de ti como autor del programa -tendrás que basar la decisión en el nivel de peligro de la acción,y en su propio nivel de paranoia. (Ya sea por preocuparse por sus usuarios, o por el miedo a ser culpado por el desorden.)

Algo que tiene el potencial de hacer que el procesador literalmente (se detenga y )se incendie probablemente se encuentre en el extremo superior del eje de "peligro" y probablemente justifique algo como el "tipo 'Sí, haz lo que yo decir'" tratamiento.

Dicho esto, una cosa a tener en cuenta es que muchas de las interfaces reales del nivel del kernel -están no protegidas de ninguna manera. En cambio, hay archivos bajo /sysque pueden cambiar las cosas con solo abrirlos y escribirlos, sin hacer preguntas aparte de los permisos de acceso a los archivos. (es decir, debe ser root.)

Esto también se aplica al contenido del disco duro (como deberíamos saber )y, en un caso, hace dos años, a las variables de configuración del firmware de la placa base. Parece que era posible "bloquear" las computadoras con un rm -rffuera de lugar.

No, de verdad. Consulte el artículo de lwn.net y el seguimiento de problemas de systemd .

Entonces, independientemente de las protecciones que implementaría, solo protegería las acciones realizadas con esa herramienta en particular.