Qual è la differenza tra / tmp e / run?

Secondo FHS-3.0 , /tmpè per file temporanei ed /runè per dati variabili di runtime. I dati in /rundevono essere cancellati al prossimo avvio, cosa che non è richiesta /tmp, ma i programmi non devono presumere che i dati in /tmpsaranno disponibili al prossimo avvio del programma. Tutto questo mi sembra abbastanza simile.

Quindi, qual è la differenza tra i due? In base a quale criterio un programma dovrebbe decidere se inserire /tmpo inserire dati temporanei /run?

Secondo la FHS:

I programmi possono avere una sottodirectory di /run; questo è consigliato per i programmi che usano più di un file di runtime.

Ciò indica che la distinzione tra "programmi di sistema" e "programmi ordinari" non è un criterio, né la durata del programma (come il processo di lunga durata rispetto a quello di breve durata).

Sebbene la seguente logica non sia fornita nell'FHS, è /runstata introdotta per superare il problema che /varera stato montato troppo tardi in modo tale che erano necessari trucchi sporchi per renderli /var/rundisponibili abbastanza presto. Tuttavia, ora con /runl'introduzione e data la sua descrizione nell'FHS, non sembra esserci una chiara ragione per avere entrambi /rune /tmp.

Nessun motivo per avere sia / run che / tmp

Penso tu abbia ragione. /tmpè sostanzialmente deprecato ora che abbiamo /run. Se il tuo programma è in grado di farlo (il che richiede che sia stato installato come operazione privilegiata), allora oggi useresti una sottodirectory di /run. Questo per motivi di sicurezza.

Ad esempio, il demone di stampa CUPS non funziona come root, ma è generalmente installato da un pacchetto del sistema operativo. Il pacchetto si installa /usr/lib/tmpfiles.d/cups.confe systemd-tmpfilescrea una directory a cui può accedere. Poiché la directory è sotto /run, il nome non può essere stato rivendicato maliziosamente da un utente non privilegiato, a differenza del /tmpquale è scrivibile in tutto il mondo.

"Programmi senza privilegi" che non possono essere utilizzati /rundirettamente

La vera distinzione è se il tuo programma è gestito da un utente arbitrario senza privilegi, con il proprio ID utente. Ma in genere non si desidera utilizzare /tmp, poiché è possibile accedervi da altri utenti non privilegiati. Preferiresti usare $XDG_RUNTIME_DIR. In genere questo è implementato come /run/user/$(id -u)- quindi sembra essere anche una sottodirectory di /run. La posizione non è garantita però; i programmi dovrebbero sempre usare la variabile d'ambiente.

/tmpsarebbe utile solo per la cooperazione ad hoc tra diversi utenti non privilegiati sul sistema. Tali sistemi ad hoc sono vulnerabili a un utente malintenzionato che rifiuta di cooperare e viziare le cose per tutti :). Un esempio potrebbe essere rappresentato dagli utenti non privilegiati che decidono di eseguire una versione del talkdemone, utilizzando un socket unix.

Informazioni originali da Lennart Poettering

Si noti che la seguente lista di controllo di Poettering sosteneva che /tmpsarebbe utile per "piccoli file", mentre /rundovrebbe essere usata solo per "primitive di comunicazione". Non penso che questa distinzione sia vera. Il poster-boy /runè udev, e sono quasi sicuro che /run/udevincluda database interni. Una volta che hai una /rundirectory, non penso che nessuno voglia seguire la distinzione dichiarata e creare un'altra directory, per ingombrare /tmp. Quindi in pratica usiamo solo al /rungiorno d'oggi.

L'uso di spazi dei nomi condivisi scrivibili in tutto il mondo [like / tmp] per scopi di comunicazione è sempre stato problematico, poiché per stabilire la comunicazione sono necessari nomi stabili, ma i nomi stabili aprono le porte agli attacchi DoS. Questo può essere corretto parzialmente, stabilendo directory per-app protette per determinati servizi durante l'avvio anticipato (come facciamo per X11), ma questo risolve solo parzialmente il problema, poiché funziona correttamente solo se ogni installazione di pacchetto è seguita da un riavvio.

...

Un'altra funzione di Fedora (per Fedora 17) ha cambiato la semantica di / tmp per molti servizi di sistema per renderli più sicuri, isolando gli spazi dei nomi / tmp dei vari servizi

...

Poiché / tmp non è più necessariamente uno spazio dei nomi condiviso, generalmente non è adatto come posizione per le primitive di comunicazione.

...

[/ run] è garantito per essere un tmpfs ed è quindi automaticamente scaricato agli stivali. Non viene eseguita alcuna pulizia automatica oltre a ciò.

...

Ecco una breve guida su come ti consigliamo (uno sviluppatore di applicazioni Linux) di scegliere la directory giusta da usare:

