こんにちは!Linuxを扱っていると、rwx(読み取り/書き込み/実行)だけでは説明できない奇妙な権限に遭遇することがあります。
「なぜ自分のパスワードは自分で変更できるのに、/etc/shadowファイルはrootしか見られないのだろう?」
「共有フォルダで自分が作ったファイルを、なぜ他の人が削除できるのだろう?」
これらすべての疑問の答えは、まさに特殊権限(Special Permissions)にあります。今日は、システムエンジニアやセキュリティ担当者であれば必ず習得すべきSetUID、SetGID、Sticky Bitについて、非常に詳しく掘り下げていきます。☕ コーヒーを片手に、ゆっくりとついてきてください!

1. 🎭 SetUID: 「仮面舞踏会の始まり」
SetUID(Set User ID)は、Linuxの権限体系において最も強力でありながら、最も危険になりうる機能です。
💡 主要な概念
通常、プログラムを実行すると、そのプロセスは「実行した人」の権限で動作します。しかし、SetUIDが設定されたファイルは、「ファイルの所有者(Owner)」の権限で実行されます。まるで王の仮面をかぶると、一時的に王の権力を振るえるようなものです。
🔍 代表的な事例: passwd
パスワードを変更する際に使用するpasswdコマンドを見てみましょう。
$ ls -l /usr/bin/passwd
-rwsr-xr-x 1 root root 68208 ... /usr/bin/passwd
- 所有者: root
- 権限: rws(ここでsがSetUIDです!)
パスワード情報は/etc/shadowファイルに保存されますが、このファイルはrootのみが修正できます。
- 一般ユーザー(user1)がpasswdを実行します。
- SetUIDの設定により、プロセスは実行中に一時的にroot権限を獲得します。
- その権限で/etc/shadowを安全に修正し、終了します。
- プロセスが終了すると、権限は元の状態に戻ります。
⚙️ 設定方法
- シンボリックモード: chmod u+s ファイル名
- 数値モード: chmod 4755 ファイル名(先頭の4がSetUIDを意味します)
2. 🤝 SetGID: 「コラボレーションのためのスマートなルール」
SetGID(Set Group ID)は、ファイルに設定される場合とディレクトリに設定される場合とで、その動作が全く異なります。実務では主にディレクトリに設定して、コラボレーション環境を構築する際に使用されます。
📂 ディレクトリに設定されたSetGID(コラボレーションの核心)
複数の開発者が一つのプロジェクトフォルダを共有していると仮定してみましょう。
- 問題点: A開発者がファイルを作成すると、所有グループがdev-aとなり、B開発者はそのファイルを修正できない可能性があります。毎回権限を修正する手間が発生します。
- 解決策: プロジェクトディレクトリにSetGIDを設定します。
- このディレクトリ内に作成されるすべてのファイル/フォルダは、親ディレクトリのグループ所有権(Group Ownership)を自動的に継承します。
- 誰がファイルを作成してもグループが統一されるため、共有が円滑になります。
📄 ファイルに設定されたSetGID
SetUIDと似ています。実行時にファイルの所有グループの権限で実行されます。(SetUIDに比べて頻繁には使用されません。)
⚙️ 設定方法
- シンボリックモード: chmod g+s ディレクトリ名
- 数値モード: chmod 2775 ディレクトリ名(先頭の2がSetGIDを意味します)
- 確認: drwxr-sr-xのように、グループ実行権限の箇所にsが表示されます。
3. 🛡️ Sticky Bit: 「私のものは私だけが捨てられる」
名前の通り、粘り強く付着する権限です。主に共有ディレクトリの無秩序を防ぐために存在します。
💡 主要な概念
Linuxでは、ディレクトリに「書き込み(w)」権限があると、その中のファイルを削除することもできます。問題は、他人が作成したファイルも削除できてしまう点です。
Sticky Bitが設定されたディレクトリでは、「ファイルの所有者(およびroot)のみが、そのファイルを削除したり名前を変更したりできます。」
🔍 代表的な事例: /tmp
Linuxの一時保存場所である/tmpは、誰でもアクセスしてファイルを作成できる必要があります。
$ ls -ld /tmp
drwxrwxrwt 19 root root 4096 ... /tmp
- 権限: rwxrwxrwt(末尾のtがSticky Bitです。)
- すべてのユーザーがファイルを書き込めますが(w)、tが設定されているため、自分が作成した一時ファイルを他のユーザーが誤って(または意図的に)削除するのを防ぎます。
⚙️ 設定方法
- シンボリックモード: chmod o+t ディレクトリ名
- 数値モード: chmod 1777 ディレクトリ名(先頭の1がSticky Bitを意味します)
4. 🧮 詳細: 数値モードと大文字表記の秘密
特殊権限を完全に理解するには、この2つの詳細を見逃してはなりません。
1) 4桁数値モードの計算方法
chmodを使用する際に、3桁ではなく4桁の数字を見たことがありますか?
- 4000: SetUID
- 2000: SetGID
- 1000: Sticky Bit
例えば、chmod 4755は4000(SetUID)+ 755(rwxr-xr-x)が合わさったものです。
2) 大文字「S」と「T」の意味
ls -lの結果で、小文字のs、tではなく大文字のS、Tを見ることがあります。これは誤植ではありません!
- 小文字(s, t): 実行権限(x)がある状態で特殊権限が付与されている場合。(正常動作)
- 大文字(S, T): 実行権限(x)がない状態で特殊権限が付与されている場合。
- 例: rw-rw-r–ファイルにSetUIDを設定すると、rwSrw-r–になります。
- 意味: 「特殊権限は設定されているけれど、実行権限自体がないので実際には動作しないだろう」という警告表示のようなものです。
5. 🚨 セキュリティ管理者への助言
SetUIDはシステムセキュリティの最大の穴となり得ます。
- 危険性: もしbashシェルやvimエディタのようなプログラムに、誰かが密かにSetUID(root所有)を設定していたらどうなるでしょうか?
- 一般ユーザーがvimを起動した瞬間、root権限を持つことになり、システム上のすべてのファイルを修正できるようになります。これを権限昇格(Privilege Escalation)攻撃と呼びます。
- セキュリティチェックのヒント: 定期的にシステム内のすべてのSetUIDファイルを検索し、意図しないファイルがないか確認する必要があります。
# システム全体でSetUIDが設定されているファイルを見つける
find / -user root -perm -4000 -print 2>/dev/null
📝 要約整理表
| 区分 | 役割 | 表記位置 | 文字 | 数値 |
|---|---|---|---|---|
| SetUID | 実行時に所有者権限を獲得 | User | s | 4000 |
| SetGID | 実行時にグループ権限を獲得 / ディレクトリのグループ継承 | Group | s | 2000 |
| Sticky Bit | 共有フォルダで他人のファイル削除を防止 | Other | t | 1000 |
今日の内容がLinuxの権限体系を理解する上で大いに役立ったことを願っています。これら3つの特殊権限をうまく活用することで、システムのセキュリティとコラボレーションの効率性を同時に向上させることができます!
次回の投稿では、Linux ACL(Access Control List)について取り上げます。お読みいただきありがとうございました。🙇♂️
コメントを残す