chmod・chownの使い方 - Permission deniedを自力で直せるようになるまで

権限管理基礎 - パーミッションの理解
読了時間: 約12分 難易度: 初級

この記事でできること

  • ls -l の出力を見て「何が原因か」を判断できる
  • chmod / chown を使い分けて、正しい直し方を選べる
  • 「とりあえず sudo」から卒業できる

想定読者：Ubuntuでサーバを触り始めた新人

前提：一部操作で sudo が必要

先に結論（判断の型）

1) ls -l で所有者・権限を見る → 2) 自分が owner / group / other のどれか判断 → 3) chmod か chown か sudo かを選ぶ

目次

  1. 判断フロー（早見表）
  2. まずは ls -l を読めるようになる（最重要）
  3. rwx の意味を「判断基準」として理解する
  4. chmod：まずは記号表記で考える（事故防止）
  5. ディレクトリの実行権限に注意
  6. chown：所有者変更は慎重に
  7. sudo は魔法ではない
  8. よくある Permission denied の切り分け
  9. 権限問題診断チェックリスト
  10. 実践課題（5分）
  11. 次に読む

判断フロー（早見表）

Permission denied が発生したとき、以下の表を上から順にチェックしてください。

症状 確認コマンド 原因 対処
ファイルに書き込めない ls -l ファイル名 w権限がない chmod u+w ファイル名
スクリプトが実行できない ls -l スクリプト名 x権限がない chmod u+x スクリプト名
ディレクトリに入れない ls -ld ディレクトリ名 x権限がない chmod u+x ディレクトリ名
他ユーザのファイルを操作したい ls -l ファイル名 所有者が異なる sudo chown $USER ファイル名（$USER は現在のユーザ名に自動展開）
システムファイルを編集したい ls -l /etc/ファイル名 root所有のファイル sudoedit /etc/ファイル名（sudo vim より安全 — 編集中のファイルの所有者が変わらない）

重要な確認手順

  1. whoami で自分のユーザ名を確認
  2. groups で所属グループを確認
  3. ls -l で所有者・グループ・権限を確認
  4. 自分が owner / group / other のどれかを判断

まずは ls -l を読めるようになる（最重要）

権限トラブルの 9割は ls -l で解決の方向が見える。これを読めるようになるだけで、「なんとなく sudo」から卒業できます。

$ ls -l sample.txt
-rw-r--r-- 1 user user  1234 Dec 17 12:00 sample.txt

見る順番（この順で固定）

  1. 先頭の - / d（ファイル or ディレクトリ）
  2. 権限 rw-r--r--
  3. 所有者 user
  4. グループ 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サーバ経由でファイルを置かれ、実行されてしまう。

安全な代替設定

数値表記の読み方：r=4, w=2, x=1 の合計。例えば 755 = rwx(7) + r-x(5) + r-x(5) = 所有者は全権限、グループとその他は読み取りと実行のみ。

対象推奨値権限の意味理由
ディレクトリ755rwxr-xr-x所有者のみ書き込み可
ファイル644rw-r--r--所有者のみ書き込み可
秘密鍵等600rw-------所有者のみアクセス可

ディレクトリの実行権限に注意

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 でもない

修正オプション

  1. sudo cd は使えない（cd はシェル組み込み）→ sudo ls /var/log/nginx で中身を見る
  2. 自分を adm グループに追加：sudo usermod -aG adm $USER（再ログイン必要 — グループ情報はログイン時に読み込まれるため）

権限問題診断チェックリスト

Permission denied が発生したとき、以下を順番に確認してください。

Step 1: 自分の立場を確認

  • whoami で自分のユーザ名を確認した
  • groups で所属グループを確認した

Step 2: ファイル/ディレクトリの状態を確認

  • ls -l ファイル名 で権限・所有者を確認した
  • 自分が owner / group / other のどれかを判断した
  • 必要な権限（r/w/x）が自分の立場に付与されているか確認した

Step 3: 対処方法を選択

  • 権限不足 → chmod で権限を追加
  • 所有者が異なる → chown で所有者を変更（要sudo）
  • システムファイル → sudoedit または sudo を使用

Step 4: 変更後の確認

  • 再度 ls -l で変更が反映されたことを確認
  • 目的の操作が成功することを確認
  • 過剰な権限（777等）を付与していないことを確認

実践課題（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

まとめ

この記事で紹介した「判断の型」を身につけたら、Penguin Gym Linuxの実践課題で手を動かして定着させましょう。

コマンド早見表

目的 コマンド 例
権限・所有者確認 ls -l ls -l sample.txt
自分のユーザ名確認 whoami whoami
所属グループ確認 groups groups
書き込み権限を追加 chmod u+w chmod u+w sample.txt
実行権限を追加 chmod u+x chmod u+x script.sh
所有者を変更 sudo chown sudo chown user:user file.txt
システムファイル編集 sudoedit sudoedit /etc/hosts

覚えておくべき3つのポイント

  1. まず ls -l：権限トラブルの9割はこれで原因がわかる
  2. 記号表記を使う：chmod u+w は意図が明確で安全
  3. sudo は最後の手段：原因を理解してから使う
Penguin Gym Linuxで実践練習 次の記事: 権限管理（応用編）