Jaka jest różnica między / tmp a / run?

Według FHS-3.0 , /tmpto pliki tymczasowe i /runjest dla danych zmiennej run-time. Dane /runwejściowe należy usunąć przy następnym uruchomieniu, co nie jest wymagane /tmp, ale programy nie mogą zakładać, że dane /tmpwejściowe będą dostępne przy następnym uruchomieniu programu. Wszystko to wydaje mi się bardzo podobne.

Jaka jest różnica między nimi? Według jakich kryteriów program powinien decydować, czy dane tymczasowe mają być wprowadzane do /tmpczy do /run?

Według FHS:

Programy mogą mieć podkatalog /run; jest to zalecane w przypadku programów, które używają więcej niż jednego pliku wykonawczego.

Wskazuje to, że rozróżnienie między „programami systemowymi” a „zwykłymi programami” nie jest kryterium, podobnie jak czas życia programu (np. Proces długo- i krótkotrwały).

Chociaż w FHS nie podano następującego uzasadnienia, /runwprowadzono go w celu rozwiązania problemu, który /varzostał zamontowany zbyt późno, tak że potrzebne były brudne sztuczki, aby /var/runudostępnić je odpowiednio wcześnie. Teraz jednak, z /runwprowadzeniem, a biorąc pod uwagę jego opis w FHS, nie wydaje się być jasny powód, aby mieć zarówno /runi /tmp.

Nie ma powodu, aby mieć zarówno / run, jak i / tmp

Myślę, że masz rację. /tmpjest zasadniczo przestarzałe, teraz mamy /run. Jeśli twój program jest w stanie to zrobić (co wymaga, aby został zainstalowany jako operacja uprzywilejowana), to w dzisiejszych czasach używałbyś podkatalogu /run. Jest to ze względów bezpieczeństwa.

Np. Demon drukowania CUPS nie działa jako root, ale zazwyczaj jest instalowany z pakietu systemu operacyjnego. Pakiet instaluje się /usr/lib/tmpfiles.d/cups.confi systemd-tmpfilestworzy katalog, do którego może uzyskać dostęp. Ponieważ katalog jest pod /run, nazwa nie może zostać złośliwie zgłoszona przez nieuprzywilejowanego użytkownika, w przeciwieństwie do tego, /tmpco można zapisać na całym świecie.

„Nieuprzywilejowane programy”, których nie można używać /runbezpośrednio

Prawdziwe rozróżnienie polega na tym, że twój program jest uruchamiany przez dowolnego, nieuprzywilejowanego użytkownika, pod własnym identyfikatorem użytkownika. Ale nadal ogólnie nie chcesz z niego korzystać /tmp, ponieważ może być dostępny dla innych nieuprzywilejowanych użytkowników. Wolisz używać $XDG_RUNTIME_DIR. Zazwyczaj jest to realizowane jako /run/user/$(id -u)- tak więc zdarza się, że jest to również podkatalog /run. Lokalizacja nie jest jednak gwarantowana; programy powinny zawsze używać zmiennej środowiskowej.

/tmpprzydałby się tylko do współpracy ad hoc między różnymi nieuprzywilejowanymi użytkownikami systemu. Takie systemy ad-hoc są podatne na ataki złośliwego użytkownika, który odmawia współpracy i psuje rzeczy wszystkim :). Jednym z przykładów byliby nieuprzywilejowani użytkownicy decydujący się na uruchomienie wersji talkdemona przy użyciu gniazda unix.

Oryginalne informacje z Lennart Poettering

Uwaga: poniższa lista kontrolna Poetteringa twierdziła, że /tmpbyłaby przydatna w przypadku „małych plików”, podczas gdy /runpowinna być używana tylko w przypadku „prymitywów komunikacyjnych”. Nie sądzę też, aby to rozróżnienie było prawdziwe. Chłopiec-plakat dla /runjest udevi jestem pewien, że /run/udevzawiera wewnętrzne bazy danych. Kiedy już masz /runkatalog, nie sądzę, że ktoś chce postępować zgodnie z domniemanym rozróżnieniem i stworzyć inny katalog, żeby się bałagać /tmp. Tak więc w praktyce używamy tylko w /rundzisiejszych czasach.

