chmod・chown・sudoの使い分け - Linux権限管理の応用

2025-01-11 読了時間: 約12分 難易度: 中級以上

権限管理の基礎を終えたら、次は**「状況に応じて使い分ける判断力」**を身につけましょう。chmod・chown・sudo はどれも便利なコマンドです。ただし、使う順番と判断基準を間違えると事故につながります。

用語の整理（この記事で使う言葉を先に定義します）

• パーミッション（権限）: だれがそのファイルを読めるか・書けるか・実行できるかの設定です。「アクセス権」とも呼びます。この記事では「権限」で統一します
• owner / group / other: 権限を与える相手の 3 分類です。順に「所有者本人」「所有グループに属する人」「それ以外の全員」を指します。chmod では u / g / o と書きます
• r / w / x: 読み取り（read）・書き込み（write）・実行（execute）の権限です。ディレクトリでは x の意味が変わります（後述）
• 記号表記 / 数値表記: chmod u+w のような書き方が記号表記です。chmod 644 のような書き方が数値表記です。「シンボリックモード」「8 進数表記」も同じものを指します
• umask: 新しく作るファイルから権限を差し引く設定値です
• root: 何でもできる管理者ユーザーです。sudo は「このコマンドだけ root として実行する」という指示です

先に結論（判断の型）

権限トラブルに遭遇したら、この順番を崩さない。

1. ls -l で 所有者・グループ・権限 を確認
2. 自分が owner / group / other のどれかを判断
3. 修正方法を選ぶ
   • 権限を足す → chmod
   • 所有者を変える → chown
   • 一時的に突破 → sudo（最後の手段）

chmod を"判断付き"で使う

結論: chmodは記号表記を基本とし数値表記は644や755の意味をすぐ説明できる場合のみ使う。

まずは記号表記で考える（安全第一）

$ chmod u+w report.txt

-rw-r--r-- 1 user user 2048 report.txt

• 所有者（u）に書き込み権限（w）を追加します
• 変更するのは指定した 1 点だけです。影響範囲が限定的なので事故りにくい書き方です

なぜ安全か

• 変更対象（u/g/o）が明示される
• 既存権限を壊しにくい

危険な例：数値表記を雑に使う

$ chmod 777 report.txt

問題点

• 全員（other を含む）に読み取り・書き込み・実行の権限を与えます
• 同じサーバに入れる人なら誰でも中身を書き換えられます
• 意図しない改変や、置き換えられたスクリプトの実行につながります

なぜ chmod 777 は危険なのか？

777 = 誰でも何でもできる

• **r（読み取り）+ w（書き込み）+ x（実行）**を全員に付与
• 共有サーバーでは他ユーザーが悪意あるコードを書き込める

実際に起きた事故例

本番サーバーで /var/www を 777 にしたケース：

• 攻撃者がPHPファイルを改ざん
• Webシェル（遠隔操作ツール）を設置された
• サーバー全体が乗っ取られる事態に

安全な代替

• ディレクトリ: 755（所有者のみ書き込み、他は読み取り・実行）
• ファイル: 644（所有者のみ書き込み、他は読み取りのみ）
• Web サーバに書き込ませたいディレクトリだけ、所有グループを合わせて chmod g+w で許可する

それでも 777 を試したくなったら

777 は「権限の問題を消す」のではなく「権限の確認をやめる」設定です。まず ls -l と id で、自分が owner / group / other のどれなのかを確認してください。必要な相手に必要な 1 ビットだけ足すのが正しい直し方です。

umask：新規ファイルのデフォルト権限を決める

なぜ新規ファイルは 644 になるのか？

umask が「引き算」しているからです。umask は新規ファイルに与える権限から、指定した値を差し引く設定です。

$ umask

0022

考え方（引き算ではなくマスク）

umask は指定した権限ビットを取り除く設定です。算術的な引き算ではありません。022 のときはたまたま引き算と同じ結果になりますが、他の値では一致しません。

umask 077 を「666 - 077」と計算すると桁借りが起きて成立しません。桁ごとに引くのではなく、指定したビットを落とす操作だと理解してください。

図1: umask 022 が落とすのは group と other の w だけです。残った権限がそのまま新規ファイルの 644 になります。上下を引き算しているのではなく、指定された位置の権限を消しているだけです（ファイルの場合。ディレクトリは 777 が起点で 755 になります）。

実務での使いどころ

• 共有ディレクトリでグループ書き込みを許可したい → umask 002
• セキュリティ強化で他者の読み取りを禁止したい → umask 077

ディレクトリ権限の落とし穴（応用で一番事故る）

結論: ディレクトリのx権限がないとcd不可でありls -lで現状確認し最小限の権限を追加する。

dr--r--r-- 2 user user 4096 logs/

症状

• ls logs はできます（中身の名前は読めます）
• ls -l logs は名前だけ出て、サイズや日付が ? になります（中のファイルの情報を取りに行けないため）
• cd logs はできません（Permission denied になります）

理由

• ディレクトリの x は「中に入る権利」です。ファイルの x（実行権限）とは意味が違います
• ディレクトリの r は「中のファイル名を一覧する権利」です。r だけでは cd も、中のファイルを開くこともできません

対応

$ chmod u+x logs

chown：所有者変更は"最終判断"

結論: chownは所有者が明確にズレている場合のみ使い-Rオプションはサービス停止を招くため慎重に。

正しい使いどころ

$ sudo chown user:user app.log

ファイルの所有者が明確にズレている場合のみ使用します。「権限エラーが出たから」という理由だけで所有者を変えないでください。

実際に起きがちな事故

$ sudo chown -R user:user /var/www

何が起きるか

• Web サーバは www-data などの専用ユーザーで動いています
• そのユーザーがファイルを読めなくなります
• 結果として Web サーバが応答しなくなります