1. Hai bisogno di un posto dove mettere il tuo socket (o altra primitiva di comunicazione) e il tuo codice viene privilegiato: usa una sottodirectory sotto / run. (O sotto / var / run per una maggiore compatibilità.)
2. Hai bisogno di un posto dove mettere il tuo socket (o altra primitiva di comunicazione) e il tuo codice viene eseguito senza privilegi: usa una sottodirectory sotto $ XDG_RUNTIME_DIR.
3. Hai bisogno di un posto per mettere in atto i tuoi download e download più grandi ed eseguire senza privilegi: usa $ XDG_DOWNLOAD_DIR.
4. Hai bisogno di un posto dove mettere i file della cache che dovrebbero essere persistenti e funzionare senza privilegi: usa $ XDG_CACHE_HOME.
5. Nulla di quanto sopra si applica e devi inserire un piccolo file che non ha bisogno di persistenza: usa $ TMPDIR con un fallback su / tmp. E usa mkstemp (), e mkdtemp () e niente di fatto in casa.
6. Altrimenti usa $ TMPDIR con un fallback su / var / tmp. Usa anche mkstemp () / mkdtemp ().

Nota che queste regole sopra sono solo suggerite da noi. Queste regole tengono conto di tutto ciò che sappiamo su questo argomento ed evitano problemi con le distribuzioni attuali e future, per quanto possiamo vederle. Ti consigliamo di aggiornare i tuoi progetti per seguire queste regole e tienili a mente se scrivi un nuovo codice.

Una cosa che vorremmo sottolineare è che / tmp e / var / tmp il più delle volte non sono in realtà la scelta giusta per il tuo caso d'uso. Esistono usi validi di queste directory, ma molto spesso un'altra directory potrebbe effettivamente essere il posto migliore. Quindi, fai attenzione, considera le altre opzioni, ma se usi / tmp o / var / tmp, almeno assicurati di usare mkstemp () / mkdtemp ().

In un certo senso ci scappiamo con il /tmpsocket legacy utilizzato dal sistema X Window, come descritto sopra. Ho letto male tmpfiles.d/x11.conf. Sembra più che si basi sulla cooperazione :). Presumo che il codice sia stato verificato, in modo tale che la negazione del servizio sia la cosa peggiore che possa accadere.

Le directory /tmpe /usr/tmp(in seguito /var/tmp) erano la discarica di tutto e tutti. L'unico meccanismo di protezione per i file in queste directory è il bit appiccicoso che limita la cancellazione o la ridenominazione dei file lì ai loro proprietari. Come ha sottolineato Marcelm in un commento, in linea di principio nulla impedisce a qualcuno di creare file con nomi utilizzati dai servizi (come nginx.pido sshd.pid). (In pratica, gli script di avvio potrebbero rimuovere prima tali file fasulli.)

/runè stato stabilito per i dati di runtime non persistenti di servizi di lunga durata come blocchi, socket, file pid e simili. Dal momento che non è scrivibile per il pubblico, protegge i dati di runtime del servizio dalla confusione /tmpe dai lavori che vengono ripuliti. In effetti: due distribuzioni che eseguo (nessun gioco di parole previsto) dispongono delle autorizzazioni 755 /run, mentre /tmpe /var/tmp(e del resto /dev/shm) hanno le autorizzazioni 1777.

/tmpè la posizione per la creazione di file e directory temporanei. Non è utilizzabile per la memorizzazione di "nomi noti" (ovvero nomi di cui un altro processo potrebbe essere a conoscenza senza che tu debba comunicargli il nome in qualche modo) perché nessuno ha proprietà sullo spazio dei nomi; chiunque può creare file lì. Come tale, lo usi generalmente quando hai un'utilità che ha bisogno di un file (cioè non una pipe o simile) come input o output, in cui qualsiasi nome (generato casualmente) funzionerà finché passerai il nome.

Storicamente, alcune cose (come X) hanno violato questo principio e inserito nomi noti (come .X11-unix) /tmp. Questo è ovviamente buggy e consente a qualsiasi utente di fare il servizio necessario semplicemente correndo per creare prima un file con il nome desiderato. Tali cose appartengono /run(o equivalentemente /var/runse non ti abboni al revisionismo di Freedesktop.org). Naturalmente sarebbe ancora meglio sistemarli per non usare nomi noti in uno spazio dei nomi globale, ma invece passare un percorso.

Secondo il Filesystem Hierarchy Standard,

• /run è per i dati delle variabili di runtime, ovvero le informazioni sul sistema in esecuzione dal riavvio
• /tmp è un posto generico per i file temporanei.

Quindi qualsiasi cosa riguardante lo stato del demone, gli utenti che hanno effettuato l'accesso, i dispositivi rimovibili montati ecc. Entrerebbe /runmentre entrerebbero i file temporanei creati da un programma /tmp.

Modifica: come sottolineato da @JdeBP nel commento qui sotto,

L'FHS consente cose come l'installazione convenzionale di cron job che eliminano regolarmente i /tmp"vecchi" file; senza tali meccanismi previsti /run. Da qui il limite draconiano su ciò che i programmi possono aspettarsi dalla vita di qualsiasi cosa venga inserita /tmp. Mentre i programmi possono aspettarsi che i file vivano più a lungo /runsu un sistema in continuo aumento, ci si aspetta anche che li riordinino di più.