chmod・chownの使い方 - Linux権限管理の基本とPermission denied対策

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

この記事でできること：

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

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

前提：一部の操作では sudo が必要です。

用語の整理：パーミッションファイルやディレクトリに対する「読む・書く・実行する」権限の設定。（permission）とは、「だれがそのファイルを読めるか・書けるか・実行できるか」の設定のことです。日本語では「権限」「アクセス権」とも呼びます。この記事では「権限」で統一します。

**rootすべての操作が許可された特別な管理者ユーザー。（ルート）**とは、何でもできる管理者のユーザー名です。**sudo（スードゥ）**は「このコマンドだけ root として実行する」という指示です。グループとは、複数のユーザーをまとめた集まりのことです。

判断フロー（早見表）

結論: Permission denied が出たら、まず ls -l で所有者と権限を見る。そのうえで chmod・chown・sudo のどれを使うかを選ぶ。

Permission denied が出たときは、次の表を上から順にチェックしてください。

ls -ld の -d は、ディレクトリ自身の情報を表示するオプションです。付けないと中身の一覧が出ます。

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

結論: 権限トラブルの9割は ls -l で解決の方向が見える。まずここを読めるようにするのが最優先だ。

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

$ ls -l sample.txt

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

なぜこの順番か：権限エラーの原因は「誰が」「何を」できるかの組み合わせです。この順番で見れば、原因を論理的に切り分けられます。

rwx の意味を「判断基準」として理解する

結論: owner・group・other のどの立場かで、できることが変わる。そこを判断の基準にする。

r は読み取り、w は書き込み、x は実行を表します。この3文字が3回くり返され、owner・group・other の順に並びます。

例：rw-r--r--

図1: Linux は owner → group → other の順に判定し、最初に当てはまった1組の rwx だけを適用します。owner に該当した時点で、group や other の権限は見ません。図が示すのは「どの1組が適用されるか」であり、その中身が許可かどうかは別の話です（適用された組が --- なら何もできません）。

chmod：まずは記号表記で考える（事故防止）

結論: 記号表記の u+w や u+x を基本にする。意味を説明できない数値表記は後回しでよい。

基本

$ chmod u+w sample.txt

chmod（change mode）は、ファイルの権限を変えるコマンドです。

意味：

• u（所有者）に対して、
• w（書き込み）を、
• 追加します。

なぜ記号表記が安全か：「何を変えたか」が明確に分かるからです。chmod 644 と書くより chmod u+w の方が意図が伝わります。レビューでも事故に気づきやすくなります。

$ chmod 777 sample.txt

失敗するとどうなるか：chmod はファイルの中身を書きかえません。ただし「1つ前に戻す」コマンドはありません。実行の前に ls -l の出力を控えておき、その状態に合わせて戻してください。

安全に試す方法：練習は ~/perm-test のような自分専用のディレクトリで行ってください。システムのファイルには影響しません。

なぜ chmod 777 は危険なのか？

777 は「誰でも読み書き実行できる」という意味です。

実際に起きた事故例

-R は、そのディレクトリの中身すべてに同じ設定を適用するオプションです。本番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) を表します。所有者は全権限、グループとその他は読み取りと実行だけになります。

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

結論: ディレクトリに x がないと cd できない。ls -ld で確認し、u+x を最小限だけ足す。

drwxr-xr-x 2 user user 4096 Dec 17 12:10 mydir

ディレクトリの x は「中に入れるかどうか」を表します。cd できるかどうか、と言いかえられます。r だけでは cd できません。ファイル一覧は見えますが、中には入れません。

chown：所有者変更は慎重に

結論: 所有者の変更は理由を説明できるときだけ行う。-R はサービス停止を招くので特に慎重に。

基本

$ sudo chown user:user sample.txt

chown（change owner）は、ファイルの持ち主を変えるコマンドです。

なぜ sudo が必要か：所有者の変更はシステム管理の操作だからです。一般ユーザーが他人のファイルを勝手に自分のものにできたら危険です。

失敗するとどうなるか：chown には取り消しコマンドがありません。元に戻すには、変更前の所有者名を自分で覚えておく必要があります。

安全に試す方法：実行の前に ls -l の出力を控えておいてください。所有者名が残っていれば、同じ chown で元に戻せます。

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 は根本原因を隠してしまう。先に ls -l で切り分け、理由を説明できるときだけ使う。

sudo は root として実行するだけのコマンドです。権限設計の問題をそのまま隠してしまうことがあります。

$ sudo chmod 777 ...

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 の切り分け

結論: ls -l で所有者と権限を確認する。自分が owner・group・other のどれかを特定してから対処する。

ケース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 で編集すること自体は正しい対処です。ただし「なぜ保護されているか」を理解したうえで使ってください。

修正

$ sudoedit /etc/hosts

追記だけなら次のコマンドでもできます。

$ echo "test" | sudo tee -a /etc/hosts

なぜ sudo echo "test" >> /etc/hosts は失敗するか：>> を処理するのはシェル入力したコマンドを解釈してコンピュータに実行させる対話プログラム。であり、sudo の外側で動きます。root 権限が及ぶのは echo だけなので、書き込みは一般ユーザー権限のまま拒否されます。

ケース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 を実行し、再ログインします。グループ情報はログイン時に読み込まれるためです。

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

結論: whoami と groups で自分の立場を確認する。次に ls -l で権限を見て、対処方法を選ぶ。

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分）

結論: chmod u-w でわざと権限を外す。権限エラーを体験し、修正コマンドを自力で判断する。

この課題は自分専用の練習ディレクトリで行います。システムのファイルは触らないため、失敗しても環境は壊れません。

$ 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