Linux権限管理【応用編】：chmod・chown・sudoを"使い分けられる"ようになる
権限管理の基礎を終えたら、次は「状況に応じて使い分ける判断力」を身につけましょう。chmod・chown・sudoは便利ですが、使う順番と判断基準を間違えると事故につながります。
目次
1. 先に結論（判断の型）
権限トラブルに遭遇したら、この順番を崩さない。
ls -lで 所有者・グループ・権限 を確認- 自分が owner / group / other のどれかを判断
- 修正方法を選ぶ
- 権限を足す →
chmod - 所有者を変える →
chown - 一時的に突破 →
sudo（最後の手段）
- 権限を足す →
「とりあえず sudo」は事故の入口です。原因を理解せずに突破すると、後で取り返しがつかなくなることがあります。
2. chmod を"判断付き"で使う
まずは記号表記で考える（安全第一）
$ chmod u+w report.txt
-rw-r--r-- 1 user user 2048 report.txt
- 所有者（u）に書き込み権限（w）を追加
- 影響範囲が限定的で事故りにくい
なぜ安全か
- 変更対象（u/g/o）が明示される
- 既存権限を壊しにくい
危険な例：数値表記を雑に使う
$ chmod 777 report.txt
問題点
- 全員に書き込み・実行権限
- 意図しない改変・実行リスクが跳ね上がる
数値表記は「意味を説明できるときだけ」使う。644や755の意味を即答できないなら、記号表記を優先しよう。
▶ なぜ chmod 777 は危険なのか？
777 = 誰でも何でもできる
- r（読み取り）+ w（書き込み）+ x（実行）を全員に付与
- 共有サーバーでは他ユーザーが悪意あるコードを書き込める
実際に起きた事故例
本番サーバーで /var/www を 777 にしたケース：
- 攻撃者がPHPファイルを改ざん
- Webシェル（遠隔操作ツール）を設置された
- サーバー全体が乗っ取られる事態に
安全な代替
- ディレクトリ:
755（所有者のみ書き込み、他は読み取り・実行） - ファイル:
644（所有者のみ書き込み、他は読み取りのみ）
▶ umask：新規ファイルのデフォルト権限を決める
なぜ新規ファイルは 644 になるのか？
umask が「引き算」しているから。
$ umask
0022
計算式
- ファイル：666 - 022 = 644
- ディレクトリ：777 - 022 = 755
実務での使いどころ
- 共有ディレクトリでグループ書き込みを許可したい →
umask 002 - セキュリティ強化で他者の読み取りを禁止したい →
umask 077
変更は一時的：umaskはシェルセッション内でのみ有効。永続化は ~/.bashrc に記述。
3. ディレクトリ権限の落とし穴（応用で一番事故る）
drwxr--r-- 2 user user 4096 logs/
症状
ls logsはできるcd logsはできない（Permission denied）
理由
- ディレクトリの
xは「中に入れる権利」 rだけでは不十分
対応
$ chmod u+x logs
なぜこの対応が正しいか
- 必要最小限の権限追加
- 他ユーザーへの影響を広げない
4. chown：所有者変更は"最終判断"
正しい使いどころ
$ sudo chown user:user app.log
ファイルの所有者が明確にズレている場合のみ使用する。
実際に起きがちな事故
$ sudo chown -R user:user /var/www
何が起きるか
- サービスユーザー（www-data等）が壊れる
- Webサーバが起動しなくなる
「なぜ所有者を変える必要があるか」を言語化できないなら実行しない
▶ 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で対象を確認 - サービスディレクトリは特に慎重に
5. sudo は魔法ではない
$ sudo rm important.txt
- 実行できる ≠ 正しい
- sudo は「原因を隠す」ことが多い
安全な考え方
- sudo は「一時的な突破」
- 恒久対応は chmod / chown で行う
▶ sudo 連打で後戻り不能になった話
よくあるパターン
Permission deniedが出る- 「とりあえず sudo」で実行
- 作成されたファイルが root 所有に
- 次から自分で編集できない
- 「また sudo」で対応…
- 気づいたら root 所有ファイルだらけ
実例
# これをやると… $ sudo vim config.yaml # config.yaml が root 所有になる $ ls -l config.yaml -rw-r--r-- 1 root root 1024 config.yaml # 次から編集できない $ vim config.yaml # Permission denied...
正しい対応
- sudo を使う前に「なぜ権限がないか」を確認
sudo -e（sudoedit）でファイル編集する- 作業後に所有者を確認・修正する
▶ 代替案：所有者を変えない設計
そもそも権限トラブルを起こさない方法
1. 実行ユーザーを揃える
アプリケーションの出力先を、実行ユーザーが書き込めるディレクトリに変更する。
2. グループ権限で解決する
# 開発者グループを作成 $ sudo groupadd developers # ユーザーをグループに追加 $ sudo usermod -a -G developers user # ディレクトリのグループを変更 $ sudo chgrp developers /path/to/project $ sudo chmod g+w /path/to/project
3. アプリ側の設定を変更する
ログ出力先、一時ファイル保存先などを、権限トラブルが起きにくい場所に設定する。
6. エラーメッセージ起点の切り分け（具体例）
ケース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 .
何が起きるか
- 意図しない範囲まで影響
- サブディレクトリ全てが全公開状態に
- 本番環境では致命傷
防止策
-Rを使う前に、対象を必ずlsで確認- まず
-Rなしで単一ファイル/ディレクトリに実行 - 意図通りか確認してから範囲を広げる
7. 実践課題（10分）
以下のコマンドを実行して、権限エラーを体験してみましょう。
$ mkdir perm-adv $ cd perm-adv $ touch test.txt $ chmod u-w test.txt $ echo test > test.txt
確認ポイント
Permission deniedが出たか？ls -lを見て理由を説明できるか？- どのコマンドで修正すべきか判断できるか？
回答例
ls -l test.txt→-r--r--r--（書き込み権限がない）- 自分が所有者なので
chmod u+w test.txtで解決
8. 次に読む
📋 検証環境
本記事のコマンドは Ubuntu 24.04 LTS / bash 5.2 で動作確認済みです。
🔐 権限管理シリーズ全体
🎉 実践で判断力を身につけよう
この記事で学んだ「判断の型」を、実際のターミナルで試してみましょう。Penguin Gym Linux の仮想環境なら、安全に権限操作を練習できます。