Użycie współdzielonych na całym świecie przestrzeni nazw [jak / tmp] do celów komunikacyjnych zawsze było problematyczne, ponieważ do nawiązania komunikacji potrzebujesz stabilnych nazw, ale stabilne nazwy otwierają drzwi do ataków DoS. Można to częściowo naprawić, ustanawiając chronione katalogi aplikacji dla niektórych usług podczas wczesnego rozruchu (tak jak w przypadku X11), ale to tylko częściowo rozwiązuje problem, ponieważ działa to poprawnie tylko wtedy, gdy po każdej instalacji pakietu następuje restart.

...

Inna funkcja Fedory (dla Fedory 17) zmieniła semantykę / tmp dla wielu usług systemowych, aby uczynić je bardziej bezpiecznymi, izolując przestrzenie nazw / tmp różnych usług

...

Ponieważ / tmp niekoniecznie jest już współużytkowaną przestrzenią nazw, zasadniczo nie nadaje się jako lokalizacja dla operacji podstawowych.

...

[/ run] z pewnością jest tmpfs i dlatego jest automatycznie opróżniany przy rozruchu. Poza tym nie wykonuje się automatycznego czyszczenia.

...

Oto ogólny przewodnik, w jaki sposób sugerujemy Ci (twórcy aplikacji dla systemu Linux) wybrać odpowiedni katalog do użycia:

1. Potrzebujesz miejsca, w którym umieścisz swoje gniazdo (lub inny prymityw komunikacyjny), a twój kod działa uprzywilejowany: użyj podkatalogu poniżej / run. (Lub poniżej / var / run dla dodatkowej kompatybilności.)
2. Potrzebujesz miejsca, w którym umieścisz swoje gniazdo (lub inny podstawowy element komunikacji), a Twój kod będzie działał nieuprzywilejowany: użyj podkatalogu poniżej $ XDG_RUNTIME_DIR.
3. Potrzebujesz miejsca, w którym będziesz mógł pobierać i pobierać większe pliki oraz uruchamiać je bez uprawnień: użyj $ XDG_DOWNLOAD_DIR.
4. Potrzebujesz miejsca do umieszczenia plików pamięci podręcznej, które powinny być trwałe i działać nieuprzywilejowane: użyj $ XDG_CACHE_HOME.
5. Żadne z powyższych nie ma zastosowania i musisz umieścić mały plik, który nie wymaga trwałości: użyj $ TMPDIR z rezerwowym na / tmp. I używaj mkstemp () i mkdtemp () i nic domowego.
6. W przeciwnym razie użyj $ TMPDIR z rezerwowym na / var / tmp. Użyj także mkstemp () / mkdtemp ().

Pamiętaj, że powyższe zasady są tylko sugerowane przez nas. Reguły te uwzględniają wszystko, co wiemy na ten temat i unikają problemów z obecnymi i przyszłymi dystrybucjami, o ile je widzimy. Zastanów się nad aktualizacją swoich projektów, aby postępować zgodnie z tymi regułami i pamiętaj o nich, jeśli napiszesz nowy kod.

Jedną rzeczą, na którą chcielibyśmy podkreślić, jest fakt, że / tmp i / var / tmp częściej nie są właściwym wyborem dla twojej skrzynki użytkownika. Istnieją prawidłowe zastosowania tych katalogów, ale całkiem często inny katalog może być lepszym miejscem. Więc bądź ostrożny, rozważ inne opcje, ale jeśli wybierzesz / tmp lub / var / tmp, to przynajmniej upewnij się, że używasz mkstemp () / mkdtemp ().

