¿Cuál es la diferencia entre / tmp y / run?

De acuerdo con FHS-3.0 , /tmpes para archivos temporales y /runpara datos variables en tiempo de ejecución. Los datos /rundeben eliminarse en el próximo inicio, lo cual no es necesario /tmp, pero los programas aún no deben suponer que los datos /tmpestarán disponibles en el próximo inicio del programa. Todo esto me parece bastante similar.

Entonces, ¿cuál es la diferencia entre los dos? ¿Con qué criterio debe decidir un programa si se deben incluir /tmpo no datos temporales /run?

De acuerdo con la FHS:

Los programas pueden tener un subdirectorio de /run; Esto se recomienda para los programas que usan más de un archivo de tiempo de ejecución.

Esto indica que la distinción entre "programas del sistema" y "programas ordinarios" no es un criterio, ni tampoco lo es la vida útil del programa (como el proceso de larga duración versus el de corta duración).

Aunque la siguiente justificación no se da en el FHS, /runse introdujo para superar el problema que /varse montó demasiado tarde, de modo que se necesitaban trucos sucios para ponerlos a /var/rundisposición lo suficientemente pronto. Sin embargo, ahora que /runse introdujo, y dada su descripción en el FHS, no parece haber una razón clara para tener ambos /runy /tmp.

No hay razón para tener tanto / run como / tmp

Creo que tienes razón. /tmpEs esencialmente obsoleto ahora tenemos /run. Si su programa está en condiciones de hacerlo (lo que requiere que se haya instalado como una operación privilegiada), entonces hoy en día usaría un subdirectorio de /run. Esto es por razones de seguridad.

Por ejemplo, el demonio de impresión CUPS no se ejecuta como root, pero generalmente se instala desde un paquete del sistema operativo. El paquete se instala /usr/lib/tmpfiles.d/cups.confy systemd-tmpfilescrea un directorio al que puede acceder. Dado que el directorio está debajo /run, el nombre no puede haber sido reclamado maliciosamente por un usuario sin privilegios, a diferencia de lo /tmpque se puede escribir en el mundo.

"Programas sin privilegios" que no se pueden usar /rundirectamente

La verdadera distinción es si su programa está siendo ejecutado por un usuario arbitrario sin privilegios, bajo su propia identificación de usuario. Pero, en general, aún no desea usarlo /tmp, ya que otros usuarios sin privilegios pueden acceder a él. Prefieres usar $XDG_RUNTIME_DIR. Por lo general, esto se implementa como /run/user/$(id -u), por lo que resulta ser un subdirectorio /runtambién. Sin embargo, la ubicación no está garantizada; Los programas siempre deben usar la variable de entorno.

/tmpsolo sería útil para la cooperación ad-hoc entre diferentes usuarios sin privilegios en el sistema. Dichos sistemas ad-hoc son vulnerables a que un usuario malintencionado se niegue a cooperar y estropee las cosas para todos :). Un ejemplo serían los usuarios no privilegiados que deciden ejecutar una versión del talkdemonio, utilizando un socket Unix.

Información original de Lennart Poettering

Tenga en cuenta que la lista de verificación de Poettering a continuación afirmaba que /tmpsería útil para "archivos pequeños", mientras /runque solo debería usarse para "primitivas de comunicación". Tampoco creo que esta distinción sea cierta. El chico del cartel /runes udev, y estoy bastante seguro de que /run/udevincluye bases de datos internas. Una vez que tenga un /rundirectorio, no creo que nadie quiera seguir la distinción reclamada y crear otro directorio, para desordenar /tmp. Entonces, en la práctica, solo usamos /runhoy en día.

El uso de espacios de nombres compartidos en todo el mundo [like / tmp] para fines de comunicación siempre ha sido problemático, ya que para establecer la comunicación se necesitan nombres estables, pero los nombres estables abren las puertas a los ataques DoS. Esto puede corregirse parcialmente, mediante el establecimiento de directorios protegidos por aplicación para ciertos servicios durante el inicio temprano (como lo hacemos para X11), pero esto solo soluciona el problema parcialmente, ya que esto solo funciona correctamente si cada instalación de paquete es seguida por un reinicio.

...

Otra característica de Fedora (para Fedora 17) cambió la semántica de / tmp para muchos servicios del sistema para hacerlos más seguros, al aislar los espacios de nombres / tmp de los diversos servicios

...

Debido a que / tmp ya no es necesariamente un espacio de nombres compartido, generalmente no es adecuado como ubicación para las primitivas de comunicación.

...

[/ run] se garantiza que es un tmpfs y, por lo tanto, se descarga automáticamente en las botas. No se realiza una limpieza automática más allá de eso.

...

Aquí hay una guía aproximada de cómo le sugerimos (un desarrollador de aplicaciones de Linux) que elija el directorio correcto para usar:

