【早見表付】Linux特殊パーミッションとは？SUID/SGID/Sticky bitの仕組みと設定コマンド

Linuxサーバーを運用していると、ls -l を実行した際に -rwsr-xr-x や drwxrwxrwt のように、見慣れない s や t という記号に出会うことがあります。

これらは特殊パーミッション（SUID / SGID / Sticky Bit）と呼ばれる機能で、通常のパーミッション（r・w・x）だけでは実現できない「一時的な所有者権限での実行」や「共有ディレクトリでの削除制限」を行うための重要な仕組みです。

この記事では、3つの特殊パーミッションの概念から、ls -l での記号の読み方、設定・解除コマンド（数値表現 4755 や 1777）、さらにはセキュリティ監査で使える一括検索コマンドまで、18年のインフラ経験をもとに分かりやすく解説します。

3分でわかる！特殊パーミッションの全体像（比較早見表）

Linuxの特殊パーミッションには、SUID・SGID・Sticky Bit の3種類が存在します。それぞれの役割と代表例は以下の通りです。

特殊パーミッション	記号	数値	付与対象	主な効果・用途	代表的な実例
SUID (Set User ID)	s (所有者)	4	ファイル	実行時、ファイル所有者の権限で動作する	/usr/bin/passwd
SGID (Set Group ID)	s (グループ)	2	ファイル / ディレクトリ	実行時、所有グループの権限で動作する （ディレクトリの場合、配下ファイルのグループを継承）	チーム共有ディレクトリ
Sticky Bit (スティッキービット)	t (その他)	1	ディレクトリ	全員が書き込み可能だが、削除・改名は作成者のみ可能	/tmp ディレクトリ

【詳細解説】3つの特殊パーミッションの仕組みと具体例

① SUID（Set User ID）｜所有者権限での実行

SUIDが設定された実行ファイルは、「誰が実行しても、ファイル所有者の権限でプロセスが動く」という特徴を持ちます。

通常、一般ユーザーは /etc/shadow（暗号化されたパスワードが保存されるファイル）を読み書きできません。

しかし、一般ユーザーが自身のパスワードを変更できるのは、パスワード変更コマンド /usr/bin/passwd にSUIDが設定されているからです。

設定・解除コマンド

# 記号法（ユーザー権限に s を付与）
chmod u+s filename
chmod u-s filename  # 解除

# 数値法（先頭に 4 を付加）
chmod 4755 filename

💡 18年目の現場知見：「便利だから」で置かれた chmod 4755 の罠

以前、ある開発現場で「一般ユーザーのバッチから管理者権限が必要な処理を動かしたい」という理由で、シェルスクリプトに安易に SUID（chmod 4755）が設定されていたことがありました。

しかし、SUIDがついたスクリプトや実行ファイルに脆弱性があると、一般ユーザーから一気に root 権限を奪われる「権限昇格（Privilege Escalation）」の標的になります。

現在のインフラ運用では、本番環境で野良SUIDファイルを配置することは原則禁止です。権限昇格が必要な処理は、SUIDに頼らず sudoers（/etc/sudoers）でコマンド・ユーザー単位に厳格に実行権限を絞り込む のが現代の安全な標準です。

② SGID（Set Group ID）｜グループ権限の継承

SGIDをファイルに設定すると「所有グループの権限で実行」されますが、実務で最もよく使われるのはディレクトリへの設定です。

SGIDが設定されたディレクトリ内に作成されたファイルやサブディレクトリは、作成したユーザーの主グループに関わらず、親ディレクトリの所有グループが強制的に自動継承されます。

【共有ディレクトリ (/shared)】 (所有グループ: devteam, SGIDあり)
   └─ user01 (主グループ: sales) がファイル作成
       └─ 作成されたファイル: 所有グループが自動的に「devteam」になる！

複数エンジニアで共通の作業ディレクトリを運用する際、「誰がファイルを作ってもグループメンバー全員が編集できる」状態を作るために不可欠な設定です。

設定・解除コマンド

# 記号法（グループ権限に s を付与）
chmod g+s dirname
chmod g-s dirname  # 解除

# 数値法（先頭に 2 を付加）
chmod 2775 dirname

💡 18年目の現場知見：グループ共有フォルダで電話が鳴り止まなかった話

複数メンバーで作業するプロジェクト用の共有ディレクトリを作成した際、SGID（chmod 2775）の付与を忘れていたことがありました。

結果、Aさんが作成したファイルの所有グループがAさんの個人グループになってしまい、後からBさんが編集しようとすると「Permission denied」が発生。「毎回 chown し直してください！」と夜間に現場からの呼び出しや問い合わせが連発する羽目に……。

ディレクトリに SGID を設定しておけば、誰がファイルを作成しても親ディレクトリの所有グループが自動継承されるため、権限のズレによる運用トラブルをゼロに抑えることができます。

③ Sticky Bit（スティッキービット）｜削除権限の制限

Sticky Bitは、主に「全ユーザーに書き込み権限を与えたいディレクトリ」に対して設定します。

通常のディレクトリでは、書き込み権限があれば「他人が作ったファイル」でも自由に削除できてしまいます。しかし、Sticky Bitが設定されていると、「ファイルの所有者（作成者）」または「rootユーザー」しかそのファイルを削除・改名できなくなります。

代表例が /tmp ディレクトリです。不特定多数のユーザーやプロセスが一時ファイルを作成しますが、他人の temporary ファイルを誤って削除できないよう drwxrwxrwt（Sticky Bit）が設定されています。

