ディレクトリ /tmp と /usr/tmp (後で /var/tmp ) は、すべての人のゴミ捨て場でした。これらのディレクトリ内のファイルに対する唯一の保護メカニズムは、ファイルの削除または名前変更を所有者に制限するスティッキー ビットです。 marcelm がコメントで指摘したように、原則として、サービスで使用される名前 (nginx.pid など) のファイルを誰かが作成することを妨げるものは何もありません。 または sshd.pid ）。 (ただし、実際には、起動スクリプトはそのような偽のファイルを最初に削除できます。)
/run ロック、ソケット、pid ファイルなどの長期サービスの非永続的なランタイム データ用に確立されました。公開されていないため、/tmp の混乱からサービス ランタイム データを保護します。 そしてそこをきれいにする仕事。確かに:私が実行している 2 つのディストリビューション (しゃれた意図はありません) には、/run に対する権限 755 があります。 、 /tmp の間 そして /var/tmp (そして /dev/shm さらに言えば) パーミッション 1777 を持っています。
/tmp 一時ファイルとディレクトリを作成する場所です。名前空間の所有者は誰もいないため、「よく知られている名前」（つまり、別のプロセスに名前を伝えなくても認識できる名前）の保存には使用できません。誰でもそこでファイルを作成できます。そのため、通常、入力または出力としてファイル (つまり、パイプなどではない) を必要とするユーティリティがある場合に使用します。この場合、名前を渡す限り、(ランダムに生成された) 名前が機能します。
歴史的に、いくつかのもの (X など) はこの原則に違反し、よく知られている名前 (.X11-unix など) を付けました。 ) /tmp で .もちろんこれにはバグがあり、最初に目的の名前でファイルを作成するために競争するだけで、必要なサービスを DoS することができます。そのようなものは /run に属します (または同等の /var/run Freedesktop.org の修正主義に加入していない場合)。もちろん、グローバル名前空間でよく知られている名前を使用せず、代わりにパス名を渡すように修正することをお勧めします。
/run と /tmp の両方を使用する理由はありません
私はあなたが正しいと思います。 /tmp /run ができたので、基本的に非推奨です .あなたのプログラムがそうする立場にある場合 (これには、インストール済み である必要があります) 特権操作として)、最近では /run のサブディレクトリを使用します .これはセキュリティ上の理由によるものです。
例えば。 CUPS 印刷デーモンはルートとして実行されませんが、通常は OS パッケージからインストールされます。パッケージは /usr/lib/tmpfiles.d/cups.conf をインストールします 、および systemd-tmpfiles アクセスできるディレクトリを作成します。ディレクトリは /run の下にあるため 、/tmp とは異なり、特権のないユーザーによって悪意を持って名前が要求された可能性はありません 誰でも書き込み可能です。
/run を使用できない「非特権プログラム」 直接
実際の違いは、プログラムが任意の非特権ユーザーによって、独自のユーザー ID で実行されている場合です。しかし、一般的に /tmp は使いたくないでしょう 、権限のない他のユーザーがアクセスできるためです。 $XDG_RUNTIME_DIR を使用することをお勧めします .通常、これは /run/user/$(id -u) として実装されます - /run のサブディレクトリになります 同じように。ただし、場所は保証されていません。プログラムは常に環境変数を使用する必要があります。
/tmp システム上の異なる非特権ユーザー間のアドホックな協力にのみ役立ちます。このようなアドホック システムは、悪意のあるユーザーが協力することを拒否し、すべての人のために物事を台無しにすることに対して脆弱です:)。 1 つの例として、権限のないユーザーが talk のバージョンを実行することを決定することがあります。 デーモン、UNIX ソケットを使用。
Lennart Poettering による元の情報
以下の Poettering のチェックリストでは、/tmp と主張されていることに注意してください。 /run に対して、「小さなファイル」に役立ちます。 「通信プリミティブ」にのみ使用する必要があります。私もこの区別は正しくないと思います。 /runのポスターボーイ udev です 、そして私は /run/udev と確信しています 内部データベースが含まれます。 /run を取得したら ディレクトリ、主張されている区別に従って別のを作成したいと思う人はいないと思います /tmp を乱雑にするディレクトリ .したがって、実際には /run を使用するだけです
誰でも書き込み可能な [/tmp のような] 共有名前空間を通信目的で使用することには、常に問題がありました。通信を確立するには安定した名前が必要ですが、安定した名前は DoS 攻撃の扉を開くからです。これは、初期起動時に特定のサービス用に保護されたアプリごとのディレクトリを確立することで (X11 の場合のように) 部分的に修正できますが、これは問題を部分的にしか修正しません。これは、すべてのパッケージのインストールの後に再起動が続く場合にのみ正しく機能するためです。
...
<ブロック引用>別の Fedora 機能 (Fedora 17 用) は、さまざまなサービスの /tmp 名前空間を分離することにより、多くのシステム サービスの /tmp のセマンティクスをより安全にするように変更しました
...
<ブロック引用>/tmp は必ずしも共有名前空間ではないため、通常、通信プリミティブの場所としては不適切です。
...
<ブロック引用>[/run] は tmpfs であることが保証されているため、起動時に自動的にフラッシュされます。それ以上の自動クリーンアップは行われません。
...
<ブロック引用>以下は、Linux アプリケーション開発者が使用する適切なディレクトリを選択する方法をおおまかに示したものです。
<オール>上記のこれらの規則は、私たちが提案したものに過ぎないことに注意してください。これらのルールは、このトピックについて私たちが知っているすべてを考慮に入れ、現在および将来のディストリビューションの問題を回避します。これらの規則に従うようにプロジェクトを更新することを検討してください。また、新しいコードを作成する場合は、それらを念頭に置いてください。
強調したいことの 1 つは、多くの場合、/tmp と /var/tmp は実際にはユースケースに適した選択ではないということです。これらのディレクトリには有効な用途がありますが、実際には別のディレクトリの方が適切な場合がよくあります。したがって、注意して他のオプションを検討してください。ただし、/tmp または /var/tmp を使用する場合は、少なくとも mkstemp()/mkdtemp() を使用してください。
従来の /tmp を使いこなす 上記のように、X ウィンドウ システムで使用されるソケット。tmpfiles.d/x11.conf を読み間違えました .協力に依存しているように見えます:)。サービス拒否が起こりうる最悪の事態であるように、コードは監査されていると思います。