¿Desde cuándo POSIX y GNU rm no borran /?

Desde hace varios años, la rmutilidad GNU no se eliminará a /menos que se llame con la --no-preserve-rootopción. Sin embargo, el comando rm -rf /se ha alojado en el subconsciente colectivo como peligroso durante mucho tiempo y la gente todavía lo cita como un comando "aterrador".

Me preguntaba cuándo apareció por primera vez esta regla que rmno se puede eliminar /. Verifiqué las especificaciones POSIX, y puedo ver que si bien POSIX: 2008 incluye esta característica de seguridad, POSIX: 2001 no. Como las versiones en línea de las especificaciones POSIX se actualizan de vez en cuando, con cada nueva publicación secundaria, también verifiqué la máquina wayback y encontré la página relevante de POSIX: 2008 desde 2010 y pude confirmar que la regla rmno puede eliminarse /ya estaba en la lista entonces.

Entonces, mis preguntas son:

• ¿Cuándo se agregó la regla que rmno se puede eliminar /a las especificaciones POSIX? ¿Estaba en la edición original de 2008 de la versión 4 de la especificación UNIX única o se agregó en una revisión?
• ¿Cuándo se agregó esta limitación a GNU rm? Estoy bastante seguro de que era antes de que se agregara a POSIX, pero ¿cuándo sucedió?

Puede encontrar la versión HTML de todas las ediciones de POSIX 2008 en línea:

• original: http://pubs.opengroup.org/onlinepubs/9699919799.2008edition/utilities/rm.html
• TC1 (edición 2013) http://pubs.opengroup.org/onlinepubs/9699919799.2013edition/utilities/rm.html
• TC2 (edición 2016) http://pubs.opengroup.org/onlinepubs/9699919799.2016edition/utilities/rm.html

Eso fue agregado en la edición de 2008.

Las correcciones técnicas generalmente no agregan nuevas características.

Puede ver que la versión anterior ( http://pubs.opengroup.org/onlinepubs/009695399/utilities/rm.html ) (POSIX 2004) no tenía ese texto.

El nuevo texto fue aceptado en la conferencia del grupo Austin de 2009-05-09 para su inclusión en una revisión posterior de la norma.

Fue solicitado por John Beck de Sun Microsystems en marzo de ese mismo año (el enlace requiere el registro de opengroup, consulte también la Solicitud de mejora número 5 aquí ).

John Beck escribió, el martes 11 de marzo de 2003:

@ page 820 line 31681-31683 section rm comment {JTB-1}

Problem:

Defect code :  3. Clarification required

An occasional user mistake, with devastating consequences, is to
write a shell script with a line such as:
      rm -rf $VARIABLE1/$VARIABLE2
or
      rm -rf /$VARIABLE1
without verifying that either variable is set, which can lead to
      rm -rf /
being the resulting command.  Since there is no plausible
circumstance under which this is the desired behavior, it seems
reasonable to disallow this.  Such a safeguard would, however,
violate the current specification.

Action:

Either extend the exceptions for . and .. on the noted lines
to list / as well, or specify that the behavior of rm if an
operand resolves to / is undefined.

GNU rmagregó --preserve-rooty las --no-preserve-rootopciones en esta confirmación 2003-11-09 , pero --preserve-rootsolo se convirtió en la predeterminada en esta confirmación 2006-09-03 , por lo que en coreutils 6.2

FreeBSD ha estado preservando la barra oblicua desde la confirmación del 04/10/2004 (con un registro de confirmación "Averigüe cuán a prueba de fuego es realmente mi ropa interior" ), pero inicialmente no cuando estaba debajoPOSIXLY_CORRECT , hasta que recordaron comprobar una década más tarde que POSIX estaba ahora ordenando en qué punto se hizo también en modo POSIX .

El compromiso inicial de FreeBSD menciona que Solaris ya lo estaba haciendo en ese momento.

@JdePB (en el comentario a continuación) encontró que el enlace a una historia interna de Sun corrobora y brinda más detalles sobre el origen de Solaris y sugiere que Solaris ya tenía la salvaguarda en su lugar antes de hacer la solicitud al grupo de Austin.

Explica los fundamentos para agregar esa exclusión. Si bien sólo se puede culpar a sí mismo si lo hacen rm -rf /, hay un caso en el que una secuencia de comandos podría hacerlo si al hacerlo rm -rf -- "$1/$2"sin comprobar que $1/ $2se proporcionaron, que es lo que afectó a algunos clientes de Sun mal cuando aplicar mal un parche Solaris (de acuerdo a ese enlace).

La prohibición de eliminar .y ..se agregó mucho antes y una vez más para proteger contra posibles percances. rmTodavía es un comando peligroso. Hace lo que debe hacer: eliminar lo que le dices.

rm -rf /*
cd /tmp &&  rm -rf .*/   # on some systems where rm -rf ../ still removes
                         # the content of ../ and shells that still
                         # may include . and .. in glob expansions.
rm -rf -- "$diretcory"/* # note the misspelled variable name
dir='foo '; rm -rf $dir/*

También eliminaría todo. Se sabe que la finalización del nombre del shell causa tales problemas cuando lo hace

rm -rf someth<Tab>/*

Ampliado a:

rm -rf something /*

Porque somethingasí no resultó ser un directorio.

A los shells les gusta tcsho zshagregarán un mensaje adicional al intentar llamar rmcon un *comodín ( tcshno de forma predeterminada).