[Linux] SUID、SGID、スティッキービット
はじめに
こんにちは。
プログラミング初心者wakinozaと申します。
勉強中に調べたことを記事にまとめています。
十分気をつけて執筆していますが、なにぶん初心者が書いた記事なので、理解が浅い点などあるかと思います。
間違い等あれば、指摘いただけると助かります。
記事を参考にされる方は、初心者の記事であることを念頭において、お読みいただけると幸いです。
記事のテーマ
- 現在、LinuCレベル1取得を目指して勉強しています。
- SUID、SGID、スティッキービットについてまとめていきます。
- パーミッションについては、以下の記事を確認してください。
1. SUID、SGID、スティッキービット
ファイルやディレクトリに対して以下の特殊なアクセス制御を指定することが可能です。
- SUID（Set User ID）
- SGID（Set Group ID）
- スティッキービット
2. SUID
SUID（Set User ID）とは、実行権限を持っているユーザーがファイルを実行した場合、実行したユーザーではなくファイルの所有ユーザーの権限で実行される仕組みです。
SUIDの例の1つが、passwdコマンドです。
Linuxでは、暗号化されたパスワードはすべて /etc/shadow というファイルに保存されています。
/etc/shadow は、機密情報を格納したファイルであるため、パーミッションは以下のように設定されています。
ls -l /etc/shadow
-rw-r----- 1 root shadow 1234 May 1 12:00 /etc/shadow
/etc/shadowの所有者はrootユーザーであり、その他ユーザーは読み書きできない状態になっています。
しかし、その他ユーザーであるはずの一般ユーザーは passwd コマンドを実行して自身のパスワードを変更できます。このコマンドは、背後で /etc/shadow への書き込み処理を伴います。
アクセス権限を持たない一般ユーザーが、なぜ/etc/shadowにパスワード情報を書き込みできるのでしょうか。
その理由は、SUIDにあります。
passwdコマンドのパーミッションを確認してみましょう。
ls -l /usr/bin/passwd
-rwsr-xr-x 1 root root 12345 May 1 12:00 /usr/bin/passwd
所有ユーザーの実行権限欄に小文字の「s」と表示されていることが確認できます。
この「s」は、所有ユーザーの実行権限（x）があり、かつSUIDが設定されていることを示しています。
もし、設定されたファイルに元々実行権限がなかった場合は、大文字の「S」となり、SUIDは有効に機能しません。
SUIDが設定されたファイルを実行する際に、具体的に何が起こっているのでしょう。
Linuxカーネルがプロセスを管理する際、主に以下の2つのユーザーIDを区別しています。
- RUID (Real User ID / 実ユーザーID): プロセスを実際に起動したユーザーのID。
- EUID (Effective User ID / 実効ユーザーID): カーネルが「このプロセスは誰の権限で動作しているか」を判断し、ファイルアクセスなどの権限を認可するためのID。
通常のコマンドを実行した場合、RUID = EUID（起動した人の権限）となります。
SUIDが設定されたファイルを実行すると、プロセスの実効ユーザーID（EUID）は、実行したユーザーのものではなく、ファイルの所有ユーザーのUIDに変更されます。
所有ユーザーは多くの場合、root（EUID 0）です。
つまり、SUIDによってpasswdコマンドの実行中だけ、プロセスが一時的に root の実効ユーザーID（EUID）で動作するため、rootユーザーにしかアクセスできないはずの /etc/shadowファイルにパスワード情報を書き込むことが可能なのです。
このように、「一般ユーザーには権限を与えたくないけれど、特定の決まった安全な手続き（プログラム）を通すときだけは、一時的に管理者の権限で動かしてあげたい」 という場合に、SUIDが使われます。
SUIDはファイルに設定されるパーミッションで、ディレクトリにSUIDを設定しても通常は無効になります。
ファイルにSUIDを設定する場合は、パーミッションの数値表現に4000を足すか、もしくは記号表現で「u+s」と指定します。
chmod 4755 file
#もしくは
chmod u+s file
3. SGID
SGID（Set Group ID）は、ファイルやディレクトリに対して設定し、特定のグループ権限を自動的に適用・引き継がせるための仕組みです。
ファイルに設定した場合、どのユーザーがそのファイルを実行しても、実行したユーザーではなく「ファイルの所有グループ」の権限でプログラムが実行されます。
ディレクトリに設定した場合、そのディレクトリ内で作成されたファイルやディレクトリには、作成者に関わらず「親ディレクトリと同じ所有グループ」が自動的にセットされます。
SUIDが「特定のユーザー（主にroot）に変身する」仕組みだったのに対し、SGIDは「特定のグループに変身する」仕組みと言えます。
SGIDは、複数ユーザーが利用する共同開発用ディレクトリなど、主にディレクトリの運用によく用いられます。
ファイル・ディレクトリを作成する際には通常、所有グループとして、所有ユーザーのプライマリグループが指定されます。
この所有グループの設定によって、任意のユーザーには共有し、それ以外のユーザーにはファイルにアクセスさせないというアクセス制御が可能になります。
しかし、複数のメンバーで共同開発する際などには、この所有グループのアクセス制御が余計な作業を生み出す場合があります。
仮に、developグループのAさんとBさんが、共同開発用のディレクトリ（/develop_shared）で開発を行っていたとします。
Aさんは複数グループに所属しています。もしAさんのプライマリグループが、developグループではない別のグループ（managerグループ）であった場合、Aさんが/develop_shared/newfile.txt を新規作成すると、そのファイルの所有グループはmanagerグループとなります。もし、Bさんがmanagerグループに所属しておらず、その他ユーザーのパーミッションも制限されていれば、Bさんは該当ファイルにアクセスできなくなります（Permission denied）。
このように、ディレクトリとそのディレクトリに配置されるファイルは別の所有グループを設定できてしまいます。そのため、共有したいと思って作成したファイルが、共有したいユーザーからアクセスできないという事態が発生します。
この状態を解消するには、Aさんがファイル作成後にchgrp develop newfile.txtコマンドを実行し、所有グループを変更する必要があります。
しかし、ファイルを作成するたびに、「今の作ったファイルの所有グループは何になっているかな」と確認・変更する作業は、煩雑です。
このような課題を解決するために有効なのが、SGIDです。
ディレクトリにSGIDを設定しておくと、ディレクトリ内で作成されたファイルやディレクトリは、誰が作成したかにかかわらず、親ディレクトリと同じ所有グループが自動的にセットされます。
共同開発用のディレクトリ（/develop_shared）の場合では、Aさんのプライマリグループが manager グループである状態でファイルを作成しても、ファイルの所有グループは、ディレクトリと同じdevelopグループに自動的に設定されます。
この状態であれば、Aさんはプライマリグループに注意する必要がなく、BさんもPermission deniedでファイルにアクセスできないという問題がなくなります。
ディレクトリにSGIDを設定する場合は、パーミッションの数値表現に2000を足すか、もしくは記号表現で「g+s」と指定します。
chmod 2770 /develop_shared
#もしくは
chmod g+s /develop_shared
SGIDを設定したディレクトリの情報を取得すると以下のようになります。
ls -dl /develop_shared
drwxrws--- 1 root develop 12345 May 1 12:00 /develop_shared
所有グループの実行権限欄に「s」と表示されていることが確認できます。
この「s」は、このディレクトリの所有グループに実行権限（x）があり、かつSGIDが設定されていることを示しています。
もし、設定されたディレクトリに所有グループの実行権限がなかった場合は、大文字の「S」となります。
ファイルで大文字の「S」の場合は、SGIDが機能しません。ディレクトリで大文字の「S」の場合は、「配下に作成されたファイルへ所有グループを強制継承する」というSGIDの機能は有効に動作します。
4. スティッキービット
スティッキービットとは、ディレクトリに対する書き込み権限を持つユーザーであっても、自身が所有していないファイルの削除や名前変更を禁止する特殊なパーミッション設定です。
スティッキービットも、主にディレクトリに対して設定されます。
ディレクトリに書き込み権限（w）と実行権限（x）があると、ファイルの作成・削除・名前変更が可能になります。
そのため、あるディレクトリでその他ユーザーに書き込み権限（w）を与えると、自分以外のユーザーが作ったファイルであっても自由に削除できてしまうというセキュリティ上のリスクが生じます。このようなリスクを回避し、「ファイルの作成は許可しつつ、他人が所有するファイルの削除や名前変更は防ぐ」という要件を満たしたい場合に利用されるのが、スティッキービットです。
スティッキービットをディレクトリに設定すると、その中にあるファイルやディレクトリを削除・名前変更できるのが以下のユーザーだけに限定されます。
- ファイルの所有ユーザー
- ディレクトリの所有ユーザー
- rootユーザー（管理者）
スティッキービットの例の1つに、/tmpディレクトリがあります。
/tmpディレクトリは、様々なユーザーが一時ファイルを保管する場所ですが、ユーザーAが利用している一時ファイルを、ユーザーBが誤って削除してしまうと、ユーザーAの処理が失敗してしまいます。
そのような不具合を防ぐために、/tmpディレクトリにはスティッキービットが設定されています。
/tmp ディレクトリのパーミッションを確認してみましょう。
ls -dl /tmp
drwxrwxrwt 21 root root 1234 May 1 12:00 /tmp
その他ユーザーの実行権限欄に「t」と表示されていることが確認できます。
この「t」は、このディレクトリにその他ユーザーの実行権限（x）があり、かつスティッキービットが設定されていることを示しています。
もし、ディレクトリのパーミッションにその他ユーザーの実行権限（x）がなかった場合は、大文字の「T」と表示されます。
スティッキービットは大文字の「T」表示（実行権限なし）であっても、「自身が所有者でないファイルの削除・名前変更を禁止する」という機能自体は有効に動作します。
ディレクトリにスティッキービットを設定する場合は、パーミッションの数値表現に1000を足すか、もしくは記号表現で「o+t」と指定します。
chmod 1777 /group_tmp
#もしくは
chmod o+t /group_tmp
5. 特殊パーミッションが設定されたファイルを検索する
システム内に意図しないSUIDファイルやSGIDディレクトリが紛れ込んでいないかを定期的に調査することは、重要です。
find コマンドの -perm オプションを使って検索可能です。
# 同一ファイルシステム内（-xdev）で、SUIDが設定されたファイルを検索
find / -xdev -perm -4000 -type f 2>/dev/null
# 特定の公開ディレクトリ配下で、SGIDが設定されたディレクトリを検索
find /var /home -xdev -perm -2000 -type d 2>/dev/null
まとめ
今回紹介した3つの特殊パーミッション（SUID, SGID, スティッキービット）は、Linuxシステムにおいて柔軟なアクセス制御や共有環境を実現するために不可欠な機能です。それぞれの特徴と代表的なユースケースを以下にまとめます。
| 特殊パーミッション | 数値 | 記号 | 主な設定対象 | 動作・効果 | 代表的なユースケース |
|---|---|---|---|---|---|
| SUID | 4000 | u+s | ファイル | 実行時にファイルの所有ユーザーの権限で動作する。 |
passwd コマンドによる /etc/shadow への書き込み |
| SGID | 2000 | g+s | ファイル / ディレクトリ | 【ファイル】実行時にファイルの所有グループ権限で動作する。 【ディレクトリ】配下の新規ファイルに親ディレクトリの所有グループを自動継承する。 |
複数メンバーによる共同開発ディレクトリ |
| スティッキービット | 1000 | o+t | ディレクトリ | 書き込み権限があっても、自身が所有者でないファイルの削除・名前変更を禁止する。 | /tmpディレクトリ（不特定多数の一時ファイル置き場） |
これらの特殊パーミッションは強力ですが、特権昇格などの致命的なセキュリティ脆弱性に繋がるリスクがあります。
実務においては、安易に新規付与するのではなく、「sudoによる限定許可」や「Linuxケーパビリティによる権限の最小化」といった代替アプローチを検討します。
記事は以上です。
最後までお読みいただき、ありがとうございました。
参考情報一覧
この記事は以下の情報を参考にして執筆しました。
- Linux教科書 LinuCレベル1Version 10.0対応
- 新しいLinuxの教科書 第2版
- ping-t
- LinuCレベル１技術解説無料セミナー ~Linuxユーザ体系とアクセス権限の理解~ (参照 2026-05-18)
- Linuxの3つのUIDの話(最終更新 2025-12-04) (参照 2026-05-18)
- Linuxセキュリティ capabilityについて理解する(最終更新 2023-03-19) (参照 2026-05-18)
Discussion