Les répertoires /tmp et /usr/tmp (plus tard /var/tmp ) était le dépotoir de tout et de tous. Le seul mécanisme de protection des fichiers dans ces répertoires est le sticky bit qui limite la suppression ou le changement de nom des fichiers à leurs propriétaires. Comme marcelm l'a souligné dans un commentaire, rien n'empêche en principe quelqu'un de créer des fichiers avec des noms utilisés par des services (comme nginx.pid ou sshd.pid ). (En pratique, cependant, les scripts de démarrage pourraient d'abord supprimer ces fichiers fictifs.)
/run a été établi pour les données d'exécution non persistantes de services de longue durée tels que les verrous, les sockets, les fichiers pid, etc. Comme il n'est pas accessible en écriture pour le public, il protège les données d'exécution du service du désordre dans /tmp et les emplois qui nettoient là-bas. En effet :Deux distributions que j'exécute (sans jeu de mots) ont des autorisations 755 sur /run , tandis que /tmp et /var/tmp (et /dev/shm d'ailleurs) ont les permissions 1777.
/tmp est l'emplacement de création des fichiers et répertoires temporaires. Il n'est pas utilisable pour stocker des "noms connus" (c'est-à-dire des noms dont un autre processus pourrait avoir connaissance sans que vous ayez à lui transmettre le nom d'une manière ou d'une autre) car personne n'a la propriété de l'espace de noms ; n'importe qui peut y créer des fichiers. En tant que tel, vous l'utilisez généralement lorsque vous avez un utilitaire qui a besoin d'un fichier (c'est-à-dire pas un canal ou autre) en entrée ou en sortie, où n'importe quel nom (généré aléatoirement) fonctionnera tant que vous transmettez le nom.
Historiquement, certaines choses (comme X) ont violé ce principe et mis des noms bien connus (comme .X11-unix ) en /tmp . Ceci est bien sûr bogué et permet à tout utilisateur de DoS le service qui en a besoin en se précipitant pour créer d'abord un fichier portant le nom souhaité. De telles choses appartiennent à /run (ou de manière équivalente /var/run si vous n'êtes pas abonné au révisionnisme de Freedesktop.org). Bien sûr, il serait encore mieux de les corriger pour qu'ils n'utilisent pas de noms connus dans un espace de noms global, mais qu'ils transmettent plutôt un chemin d'accès.
Aucune raison d'avoir à la fois /run et /tmp
Je pense que tu as raison. /tmp est essentiellement obsolète maintenant nous avons /run . Si votre programme est en mesure de le faire (ce qui nécessite qu'il ait été installé en tant qu'opération privilégiée), alors de nos jours, vous utiliseriez un sous-répertoire de /run . C'est pour des raisons de sécurité.
Par exemple. le démon d'impression CUPS ne s'exécute pas en tant que root, mais est généralement installé à partir d'un package de système d'exploitation. Le paquet installe /usr/lib/tmpfiles.d/cups.conf , et systemd-tmpfiles crée un répertoire auquel il peut accéder. Puisque le répertoire est sous /run , le nom ne peut pas avoir été revendiqué de manière malveillante par un utilisateur non privilégié, contrairement à /tmp qui est accessible en écriture par tout le monde.
"Programmes non privilégiés" qui ne peuvent pas utiliser /run directement
La vraie distinction est si votre programme est exécuté par un utilisateur arbitraire non privilégié, sous son propre ID utilisateur. Mais vous ne voulez généralement toujours pas utiliser /tmp , car il peut être consulté par d'autres utilisateurs non privilégiés. Vous préférez utiliser $XDG_RUNTIME_DIR . Généralement, cela est implémenté en tant que /run/user/$(id -u) - il s'agit donc d'un sous-répertoire de /run aussi bien. L'emplacement n'est pas garanti cependant; les programmes doivent toujours utiliser la variable d'environnement.
/tmp ne serait utile que pour une coopération ad hoc entre différents utilisateurs non privilégiés sur le système. De tels systèmes ad hoc sont vulnérables à un utilisateur malveillant refusant de coopérer et gâchant les choses pour tout le monde :). Un exemple serait des utilisateurs non privilégiés décidant d'exécuter une version du talk démon, en utilisant un socket unix.
Informations originales de Lennart Poettering
Remarque, la liste de contrôle de Poettering ci-dessous affirmait que /tmp serait utile pour les "petits fichiers", alors que /run ne doit être utilisé que pour les "primitives de communication". Je ne pense pas non plus que cette distinction soit vraie. L'affiche de /run est udev , et je suis à peu près sûr /run/udev comprend des bases de données internes . Une fois que vous avez un /run répertoire, je ne pense pas que quiconque veuille suivre la distinction revendiquée et en créer un autre répertoire, pour encombrer /tmp . Donc, en pratique, nous utilisons simplement /run de nos jours.
L'utilisation d'espaces de noms partagés en écriture universelle [comme /tmp] à des fins de communication a toujours été problématique, car pour établir une communication, vous avez besoin de noms stables, mais les noms stables ouvrent la porte aux attaques DoS. Cela peut être partiellement corrigé, en établissant des répertoires par application protégés pour certains services lors du démarrage précoce (comme nous le faisons pour X11), mais cela ne résout que partiellement le problème, car cela ne fonctionne correctement que si chaque installation de package est suivie d'un redémarrage.
...
Une autre fonctionnalité de Fedora (pour Fedora 17) a modifié la sémantique de /tmp pour de nombreux services système afin de les rendre plus sûrs, en isolant les espaces de noms /tmp des différents services
...
Étant donné que /tmp n'est plus nécessairement un espace de noms partagé, il n'est généralement pas adapté comme emplacement pour les primitives de communication.
...
[/run] est garanti être un tmpfs et est donc automatiquement vidé au démarrage. Aucun nettoyage automatique n'est effectué au-delà.
...
Voici un guide approximatif de la façon dont nous vous suggérons (un développeur d'applications Linux) de choisir le bon répertoire à utiliser :
- Vous avez besoin d'un emplacement pour placer votre socket (ou autre primitive de communication) et votre code s'exécute en mode privilégié :utilisez un sous-répertoire sous /run. (Ou sous /var/run pour plus de compatibilité.)
- Vous avez besoin d'un emplacement pour placer votre socket (ou une autre primitive de communication) et votre code s'exécute sans privilège :utilisez un sous-répertoire sous $XDG_RUNTIME_DIR.
- Vous avez besoin d'un emplacement pour placer vos téléchargements volumineux et en cours et les exécuter sans privilège :utilisez $XDG_DOWNLOAD_DIR.
- Vous avez besoin d'un emplacement pour placer les fichiers de cache qui doivent être persistants et s'exécuter sans privilège :utilisez $XDG_CACHE_HOME.
- Rien de ce qui précède ne s'applique et vous devez placer un petit fichier qui n'a pas besoin de persistance :utilisez $TMPDIR avec un repli sur /tmp. Et utilisez mkstemp(), et mkdtemp() et rien de chez vous.
- Sinon, utilisez $TMPDIR avec un repli sur /var/tmp. Utilisez également mkstemp()/mkdtemp().
Notez que ces règles ci-dessus ne sont que suggérées par nous. Ces règles tiennent compte de tout ce que nous savons sur ce sujet et évitent les problèmes avec les distributions actuelles et futures, dans la mesure où nous pouvons les voir. Veuillez envisager de mettre à jour vos projets pour suivre ces règles et gardez-les à l'esprit si vous écrivez un nouveau code.
Une chose que nous aimerions souligner est que /tmp et /var/tmp le plus souvent ne sont pas le bon choix pour votre cas d'utilisation. Il existe des utilisations valables de ces répertoires, mais très souvent un autre répertoire pourrait en fait être le meilleur endroit. Donc, soyez prudent, considérez les autres options, mais si vous optez pour /tmp ou /var/tmp, assurez-vous au moins d'utiliser mkstemp()/mkdtemp().
Nous nous en sortons en quelque sorte avec l'héritage J'ai mal lu /tmp socket utilisé par le système X window, comme décrit ci-dessus.tmpfiles.d/x11.conf . On dirait plus que cela repose sur la coopération :). Je suppose que le code a été audité, de sorte que le déni de service est le pire qui puisse arriver.