Linux権限管理の基本：Permission denied を自力で直せるようになるまで
この記事でできること
ls -lの出力を見て「何が原因か」を判断できる- chmod / chown を使い分けて、正しい直し方を選べる
- 「とりあえず sudo」から卒業できる
想定読者：Ubuntuでサーバを触り始めた新人
前提：一部操作で sudo が必要
先に結論（判断の型）
1) ls -l で所有者・権限を見る → 2) 自分が owner / group / other のどれか判断 → 3) chmod か chown か sudo かを選ぶ
目次
まずは ls -l を読めるようになる（最重要）
権限トラブルの 9割は ls -l で解決の方向が見える。これを読めるようになるだけで、「なんとなく sudo」から卒業できます。
$ ls -l sample.txt
-rw-r--r-- 1 user user 1234 Dec 17 12:00 sample.txt
見る順番（この順で固定）
- 先頭の
-/d（ファイル or ディレクトリ） - 権限
rw-r--r-- - 所有者
user - グループ
user
なぜこの順番か：権限エラーの原因は「誰が」「何を」できるかの組み合わせ。この順番で見れば、原因を論理的に切り分けられます。
rwx の意味を「判断基準」として理解する
例：rw-r--r--
| 対象 | 権限 | できること |
|---|---|---|
| owner（所有者） | rw- | 読み書きOK、実行NG |
| group（グループ） | r-- | 読みのみ |
| other（その他） | r-- | 読みのみ |
判断例
- 自分が owner → 書ける
- group / other → 読めるだけ、書けない
自分がどの立場かを確認するには whoami と groups を使います。
chmod：まずは記号表記で考える（事故防止）
基本
$ chmod u+w sample.txt
意味：
u（所有者）にw（書き込み）を- 追加する
なぜ記号表記が安全か：「何を変えたか」が明確に分かる。chmod 644 と書くより、chmod u+w の方が意図が伝わり、レビューでも事故に気づきやすい。
よくある事故
$ chmod 777 sample.txt
問題点：
- 意味を理解せず実行しがち
- 不要に権限を広げる
→ 数値表記は後回しでOK。まず記号表記を使う
▶ なぜ chmod 777 は危険なのか？（クリックで展開）
777 は「誰でも読み書き実行できる」という意味です。
実際に起きた事故例
本番Webサーバで /var/www/html を chmod -R 777 にした結果：
- 攻撃者がPHPファイルをアップロード
- そのPHPが実行され、サーバを乗っ取られた
- 顧客データが流出、サービス停止
なぜ攻撃が成功したか
777 = other（誰でも）に w（書き込み）と x（実行）を許可。Webサーバ経由でファイルを置かれ、実行されてしまう。
安全な代替設定
| 対象 | 推奨値 | 理由 |
|---|---|---|
| ディレクトリ | 755 | 所有者のみ書き込み可 |
| ファイル | 644 | 所有者のみ書き込み可 |
| 秘密鍵等 | 600 | 所有者のみアクセス可 |
ディレクトリの実行権限に注意
drwxr-xr-x 2 user user 4096 Dec 17 12:10 mydir
- ディレクトリの
x：中に入れるかどうか（cd できるか） rだけではcdできない（ファイル一覧は見えるが入れない）
詰まり例
ls はできるのに cd できない
→ ディレクトリに x 権限がない可能性大
修正：chmod u+x mydir
chown：所有者変更は慎重に
基本
$ sudo chown user:user sample.txt
なぜ sudo が必要か：所有者の変更はシステム管理操作。一般ユーザが勝手に他人のファイルを自分のものにできたら危険だから。
よくある事故
/var/www配下を全部chown -R myuser→ Webサーバが動かなくなる- root 所有にして戻せなくなる
考え方：「なぜ所有者を変える必要があるのか？」を必ず考える
▶ chown -R で詰んだ話（復旧方法付き）
事故の経緯
$ sudo chown -R myuser:myuser /var/www/html
「自分のファイルを編集したい」と思って実行。結果：
- Apache/Nginx は
www-dataユーザで動作 - 所有者が変わったことで、Webサーバがファイルを読めなくなった
- サイトが 403 Forbidden で表示されなくなった
復旧方法
$ sudo chown -R www-data:www-data /var/www/html
正しいアプローチ
自分が編集したいなら、所有者を変えるのではなく：
- 自分を
www-dataグループに追加する - または
sudo -u www-data vim file.phpで編集する
sudo は魔法ではない
- sudo = root として実行するだけ
- 権限設計の問題を隠してしまうことがある
NGパターン
$ sudo chmod 777 ...
「Permission denied が出たから sudo」「それでもダメだから 777」。これは最悪のパターン。原因を理解せず、セキュリティホールを作っている。
推奨
- まず
ls -lで原因切り分け - 必要な場合だけ sudo
- sudo が必要な理由を説明できる状態で使う
▶ sudo の乱用で起きた実際の事故
事故パターン1：ファイルが編集できなくなる
$ sudo vim config.yaml
この後、普通に vim config.yaml で編集しようとすると：
E45: 'readonly' option is set (add ! to override)
原因：sudo で開いたときに root 所有になった（または .swp ファイルが root で作られた）
解決策
sudo chown $USER:$USER config.yamlで所有者を戻す- または最初から
sudoedit config.yaml（sudo -e）を使う
事故パターン2：ホームディレクトリが root 所有に
$ sudo chown -R root:root ~
結果：ログインできなくなる、.bashrc が読めない、SSH鍵が使えない。
復旧：別のroot権限セッションから chown -R user:user /home/user
よくある Permission denied の切り分け
ケース1：ファイルに書き込めない
$ echo "test" >> /etc/hosts
-bash: /etc/hosts: Permission denied
診断
$ ls -l /etc/hosts
-rw-r--r-- 1 root root 221 Dec 17 10:00 /etc/hosts
原因
- 所有者は
root - 自分は
otherの立場 →r--（読みのみ）
ありがちな勘違い
「sudo すればいい」→ 半分正解、半分不正解
/etc/hosts はシステムファイルなので、意図的に root のみ書き込み可にしている。sudo で編集すること自体は正しいが、「なぜ保護されているか」を理解した上で使うこと。
ケース2：スクリプトが実行できない
$ ./deploy.sh
-bash: ./deploy.sh: Permission denied
診断
$ ls -l deploy.sh
-rw-r--r-- 1 user user 1234 Dec 17 11:00 deploy.sh
原因
- 権限が
rw-r--r--→ 実行権限（x）がない - 自分が所有者なのに実行できない
修正
$ chmod u+x deploy.sh $ ./deploy.sh
なぜこの方法が安全か：u+x は所有者にだけ実行権限を付与。他のユーザには影響しないので、必要最小限の変更。
ケース3：ディレクトリに入れない
$ cd /var/log/nginx
-bash: cd: /var/log/nginx: Permission denied
診断
$ ls -ld /var/log/nginx
drwxr-x--- 2 www-data adm 4096 Dec 17 10:00 /var/log/nginx
原因
- 権限が
rwxr-x---→ other には何も許可されていない - 自分は
www-dataでもadmでもない
修正オプション
sudo cdは使えない（cd はシェル組み込み）→sudo ls /var/log/nginxで中身を見る- 自分を
admグループに追加：sudo usermod -aG adm $USER（再ログイン必要）
実践課題（5分）
$ mkdir ~/perm-test $ cd ~/perm-test $ touch a.txt $ ls -l $ chmod u-w a.txt $ echo "test" > a.txt
期待結果：
- Permission denied が出る
ls -lを見て「自分が owner だが w がない」と説明できる
復旧：
$ chmod u+w a.txt $ echo "test" > a.txt $ cat a.txt
test
次に読む
検証環境
本記事のコマンドは Ubuntu 24.04 LTS / bash 5.2 で動作確認済みです。
実践で権限管理をマスターしよう
この記事で紹介した「判断の型」を身につけたら、Penguin Gym Linuxの実践課題で手を動かして定着させましょう。