共有ディレクトリで他ユーザーのファイルを勝手に削除されない権限設定

まず結論：/tmp は「誰でも書けるが自分のファイルしか消せない」設計になっている

/tmp を ls -ld で確認すると、末尾に t が付いたパーミッションが表示されます。

$ ls -ld /tmp
drwxrwxrwt 20 root root 4096 Jul 20 09:15 /tmp

rwxrwxrwt の末尾の t が「スティッキービット」です。これが付いているディレクトリでは、書き込み権限（w）があっても他ユーザーのファイルは削除できません。削除できるのはそのファイルの所有者と root のみです。

同じ仕組みを自前の共有ディレクトリに適用するには、chmod +t または chmod 1777 を使います。この記事では確認・設定・実務上の注意点を順に説明します。

スティッキービットがないと何が起きるか

共有ディレクトリを単純に chmod 777 にした場合の挙動を確認します。

# root で共有ディレクトリを作成（スティッキービットなし）
$ sudo mkdir /shared
$ sudo chmod 777 /shared

# ユーザー alice がファイルを作成
alice$ touch /shared/alice_data.txt

# ユーザー bob がそのファイルを削除できてしまう
bob$ rm /shared/alice_data.txt
# エラーなく削除される

書き込み権限は「そのディレクトリへの書き込み」なので、ディレクトリ内のファイルを削除する操作にも適用されます。全員書き込み可のディレクトリでは、悪意のあるユーザーや操作ミスによって他人のファイルが消えるリスクがあります。

スティッキービットを設定して共有ディレクトリを作る

スティッキービットの設定は2通りあります。既存ディレクトリへの追加なら +t、新規作成時にまとめて指定するなら数値モードが簡潔です。

# 方法1：既存ディレクトリに追加
$ sudo chmod +t /shared

# 方法2：数値モードで一括指定（1=スティッキービット, 777=全員rwx）
$ sudo chmod 1777 /shared

# 確認
$ ls -ld /shared
drwxrwxrwt 2 root root 4096 Jul 20 09:20 /shared

設定後の動作を確認します。

# ユーザー alice がファイルを作成
alice$ touch /shared/alice_data.txt

# ユーザー bob が削除しようとすると拒否される
bob$ rm /shared/alice_data.txt
rm: cannot remove '/shared/alice_data.txt': Operation not permitted

# alice 自身は削除できる
alice$ rm /shared/alice_data.txt
# 成功

パーミッション表示で t が大文字の T になっている場合は、スティッキービットは設定されているものの、その他ユーザーへの実行権限（x）がない状態です。通常の共有ディレクトリでは t（小文字）になるよう 1777 を指定してください。

現代のLinuxにおける /tmp の実態

Ubuntu 22.04以降やFedora、AlmaLinux 9などの現代的なディストリビューションでは、/tmp はディスク上のディレクトリではなく tmpfs（メモリ上のファイルシステム） としてマウントされているケースが主流です。

$ findmnt /tmp
TARGET SOURCE FSTYPE OPTIONS
/tmp   tmpfs  tmpfs  rw,nosuid,nodev,nr_inodes=1048576

# または
$ mount | grep /tmp
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,nr_inodes=1048576)

再起動のたびに内容が消える点は従来と同じですが、管理は systemd-tmpfiles が担っています。/tmp のパーミッションも systemd-tmpfiles の設定（/usr/lib/tmpfiles.d/tmp.conf）によって起動時に 1777 に復元されます。

$ cat /usr/lib/tmpfiles.d/tmp.conf
# 抜粋
d /tmp 1777 root root -

つまり、/tmp のスティッキービットを手動で外しても、次回再起動時には元に戻ります。永続的に変更したい場合は /etc/tmpfiles.d/ にオーバーライド用の設定ファイルを置く必要があります（ただし通常そのような変更は不要です）。

また、再起動をまたいで残したいファイルには /tmp ではなく /var/tmp を使います。こちらもスティッキービット付き（drwxrwxrwt）で、再起動後も内容が保持されます。

実務でよくある落とし穴

root は常に削除できる

スティッキービットは一般ユーザー間の削除を制限するものです。root には適用されません。サーバー管理者が意図せず rm -rf /tmp/* などを実行した場合は、スティッキービットに関わらず全ファイルが削除されます。本番サーバーでの rm -rf は対象パスを必ずダブルチェックしてください。

ディレクトリ自体のリネーム・移動は別の話

スティッキービットが保護するのは「ファイルの削除とリネーム」です。ファイルの内容の変更（書き込み）は通常の書き込み権限で制御されます。ファイルの中身を上書きされたくない場合は、ファイル自体のパーミッションを別途設定する必要があります。

NFS マウントされた共有ディレクトリでの注意

NFSでマウントした共有ディレクトリにスティッキービットを設定しても、NFSサーバー側の設定（no_root_squash 等）によっては期待どおりに動作しない場合があります。NFS越しの共有ディレクトリでこの仕組みを使う場合は、実際の挙動を確認してから本番適用してください。

設定のチェックリスト

共有ディレクトリにスティッキービットを設定する際の確認手順をまとめます。

# 1. ディレクトリのパーミッション確認
ls -ld /対象ディレクトリ

# 2. スティッキービット設定（末尾が t になっていなければ）
sudo chmod 1777 /対象ディレクトリ

# 3. 再確認
ls -ld /対象ディレクトリ
# drwxrwxrwt ... と表示されれば設定完了

# 4. 別ユーザーで実際に削除できないことを確認
# （本番投入前に必ずテストユーザーで動作確認する）

ある運用現場では、開発チームが共有する一時作業ディレクトリを chmod 777 のまま運用していたところ、スクリプトの誤動作で別チームのファイルが消える事故が発生しました。chmod 1777 に変更してスティッキービットを追加したことで、以降は同様の事故が発生しなくなっています。複数ユーザーが書き込む共有ディレクトリを作成する際は、1777 をデフォルトの選択肢として検討してください。