設定・解除コマンド

# 記号法（その他のユーザー権限に t を付与）
chmod o+t dirname
chmod o-t dirname  # 解除

# 数値法（先頭に 1 を付加）
chmod 1777 dirname

💡 18年目の現場知見：アプリ用一時ディレクトリに「単なる 777」を設定した末路

複数プロセスがテンポラリファイルを読み書きするディレクトリに対して、安易にアクセス権限を設定して運用していたシステムがありました。

ある日、特定のバッチプロセスがバグで暴走し、他のプロセスが作成した一時ファイルまで片端から削除（Clean up）してしまう悲劇が発生。システム全体が停止する大障害へ発展しました。

全員に書き込みを許可しつつも他人のファイル削除を防ぐには、単なる 777 ではなく Sticky Bit を付与した 1777（/tmp と同じ設定）を徹底するのが、運用設計の重要な作法です。

「ls -l」での記号の読み方（大文字 S / T と小文字 s / t の違い）

ls -l コマンドでパーミッションを確認した際、記号が小文字（s / t）ではなく大文字（S / T）で表示されることがあります。

-rwsr-xr-x. 1 root root  # 小文字の s (正常)
-rwSr-xr-x. 1 root root  # 大文字の S (注意！)

大文字と小文字の違い

• 小文字 (s / t): 元々の実行権限（x）が付与されている状態（正常動作）
• 大文字 (S / T): 元々の実行権限（x）が付与されていない状態（無効状態・設定ミス）

大文字が表示されている場合、「特殊パーミッションを設定したものの、肝心の実行権限 x が無いため機能していない」状態です。chmod u+x などで実行権限を足すと小文字に変わります。

💡 18年目の現場知見：「設定したはずなのに動かない」時のチェックポイント

「指示通り SUID（4755）を設定したはずなのに、一般ユーザーから実行すると権限エラーになる」という障害調査を依頼されたことがあります。

ls -l で確認すると、表示が -rwSr-xr-x（大文字の S）になっていました。原因は、ファイル自体に実行権限 x が付いていない状態で chmod u+s を実行していたことでした。

構築時のレビューやトラブルシューティングでは、「記号が大文字 S や T になっていないか（＝実行権限 x が落とされていないか）」をチェックするのが、素早く原因を特定するコツです。

【18年の現場知見】セキュリティ監査と一括検索コマンド

SUIDやSGIDが設定されたファイルは、攻撃者に悪用されると一般ユーザーから root 権限への「権限昇格攻撃（Privilege Escalation）」の足がかりにされる危険性があります。

そのため、18年のインフラ現場でも、サーバー引き渡し前や定期的なセキュリティ監査の際には、「意図しない場所に不要なSUID/SGIDファイルが存在しないか」を必ずチェックします。

不要なSUID / SGID ファイルの一括検索コマンド

# システム全体から SUID が設定されたファイルを検索
find / -perm -4000 -type f -ls 2>/dev/null

# システム全体から SGID が設定されたファイルを検索
find / -perm -2000 -type f -ls 2>/dev/null

# SUID または SGID のいずれかが付与されたファイルをまとめて検索
find / -type f \( -perm -4000 -o -perm -2000 \) -ls 2>/dev/null

自作のスクリプトや業務アプリの実行ファイルに安易に SUID を付与せず、必要最小限の運用にとどめるのがセキュリティの基本ルールです。

💡 18年目の現場知見：本番移行前（引き渡し検査）での「一括検索」のリアル

大規模インフラの運用移管や本番引き渡し前には、セキュリティ監査の一環として必ず find / -perm -4000 を実行し、全ディスク内の SUID / SGID ファイルを洗い出します。

実際にこのコマンドを回すと、構築作業中に作業者が一時的に配置した野良ツールやテスト用スクリプトに SUID が残っているケースが時折見つかります。

パラメータシート（設計書）に記載のない不要な SUID / SGID ファイルは、セキュリティ上のバックドア（裏口）になり得るため、本番稼働前にすべて洗い出して解除・撤去するのがインフラエンジニアの務めです。

まとめ：特殊パーミッションをマスターして安全なアクセス制御を

• SUID (4 / u+s): 誰が実行してもファイル所有権限で動作（例: /usr/bin/passwd）
• SGID (2 / g+s): 所有グループ権限の継承。チーム共有フォルダの運用に最適
• Sticky Bit (1 / o+t): 全員書き込めるが削除は作成者限定（例: /tmp）
• 大文字の S や T は実行権限 x が不足しているサイン

一般的な 755 や 644 といったパーミッションに加え、特殊パーミッションを正しく使いこなすことで、Linuxサーバーのセキュリティと利便性を両立させることができます。

権限不足や「Permission denied」が発生した際に、安全に原因を切り分けて復旧する手順は、こちらの記事で詳しく解説しています。

Linuxサーバーを扱うということは、その背後にある厳格なセキュリティ設計を尊重することです。正しい知識を武器に、信頼されるエンジニアを目指しましょう。

---

SUIDやSGIDが正しく設定されていないことが原因で、アプリケーションがエラーを吐くケースは意外と多いものです。

表面上の挙動だけでは分かりにくい権限トラブルも、OSのログを適切に追うことで、パーミッションエラーの真実が見えてきます。権限設定とセットで覚えておきたいログ調査の基本テクニックもあわせて確認しておきましょう。