Los directorios /tmp y /usr/tmp (luego /var/tmp ) solía ser el vertedero de todo y de todos. El único mecanismo de protección para los archivos en estos directorios es el sticky bit 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 utilizan los servicios (como nginx.pid o sshd.pid ). (Sin embargo, en la práctica, los scripts de inicio podrían eliminar estos archivos falsos primero).
/run se estableció para datos de tiempo de ejecución no persistentes de servicios de larga duración, como bloqueos, sockets, archivos pid y similares. Dado que no se puede escribir para el público, protege los datos de tiempo de ejecución del servicio del desorden en /tmp y trabajos que limpian allí. De hecho:dos distribuciones que ejecuto (sin juego de palabras) tienen permisos 755 en /run , mientras que /tmp y /var/tmp (y /dev/shm para el caso) tienen permisos 1777.
/tmp es la ubicación para la creación de archivos y directorios temporales. No se puede usar para almacenar "nombres conocidos" (es decir, nombres que otro proceso podría conocer sin que usted tenga que transmitirle el nombre de alguna manera) porque nadie tiene 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 canalización o algo así) 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 ) en /tmp . Por supuesto, esto tiene errores y permite que cualquier usuario DoS el servicio que necesita hacerlo simplemente compitiendo para crear un archivo con el nombre deseado primero. Tales cosas pertenecen a /run (o equivalente /var/run si no se suscribe al revisionismo de Freedesktop.org). Por supuesto, incluso mejor sería corregirlos para que no usen nombres conocidos en un espacio de nombres global, sino que pasen un nombre de ruta.
No hay razón para tener tanto /run como /tmp
Creo que tienes razón. /tmp está esencialmente en desuso ahora que tenemos /run . Si su programa está en condiciones de hacerlo (lo que requiere que haya sido instalado como una operación privilegiada), hoy en día usaría un subdirectorio de /run . Esto es por razones de seguridad.
P.ej. el demonio de impresión CUPS no se ejecuta como raíz, pero generalmente se instala desde un paquete de sistema operativo. El paquete instala /usr/lib/tmpfiles.d/cups.conf y systemd-tmpfiles crea un directorio al que puede acceder. Dado que el directorio está bajo /run , el nombre no puede haber sido maliciosamente reclamado por un usuario sin privilegios, a diferencia de /tmp que es de escritura mundial.
"Programas sin privilegios" que no pueden usar /run directamente
La distinción real es si su programa está siendo ejecutado por un usuario arbitrario sin privilegios, bajo su propia identificación de usuario. Pero aún así, por lo general, no querrás usar /tmp , porque otros usuarios sin privilegios pueden acceder a él. Preferirías usar $XDG_RUNTIME_DIR . Por lo general, esto se implementa como /run/user/$(id -u) - por lo que resulta ser un subdirectorio de /run también. Sin embargo, la ubicación no está garantizada; los programas siempre deben usar la variable de entorno.
/tmp solo sería útil para la cooperación ad-hoc entre diferentes usuarios no privilegiados en el sistema. Tales sistemas ad-hoc son vulnerables a un usuario malicioso que se niegue a cooperar y estropee las cosas para todos :). Un ejemplo serían los usuarios sin privilegios que deciden ejecutar una versión de talk daemon, usando un socket Unix.
Información original de Lennart Poettering
Tenga en cuenta que la lista de verificación de Poettering a continuación afirma que /tmp sería útil para "archivos pequeños", mientras que /run solo debe usarse para "primitivas de comunicación". Tampoco creo que esta distinción sea cierta. El chico del cartel de /run es udev , y estoy bastante seguro de que /run/udev incluye bases de datos internas. Una vez que tenga un /run directorio, no creo que nadie quiera seguir la distinción reclamada y crear otro directorio, desordenar /tmp . Entonces, en la práctica, solo usamos /run hoy en día.
El uso de espacios de nombres compartidos de escritura mundial [como /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 se puede corregir parcialmente, estableciendo 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 del 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 distintos 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.
...
Se garantiza que [/run] es un tmpfs y, por lo tanto, se vacía automáticamente al arrancar. Más allá de eso, no se realiza ninguna limpieza automática.
...
Aquí hay una guía aproximada de cómo le sugerimos a usted (un desarrollador de aplicaciones de Linux) que elija el directorio correcto para usar:
- 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 mayor compatibilidad).
- 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.
- Necesita un lugar para poner sus descargas más grandes y descargas en progreso y ejecutarlas sin privilegios:use $XDG_DOWNLOAD_DIR.
- Necesita un lugar para colocar archivos de caché que deben ser persistentes y ejecutarse sin privilegios:use $XDG_CACHE_HOME.
- Nada de lo anterior se aplica 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.
- De lo contrario, use $TMPDIR con un respaldo en /var/tmp. También use mkstemp()/mkdtemp().
Tenga en cuenta que estas reglas anteriores solo las sugerimos 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éngalas en cuenta si escribe código nuevo.
Una cosa que nos gustaría enfatizar es que /tmp y /var/tmp la mayoría de las veces no son la opción correcta para su caso de uso. Hay usos válidos de estos directorios, pero muy a menudo otro directorio podría ser el mejor lugar. Entonces, tenga cuidado, considere las otras opciones, pero si opta por /tmp o /var/tmp, al menos asegúrese de usar mkstemp()/mkdtemp().
Nos salimos con la suya con el legado Leí mal /tmp socket utilizado por el sistema de ventanas X, como se describe anteriormente.tmpfiles.d/x11.conf . Parece más que se basa en la cooperación :). Supongo que el código ha sido auditado, de modo que la denegación de servicio es lo peor que puede pasar.