Quelle est la différence entre / tmp et / run?

Selon FHS-3.0 , il /tmps’agit de fichiers temporaires et de /rundonnées variables au moment de l’exécution. Les données d' entrée /rundoivent être supprimées au prochain démarrage, ce qui n'est pas obligatoire pour /tmp, mais les programmes ne doivent pas encore supposer que les données d' /tmpentrée seront disponibles au prochain démarrage du programme. Tout cela me semble assez similaire.

Alors, quelle est la différence entre les deux? Par quel critère devrait un programme décider de mettre les données temporaires dans /tmpou en /run?

Selon la FHS:

Les programmes peuvent avoir un sous-répertoire de /run; cela est encouragé pour les programmes qui utilisent plusieurs fichiers d'exécution.

Cela indique que la distinction entre "programmes système" et "programmes ordinaires" n'est pas un critère, pas plus que la durée de vie du programme (comme, processus long ou court).

Bien que le raisonnement suivant ne soit pas expliqué dans la FHS, il a /runété introduit pour résoudre le problème qui a /varété mis en place trop tard, de sorte que des astuces compliquées étaient nécessaires pour être /var/rundisponibles suffisamment tôt. Cependant, maintenant avec /runson introduction, et compte tenu de sa description dans le FHS, il ne semble pas être une raison évidente d'avoir les deux /runet /tmp.

Aucune raison d'avoir les deux / run et / tmp

Je pense que tu as raison. /tmpest essentiellement obsolète maintenant, nous avons /run. Si votre programme est en mesure de le faire (ce qui nécessite qu'il soit installé en tant qu'opération privilégiée), vous utiliserez alors 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 s'installe /usr/lib/tmpfiles.d/cups.confet systemd-tmpfilescrée un répertoire auquel il peut accéder. Étant donné que le répertoire est en dessous /run, le nom ne peut pas avoir été réclamé de manière malveillante par un utilisateur non privilégié, contrairement à /tmpce qui est en écriture pour le monde entier.

"Programmes non privilégiés" qui ne peuvent pas utiliser /rundirectement

La vraie différence réside dans le fait que votre programme est exécuté par un utilisateur arbitraire non privilégié, sous son propre ID utilisateur. Mais vous ne voulez généralement pas utiliser /tmp, car d’autres utilisateurs non privilégiés peuvent y accéder. Vous préférez utiliser $XDG_RUNTIME_DIR. Généralement, ceci est implémenté comme /run/user/$(id -u)- il se trouve qu’il s’agit également d’un sous-répertoire /run. L'emplacement n'est pas garanti cependant; les programmes doivent toujours utiliser la variable d'environnement.

/tmpne serait utile que pour une coopération ad hoc entre différents utilisateurs non privilégiés du système. De tels systèmes ad-hoc sont vulnérables au refus d'un utilisateur malveillant de coopérer et de gâter tout le monde :). Un exemple serait les utilisateurs non privilégiés qui décideraient d'exécuter une version du talkdémon, en utilisant un socket Unix.

Information originale de Lennart Poettering

Notez que la liste de contrôle de Poettering ci-dessous indique que /tmpcela serait utile pour les "petits fichiers", alors /runqu'il ne devrait être utilisé que pour les "primitives de communication". Je ne pense pas que cette distinction soit vraie non plus. Le posteur pour /runest udev, et je suis à peu près sûr, /run/udevinclut des bases de données internes. Une fois que vous avez un /runrépertoire, je ne pense pas que quiconque veuille suivre la distinction revendiquée et créer un autre répertoire, pour encombrer /tmp. Donc, en pratique, nous utilisons simplement de /runnos jours.