実行前に必ずやること

1. ls -ld 対象ディレクトリ で現在の所有者を控える
2. -R を外して 1 ファイルだけで試す
3. find /var/www ! -user www-data | head のように、変更対象を先に一覧する

chown -R で詰んだ話（復旧方法付き）

実際の事故

/var/www を全部 chown -R myuser した結果：

• Apache/Nginx は www-data ユーザで動作
• 設定ファイルやログにアクセスできなくなった
• Webサービスが全停止

復旧方法

# Webコンテンツ領域を復旧
$ sudo chown -R www-data:www-data /var/www/html

# 所有者を確認
$ ls -la /var/www/html/

教訓

• -R（再帰的）は影響範囲が広い
• 実行前に ls -la で対象を確認
• サービスディレクトリは特に慎重に

sudo は魔法ではない

結論: sudoは一時的な突破手段であり根本対応はchmodかchownで行い安易な連用は詰みの入口。

$ sudo rm important.txt

• 実行できることと、正しいことは別です
• sudo は原因を消しません。原因を見えなくするだけです

安全な考え方

• sudo は一時的な突破手段です
• 恒久対応は chmod か chown で行います
• sudo を打つ前に「なぜ自分の権限では足りないのか」を 1 行で説明できるか確かめてください

sudo 連打で後戻り不能になった話

よくあるパターン

1. Permission denied が出る
2. 「とりあえず sudo」で実行
3. 作成されたファイルが root 所有に
4. 次から自分で編集できない
5. 「また sudo」で対応…
6. 気づいたら root 所有ファイルだらけ

図2: sudo が作ったファイルは root 所有になります。次に自分で編集しようとすると弾かれ、そのユーザーがまた sudo を打つ。この輪が「とりあえず sudo」を再生産します。

実例

# 新規ファイルを sudo で作ると…
$ sudo vim new-config.yaml

# root 所有のファイルができる
$ ls -l new-config.yaml
-rw-r--r-- 1 root root 1024 new-config.yaml

# 次から自分では編集できない
$ vim new-config.yaml
# Permission denied...

既存の自分のファイルを sudo vim で編集した場合、所有者は変わりません。vim は書き戻すときに元の所有者を保ちます。root 所有のファイルが増えるのは、sudo を付けたコマンドがファイルを新しく作ったときです。sudo touch、sudo cp、sudo コマンド > ファイル のリダイレクトも同じ理由で root 所有のファイルを作ります。

正しい対応

• sudo を使う前に「なぜ権限がないか」を確認します
• システムファイルの編集には sudoedit（sudo -e）を使います。編集後もファイルの所有者が変わりません
• 作業後に ls -l で所有者を確認します。root 所有になっていたら sudo chown $USER ファイル名 で戻します

代替案：所有者を変えない設計

そもそも権限トラブルを起こさない方法

1. 実行ユーザーを揃える

アプリケーションの出力先を、実行ユーザーが書き込めるディレクトリに変更する。

2. グループ権限で解決する

# 開発者グループを作成
$ sudo groupadd developers

# ユーザーをグループに追加
$ sudo usermod -a -G developers user

# ディレクトリのグループを変更
$ sudo chgrp developers /path/to/project
$ sudo chmod g+w /path/to/project

usermod でグループを追加しても、いま開いているセッションには反映されません。一度ログアウトして入り直してください。反映されたかどうかは groups コマンドで確認できます。

3. アプリ側の設定を変更する

ログ出力先や一時ファイルの保存先を変更します。実行ユーザーが書き込める場所に寄せるほど、権限トラブルは起きにくくなります。

エラーメッセージ起点の切り分け（具体例）

結論: Permission deniedはls -lで所有者と権限を確認し原因を特定してから対処する。

ケース1：Permission denied

$ echo test > report.txt

Permission denied

確認手順

$ ls -l report.txt

-r--r--r-- 1 user user 2048 report.txt

判断

• 所有者が自分の場合 → chmod u+w で解決します
• 所有者が違う場合 → まず所属グループでの解決を検討します。それでも足りないときだけ chown や sudo を検討します

ケース2：Operation not permitted

$ chown user:user system.conf

Operation not permitted

原因

• 所有者の変更は root 権限が必要な操作です。一般ユーザーは自分のファイルであっても他人へ譲渡できません

判断

• 本当に所有者変更が必要か？
• sudo を使う理由を説明できるか？

事故例：chmod -R の暴発

最悪のパターン

# カレントディレクトリ全体を777に…
$ chmod -R 777 .

何が起きるか

• カレントディレクトリ配下すべてに影響します。隠しディレクトリ（.git や .ssh）も対象です
• サブディレクトリのファイルが全員書き込み可能になります
• ~/.ssh が含まれていた場合、SSH は権限が緩すぎる鍵を拒否するため、鍵認証でログインできなくなります

防止策

• -R を使う前に、対象を必ず ls -la で確認します
• まず -R なしで単一ファイル・単一ディレクトリに実行します
• 意図どおりか確認してから範囲を広げます
• ファイルとディレクトリで必要な権限は違います。まとめて変えず、find . -type f -exec chmod 644 {} + と find . -type d -exec chmod 755 {} + のように分けて指定します

実践課題（10分）

結論: 権限エラーを実際に体験しls -lで原因を読みとりどのコマンドで直すかを判断する。

以下のコマンドを実行して、権限エラーを体験してみましょう。作業用のディレクトリを新しく作るので、既存のファイルには影響しません。

$ mkdir perm-adv
$ cd perm-adv
$ touch test.txt
$ chmod u-w test.txt
$ echo test > test.txt

確認ポイント

1. Permission denied が出たか？
2. ls -l を見て理由を説明できるか？
3. どのコマンドで修正すべきか判断できるか？