1. Necesita un lugar para colocar su socket (u otra primitiva de comunicación) y su código se ejecuta con privilegios: use un subdirectorio debajo de / run. (O debajo de / var / run para una compatibilidad adicional).
2. Necesita un lugar para colocar su socket (u otra primitiva de comunicación) y su código se ejecuta sin privilegios: use un subdirectorio debajo de $ XDG_RUNTIME_DIR.
3. Necesita un lugar para poner sus descargas y descargas más grandes en progreso y ejecutar sin privilegios: use $ XDG_DOWNLOAD_DIR.
4. Necesita un lugar para colocar los archivos de caché que deben ser persistentes y ejecutarse sin privilegios: use $ XDG_CACHE_HOME.
5. No se aplica nada de lo anterior y debe colocar un archivo pequeño que no necesite persistencia: use $ TMPDIR con un respaldo en / tmp. Y use mkstemp () y mkdtemp () y nada de cosecha propia.
6. De lo contrario, use $ TMPDIR con un respaldo en / var / tmp. También use mkstemp () / mkdtemp ().

Tenga en cuenta que estas reglas anteriores solo son sugeridas por nosotros. Estas reglas tienen en cuenta todo lo que sabemos sobre este tema y evitan problemas con las distribuciones actuales y futuras, por lo que podemos ver. Considere actualizar sus proyectos para seguir estas reglas, y téngalos en cuenta si escribe un código nuevo.

Una cosa que nos gustaría enfatizar es que / tmp y / var / tmp en la mayoría de los casos no son la opción correcta para su caso de uso. Hay usos válidos de estos directorios, pero a menudo otro directorio podría ser el mejor lugar. Por lo tanto, tenga cuidado, considere las otras opciones, pero si elige / tmp o / var / tmp, al menos asegúrese de usar mkstemp () / mkdtemp ().

De alguna manera nos salimos con el /tmpsocket heredado utilizado por el sistema de ventanas X, como se describió anteriormente. Yo leí mal tmpfiles.d/x11.conf. Parece más que depende de la cooperación :). Supongo que el código ha sido auditado, de modo que la denegación de servicio es lo peor que puede suceder.

Los directorios /tmpy /usr/tmp(más tarde /var/tmp) solían ser el vertedero de todo y de todos. El único mecanismo de protección para los archivos en estos directorios es el bit fijo que restringe la eliminación o el cambio de nombre de los archivos a sus propietarios. Como marcelm señaló en un comentario, en principio no hay nada que impida que alguien cree archivos con nombres que son utilizados por los servicios (como nginx.pido sshd.pid). (Sin embargo, en la práctica, los scripts de inicio podrían eliminar esos archivos falsos primero).

/runse estableció para datos de tiempo de ejecución no persistentes de servicios de larga duración, como bloqueos, sockets, archivos pid y similares. Como no se puede escribir para el público, protege los datos de tiempo de ejecución del servicio del desorden /tmpy los trabajos que limpian allí. De hecho: dos distribuciones que ejecuto (sin juego de palabras) tienen permisos 755 /run, mientras que /tmpy /var/tmp(y /dev/shmpara el caso) tienen permisos 1777.

/tmpes la ubicación para la creación de archivos y directorios temporales. No es utilizable para almacenar "nombres conocidos" (es decir, nombres que otro proceso podría tener en cuenta sin que tenga que transmitir el nombre de alguna manera) porque nadie tiene la propiedad sobre el espacio de nombres; cualquiera puede crear archivos allí. Como tal, generalmente lo usa cuando tiene una utilidad que necesita un archivo (es decir, no una tubería o tal) como entrada o salida, donde cualquier nombre (generado aleatoriamente) funcionará siempre que pase el nombre.

Históricamente, algunas cosas (como X) violaron este principio y pusieron nombres conocidos (como .X11-unix) /tmp. Por supuesto, esto tiene errores y permite a cualquier usuario hacer el servicio que necesita hacerlo simplemente compitiendo para crear un archivo con el nombre deseado primero. Tales cosas pertenecen a /run(o equivalente /var/runsi no se suscribe al revisionismo de Freedesktop.org). Por supuesto, incluso mejor sería arreglarlos para que no usen nombres conocidos en un espacio de nombres global, sino que pasen un nombre de ruta.

De acuerdo con el Estándar de jerarquía del sistema de archivos,

• /run es para datos variables de tiempo de ejecución, es decir, información sobre el sistema en ejecución desde el reinicio
• /tmp es un lugar genérico para archivos temporales.

Por lo tanto, cualquier cosa relacionada con el estado del demonio, los usuarios registrados, los dispositivos extraíbles montados, etc. entraría /runmientras entraban los archivos temporales creados por un programa /tmp.

Editar: como señaló @JdeBP en el comentario a continuación,

El FHS permite cosas como la configuración convencional de trabajos cron que purgan regularmente los /tmparchivos "antiguos"; sin tales mecanismos destinados a /run. De ahí el límite draconiano sobre qué programas pueden esperar de la vida útil de cualquier cosa puesta /tmp. Si bien los programas pueden esperar que los archivos vivan más tiempo en /runun sistema en funcionamiento continuo, también se espera que se arreglen más.