L'utilisation d'espaces de noms partagés en écriture [comme / tmp] à des fins de communication a toujours été problématique, car pour établir une communication, vous avez besoin de noms stables, mais des noms stables ouvrent la porte aux attaques par déni de service. Cela peut être corrigé partiellement en établissant des répertoires protégés par application pour certains services lors du démarrage initial (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écurisés, en isolant les espaces de noms / tmp des différents services.

...

Etant donné que / tmp n'est plus nécessairement un espace de noms partagé, il ne convient généralement pas comme emplacement pour les primitives de communication.

...

[/ run] est garanti d'être un fichier tmpfs et est donc automatiquement vidé lors du démarrage. Aucun nettoyage automatique n'est fait au-delà de cela.

...

Voici un guide approximatif sur la façon dont nous vous suggérons (développeur d'applications Linux) de choisir le bon répertoire à utiliser:

1. Vous avez besoin d'un emplacement pour placer votre socket (ou une autre primitive de communication) et votre code est privilégié: utilisez un sous-répertoire sous / run. (Ou sous / var / run pour une compatibilité accrue.)
2. Vous avez besoin d'un emplacement pour placer votre socket (ou une autre primitive de communication) et votre code est exécuté sans privilège: utilisez un sous-répertoire situé sous $ XDG_RUNTIME_DIR.
3. Vous avez besoin d'un emplacement pour mettre vos téléchargements les plus volumineux et en cours et exécuter sans privilèges: utilisez $ XDG_DOWNLOAD_DIR.
4. 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.
5. Rien de ce qui précède ne s'applique et vous devez placer un petit fichier qui ne nécessite aucune persistance: utilisez $ TMPDIR avec un repli sur / tmp. Et utilisez mkstemp (), et mkdtemp () et rien chez vous.
6. Sinon, utilisez $ TMPDIR avec un repli sur / var / tmp. Utilisez également mkstemp () / mkdtemp ().

Notez que ces règles ci-dessus ne sont suggérées que par nous. Ces règles prennent en compte tout ce que nous savons sur ce sujet et évitent les problèmes liés aux distributions actuelles et futures, dans la mesure où nous pouvons les voir. Pensez à mettre à jour vos projets pour suivre ces règles, et gardez-les à l'esprit si vous écrivez un nouveau code.

Une chose sur laquelle nous voudrions insister est que / tmp et / var / tmp ne sont pas le plus souvent 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 peut en fait être le meilleur endroit. Donc, soyez prudent, considérez les autres options, mais si vous choisissez / tmp ou / var / tmp, assurez-vous au moins d’utiliser mkstemp () / mkdtemp ().

Nous nous débrouillons un peu avec le /tmpsocket hérité utilisé par le système X Window, comme décrit ci-dessus. J'ai mal lu tmpfiles.d/x11.conf. On dirait plus que ça dépend de la coopération :). Je suppose que le code a été vérifié, de sorte que le déni de service est le pire qui puisse arriver.

Les annuaires /tmpet /usr/tmp(plus tard /var/tmp) étaient le dépotoir pour tout et pour tout le monde. Le seul mécanisme de protection des fichiers de ces répertoires est le "sticky bit" qui limite la suppression ou le changement de nom des fichiers à leurs propriétaires. Comme l'a souligné marcelm dans un commentaire, rien n'empêche en principe de créer des fichiers avec des noms utilisés par des services (tels que nginx.pidou sshd.pid). (Cependant, dans la pratique, les scripts de démarrage peuvent supprimer d’abord ces faux fichiers.)

/runa é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 /tmpet les tâches qui y sont nettoyées. En effet: deux distributions que je lance (sans jeu de mots) ont des autorisations 755 sur /run, tandis que /tmpet /var/tmp(et /dev/shmd'ailleurs) ont des autorisations 1777.

/tmpest l'emplacement de création des fichiers temporaires et des répertoires. Il n'est pas utilisable pour stocker des "noms connus" (c'est-à-dire des noms dont un autre processus peut avoir connaissance sans que vous ayez à lui transmettre le nom) parce que personne n'est propriétaire 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 nécessitant un fichier (c.-à-d. Pas un tuyau) comme entrée ou sortie, où tout nom (généré aléatoirement) fonctionnera aussi longtemps que vous le passerez.

Historiquement, certaines choses (comme X) ont violé ce principe et ont mis des noms connus (comme .X11-unix) dans /tmp. Ceci est bien sûr bogué et permet à tout utilisateur de créer un fichier avec le nom souhaité en premier. De telles choses appartiennent à /run(ou équivalent /var/runsi vous ne vous abonnez pas au révisionnisme Freedesktop.org). Bien sûr, il serait même préférable de les empêcher de ne pas utiliser de noms connus dans un espace de noms global, mais plutôt de les contourner.

Selon la norme de hiérarchie du système de fichiers,

• /run est pour les données variables d'exécution c.-à-d. des informations sur le système en cours depuis le redémarrage
• /tmp est un endroit générique pour les fichiers temporaires.

Ainsi, tout ce qui concerne l'état du démon, les utilisateurs connectés, les périphériques amovibles montés, etc. serait inséré pendant /runque les fichiers temporaires créés par un programme y seraient insérés /tmp.

Edit: comme l'a souligné @JdeBP dans le commentaire ci-dessous,

La FHS permet, par exemple, la configuration classique de tâches cron qui purgent régulièrement les /tmp"anciens" fichiers; sans de tels mécanismes destinés à /run. D'où la limite draconienne à ce que les programmes peuvent attendre de la durée de vie de tout ce qui est mis en place /tmp. Alors que les programmes peuvent s’attendre à ce que les fichiers durent plus longtemps /runsur un système continuellement en place, ils sont également censés s’organiser davantage après eux-mêmes.