W pewnym sensie uciekamy od starszego /tmpgniazda używanego przez system okien X, jak opisano powyżej. Źle odczytałem tmpfiles.d/x11.conf. Wygląda na to, że polega na współpracy :). Zakładam, że kod został poddany audytowi, dlatego odmowa usługi jest najgorszym z możliwych.

Katalogi /tmpi /usr/tmp(później /var/tmp) były wysypiskiem śmieci dla wszystkich i dla wszystkich. Jedynym mechanizmem ochrony plików w tych katalogach jest lepki bit, który ogranicza usuwanie lub zmianę nazwy plików tam na ich właścicieli. Jak zauważył marcelm w komentarzu, w zasadzie nic nie stoi na przeszkodzie, aby ktoś utworzył pliki o nazwach używanych przez usługi (takie jak nginx.pidlub sshd.pid). (W praktyce skrypty startowe mogą jednak najpierw usunąć takie fałszywe pliki).

/runzostała utworzona dla nietrwałych danych wykonawczych usług długowiecznych, takich jak zamki, gniazda, pliki pid i tym podobne. Ponieważ nie jest dostępny do zapisu publicznego, chroni dane wykonawcze usługi przed bałaganem /tmpi zadaniami, które tam czyszczą. Rzeczywiście: Dwie dystrybucje, które uruchamiam (bez zamierzonej gry słów) mają uprawnienia na 755 /run, a /tmpi /var/tmp(i /dev/shmdo tego) mają uprawnienia 1777.

/tmpjest miejscem tworzenia tymczasowych plików i katalogów. Nie nadaje się do przechowywania „dobrze znanych nazw” (tj. Nazw, o których inny proces mógłby wiedzieć bez konieczności przekazywania nazwy), ponieważ nikt nie ma prawa własności do przestrzeni nazw; każdy może tam tworzyć pliki. Jako taki zazwyczaj używasz go, gdy masz narzędzie, które potrzebuje pliku (tj. Nie potoku lub takiego) jako danych wejściowych lub wyjściowych, w którym dowolna (losowo generowana) nazwa będzie działać tak długo, jak długo przekażesz nazwę.

Historycznie niektóre rzeczy (jak X) naruszały tę zasadę i wprowadzały znane nazwy (jak .X11-unix) /tmp. Jest to oczywiście błędne i pozwala każdemu użytkownikowi na wykonanie usługi DoS po prostu ścigając się, aby najpierw utworzyć plik o żądanej nazwie. Takie rzeczy należą /run(lub równoważnie, /var/runjeśli nie subskrybujesz rewizjonizmu Freedesktop.org). Oczywiście jeszcze lepiej byłoby naprawić je tak, aby nie używały dobrze znanych nazw w globalnej przestrzeni nazw, ale zamiast tego podawały nazwę ścieżki.

Zgodnie ze standardem hierarchii systemu plików,

• /run dotyczy danych zmiennych wykonawczych, tj. informacji o systemie uruchomionym od momentu ponownego uruchomienia
• /tmp to ogólne miejsce na pliki tymczasowe.

Tak więc wszystko, co dotyczy statusu demona, zalogowanych użytkowników, zamontowanych urządzeń wymiennych itp. /run, Wchodziłoby do plików tymczasowych utworzonych przez program /tmp.

Edycja: jak wskazał @JdeBP w komentarzu poniżej,

FHS pozwala na takie rzeczy jak konwencjonalna konfiguracja zadań cron, które regularnie usuwają /tmp„stare” pliki; bez takich mechanizmów przeznaczonych do /run. Stąd drakoński limit tego, czego programy mogą oczekiwać od czasu życia wszystkiego, co się pojawi /tmp. Chociaż programy mogą oczekiwać, że pliki będą dłużej żyły w /runsystemie działającym w trybie ciągłym, oczekuje się również, że będą je porządkować.