chmod 755 / 644 / 600 完全ガイド — setuid と sticky の罠まで一気に理解する

Linux/Unix のファイルパーミッションは 3 つのアクター × 3 種類の権限 = 9 ビットで表します。 3 アクターは:

• u (user / owner) ― ファイルの所有者
• g (group) ― ファイルが属するグループのメンバー
• o (other) ― それ以外の全員

3 権限は:

• r (read, 値 4) ― ファイルなら内容を読める、 dir なら ls で中身を一覧できる
• w (write, 値 2) ― ファイルなら書き換えできる、 dir なら中のファイルを追加・削除できる (ファイル自身の権限ではない、 ここ重要)
• x (execute, 値 1) ― ファイルなら実行できる、 dir なら cd で中に入れる (一覧は r が別途必要)

3 つの値 (4 + 2 + 1) を足し算するだけで、 各アクターの権限が 0〜7 の 1 桁 8 進数で表せます。 これを 3 つ並べた 3 桁 8 進数が「755」 等のお馴染みの表記です。

覚えるべきは結局この 4〜5 パターンです。

新規ファイルが デフォルトで 644 になるのは、 多くのシステムの umask が 022 に設定されているためです。 chmod の base 値はファイル 666 / dir 777 で、 そこから umask の各ビットを引きます (実際には AND NOT):

# umask 022 のとき
ファイル: 666 & ~022 = 644 (rw-r--r--)
dir:      777 & ~022 = 755 (rwxr-xr-x)

# umask 002 のとき (グループ共有環境でよく見る)
ファイル: 666 & ~002 = 664 (rw-rw-r--)
dir:      777 & ~002 = 775 (rwxrwxr-x)

POSIX 標準は 8 進と並んで シンボリックの構文も定義しています (本来こちらが正式)。 構文は [ugoa][+−=][rwxst] をカンマ区切りで並べる形:

chmod u=rwx,g=rx,o=rx file     # 755 と等価
chmod u+x script.sh             # 所有者だけ実行権を追加
chmod -R go-w /path             # group + other から書き権限を一括除去
chmod a+r file                  # 全員 (all = ugo) に読み権限

記号と意味:

• who: u 所有者 / g グループ / o その他 / a = ugo
• op: + 追加 / - 除去 / = 完全置き換え
• perm: r w x / s setuid・setgid / t sticky / X 「他に x が立っている時だけ x を追加」 (再帰的 chmod で便利)

シンボリックは「変更したい場所だけ触る」 のが強み。 「サーバー上の特定ファイルから書き権限だけ消したい」 のような部分修正は chmod go-w の方が安全で意図が明確になります。 8 進は「完全に新しい状態に置き換える」 操作なので、 元状態を破壊するリスクがあります。

4 桁の 8 進数 (例: 4755) を見かけたら、 先頭の桁は 特殊ビットです。 値は同じく 4+2+1 の合算:

• setuid (値 4, 8 進 4000) ― 実行ファイルに付けると、 実行時のプロセス権限が「実行者ではなくファイルの所有者」 になる
• setgid (値 2, 8 進 2000) ― 実行ファイルでは「グループ ID が所有グループに切り替わる」、 ディレクトリでは「その dir 内に作成された新規ファイルが親 dir のグループを継承」
• sticky (値 1, 8 進 1000) ― ディレクトリで「ファイルを削除/改名できるのは 所有者本人と root のみ」

シンボリック表記では x の位置に s / S / t / T が現れます (小文字は x も立っている、 大文字は x が立っていない)。

なぜ /tmp が 1777 なのか

POSIX 標準と Linux man-page は揃って言及していますが、 /tmp はあらゆるユーザーが一時ファイルを置く共有スペースなので、 「全員書き込み可」 (777) でなくてはなりません。 しかしそれだけだと、 ユーザー A が作ったファイルを悪意のあるユーザー B が削除できてしまう (ディレクトリの w 権限があれば中のファイルを消せる)。 そこで sticky ビット (1) を付けて、 「削除/改名できるのは所有者だけ」 という制限を加える。 これが 1777 = rwxrwxrwt の意味です。

setuid の罠 ― 現代では極力避ける

setuid は強力で便利な機能ですが、 脆弱性の温床として知られています。 任意のユーザーが root 権限でコードを実行できる経路になるため、 1 つのバグが権限昇格に直結します。 現代のセキュリティ慣行では:

• setuid 実行ファイルは可能な限り減らす (各 distro は最小化を進めている)
• 代替として Linux capabilities (例: setcap cap_net_bind_service+ep) で必要な権限だけ付与
• sudo / polkit 経由で個別承認に切り替える
• shell script に setuid は 絶対に付けない (多くのカーネルがそもそも無視する)

SSH 秘密鍵が 600 (or 400) でないと OpenSSH が拒否

$ ssh -i ~/.ssh/id_rsa user@host
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/user/.ssh/id_rsa' are too open.
It is required that your private key files are NOT accessible by others.

対処: chmod 600 ~/.ssh/id_rsa (または 400 で書き換えも禁止)。 OpenSSH は秘密鍵の group / other に少しでも権限があると起動時にエラーで止まります。 シェル機能ではなく ssh(1) のセキュリティ要件です。

~/.ssh ディレクトリは 700

ディレクトリの group や other に w があると、 中のファイルを置き換えられるリスクがあるため、 OpenSSH は ~/.ssh 自体も 700 を要求します。 多くのチュートリアルが chmod 700 ~/.ssh && chmod 600 ~/.ssh/* をセットで指示するのはこのためです。

Web サーバーで実行ファイルに x が付いていない

CGI スクリプトや実行型バイナリは 所有者だけでなく Web サーバープロセスからも x が必要です。 Apache/Nginx が www-data ユーザーで動いているなら、 そのユーザーが含まれるグループ (or other) に x が立っている必要があります。 一般には 755 で配置。

git clone 後にスクリプトが動かない

Linux の git は実行ビット (x) を保存しますが、 Windows 側で clone したり ZIP 経由でコピーすると x が落ちることがあります。 chmod +x script.sh や git update-index --chmod=+x script.sh で復活させます。

結局のところ、 8 進のパーミッションは次の 1 行で要約できます:

[特殊 1 桁] [所有者 1 桁] [グループ 1 桁] [その他 1 桁] = それぞれ 4 (read) + 2 (write) + 1 (execute) の合計

あとは、 「755 = 自分が全部、 他は読み + 通過」 「644 = 自分は読み書き、 他は読みのみ」 「600 = 自分専用」 という代表パターンを覚えれば、 9 割の用途はカバーできます。 setuid・setgid・sticky を見たら、 4 桁目の「特殊操作」 だと意識する。 これだけです。

頭の中で計算するのに自信がないときは chmod 計算機ツール をどうぞ。 チェックボックスで rwx を切ると 8 進・シンボリック・ugo の 3 表記が同時に更新され、 setuid / setgid / sticky の意味も画面下に表示されます。 chmod コマンドのコピペ用フォーマットもターミナル風に表示するので、 そのまま貼り付けて使えます。

パーミッション設定はサーバーセキュリティの基礎の基礎です。 「とりあえず 777 にしておけば動く」 で済ませず、 必要最小限の権限 (= 最小権限の原則) を選ぶ習慣をつけると、 後から起きる事故の多くを未然に防げます。