Linuxのファイル権限：chmod、chown、sudoを例で解説

Linuxのファイル権限は、「誰が、そのファイルに何をできるか」を決めます。すべてのファイルには所有者、グループ、そして3組の権限があります。所有者向け、グループ向け、その他全員向けです。権限は chmod で変更し、所有者は chown で変更し、管理者としての操作は sudo で実行します。ここでは権限の読み方、変更の仕方、そして Permission denied エラーの直し方を説明します。

ファイルの権限を確認する

権限は ls -l の出力で確認できます。

$ ls -l
-rw-r--r-- 1 alice developers  1204 Oct 10 14:02 notes.txt
-rwxr-xr-x 1 alice developers   356 Oct 10 14:05 deploy.sh
drwxr-x--- 2 alice developers  4096 Oct 10 13:50 secrets

先頭の10文字は次のように読みます。

• 1文字目は種類。- は通常のファイル、d はディレクトリ、l はシンボリックリンク。
• 2〜4文字目は所有者（user）の権限。
• 5〜7文字目はグループ（group）の権限。
• 8〜10文字目はその他（others）の権限。

その後にはハードリンク数、所有者（alice）、グループ（developers）、サイズ、日時、名前が続きます。1つのファイルを確認するには stat が便利です。

$ stat -c '%A %a %U:%G %n' deploy.sh
-rwxr-xr-x 755 alice:developers deploy.sh

r、w、xの意味

権限の意味はファイルとディレクトリで異なります。これが混乱の主な原因です。

注意すべき点があります。ディレクトリに w と x があれば、ファイル自体に書き込み権限がなくても、そのファイルを削除できます。ディレクトリに x がないと、ファイルの読み取りが許可されていても、中のファイルを開けません。

システムは次の順に権限を確認します。自分が所有者なら所有者の権限を、そうでなければ自分がファイルのグループに属していればグループの権限を、どちらでもなければその他の権限を適用します。rootユーザーは読み書きの権限チェックを免除されます。

数値表記：755、644、600

各権限には値があります。r = 4、w = 2、x = 1。3組それぞれの値を足すと、0から7までの数字になります。

よく使われる組み合わせは覚えておくと便利です。

chmodコマンド：権限を変更する

数値モード

数値表記では権限をまとめて指定します。

chmod 644 index.html
chmod 755 deploy.sh
chmod 600 ~/.ssh/id_ed25519

記号モード

記号表記では、他の権限には触れず、必要な部分だけを変更できます。対象は u（所有者）、g（グループ）、o（その他）、a（全員）。操作は +（追加）、-（削除）、=（正確に設定）です。

chmod +x deploy.sh        # 実行を許可
chmod u+x,g-w file        # 所有者は実行可能、グループは書き込み不可
chmod o-rwx secrets/      # その他のユーザーには何も許可しない
chmod g=rx app/           # グループには読み取りと移動だけを許可

再帰的に変更する：ファイルとディレクトリを分けて扱う

-R オプションを付けると、ディレクトリツリー全体に権限が適用されます。ただし chmod -R 755 では、すべてのファイルが実行可能になってしまい、通常は望ましくありません。find を使って、ファイルとディレクトリを分けて設定するのが安全です。

find /srv/site -type d -exec chmod 755 {} +
find /srv/site -type f -exec chmod 644 {} +

短く書く方法もあります。大文字の X は、ディレクトリと、すでに実行権限を持つファイルにだけ実行権限を付けます。

chmod -R u=rwX,go=rX /srv/site

chownコマンド：所有者とグループを変更する

ファイルの所有者を変更できるのはrootだけなので、chown は通常 sudo 経由で実行します。

sudo chown alice report.txt               # 所有者
sudo chown alice:developers report.txt    # 所有者とグループ
sudo chown :www-data index.html           # グループのみ
sudo chown -R www-data:www-data /var/www/site

グループだけを変更するには chgrp があります。例：sudo chgrp developers report.txt。自分の所属グループは id または groups で確認できます。

$ id
uid=1000(alice) gid=1000(alice) groups=1000(alice),27(sudo),1001(developers)

ユーザーをグループに追加するには sudo usermod -aG developers bob を使います。-a オプションは必須です。付けないと、そのユーザーは他の追加グループから外れてしまいます。新しいグループは再ログイン後に有効になります。

sudo：管理者として操作する

sudo は、1つのコマンドをrootまたは他のユーザーとして実行します。入力するのはrootのパスワードではなく、自分のパスワードです。すべての実行はログに記録されるため、誰が何をしたかが分かります。

sudo apt update
sudo systemctl restart nginx
sudo -u postgres psql       # postgresユーザーとして実行
sudo -i                     # 対話的なrootシェル
sudo -l                     # 自分に許可されているコマンドを表示

誰に何が許可されるかは /etc/sudoers と /etc/sudoers.d/ のファイルで定義されます。これらのファイルは必ず sudo visudo で編集してください。保存前に構文をチェックしてくれるため、誤った記述でsudoが使えなくなることを防げます。Ubuntuでは sudo グループに所属させることで管理者権限が与えられ、RHEL系では wheel グループを使います。

# /etc/sudoers.d/deploy — ユーザーdeployはnginxの再起動だけを許可
deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart nginx

sudo echo > file がうまくいかない理由

よくある落とし穴です。

$ sudo echo "127.0.0.1 test.local" >> /etc/hosts
bash: /etc/hosts: Permission denied

リダイレクト >> を処理するのは sudo ではなくシェルなので、ファイルはroot権限なしで開かれます。正しくは tee を使います。

echo "127.0.0.1 test.local" | sudo tee -a /etc/hosts

Permission denied：原因と対処

Permission denied は、カーネルがプロセスの操作を拒否したことを意味します。調べる手順は常に同じです。自分が誰か（id）、所有者と権限は何か（ls -l）、経路上の各ディレクトリの権限は何か（namei -l）を確認します。

$ namei -l /srv/app/config/app.env
f: /srv/app/config/app.env
drwxr-xr-x root  root  /
drwxr-xr-x root  root  srv
drwxr-x--- deploy deploy app
drwxr-xr-x deploy deploy config
-rw-r----- deploy deploy app.env

この例では、ディレクトリ app がその他のユーザーに閉じられています。deploy グループに属さないユーザーは、ファイル自体の権限がどうであれ、そこから先へ進めません。

スクリプトが実行できない

$ ./deploy.sh
bash: ./deploy.sh: Permission denied

ファイルに実行権限がありません。chmod +x deploy.sh で付与するか、bash deploy.sh のようにインタープリタを指定して実行します。パーティションが noexec オプション付きでマウントされている場合（/tmp でよくあります）は、ファイルを直接実行できないため、後者の方法を使うしかありません。

システムディレクトリに書き込めない

/etc、/usr、/var/www のファイルは、rootまたはシステムユーザーの所有です。一時的な変更には sudo を使ってください。継続的な作業では、全員に権限を与えるのではなく、グループに権限を与えるべきです。

Webサーバーが403を返す

NginxやApacheは（DebianとUbuntuでは）www-data ユーザーで動作します。このユーザーにはファイルの読み取り権限と、経路上のすべてのディレクトリの x 権限が必要です。対処法は sudo chown -R www-data:www-data /var/www/site、またはディレクトリを 755、ファイルを 644 にすることです。

SSHが鍵を受け付けない

権限が開きすぎている鍵は、SSHが拒否します。秘密鍵は 600、ディレクトリ ~/.ssh は 700、サーバー上の authorized_keys は 600 である必要があります。

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519 ~/.ssh/authorized_keys

Dockerに接続できない

permission denied while trying to connect to the Docker daemon socket と表示されたら、docker グループに入っていません。sudo usermod -aG docker $USER を実行して再ログインしてください。このグループのメンバーは、実質的にroot権限を持つことに注意してください。

chmod 777 が悪い考えである理由

「とりあえず chmod 777 にすれば直る」という助言はエラーを消しますが、そのファイルへの書き込みをすべてのユーザーとプロセスに許してしまいます。Webアプリケーションが乗っ取られると、攻撃者はそのファイルを書き換えられます。正しい方法は、どのユーザーにアクセスが必要かを特定し、所有者またはグループを通じてその人にだけ権限を与えることです。

umask：デフォルトの権限

新しく作られるファイルの権限は、umask によって決まります。一般的な値 022 では、ファイルは 644、ディレクトリは 755 で作成されます。

$ umask
0022

まとめ

Linuxの権限は、所有者、グループ、その他のユーザーそれぞれの3組のrwxです。chmod は数値（755、644、600）または記号で権限を変更し、chown は所有者を変更します。sudo は1つのコマンドをrootとして実行することを許可します。Permission denied が出たら、ユーザー、ファイルの権限、経路上の各ディレクトリの権限を確認してください。777で問題を隠すのではなく、原因を直しましょう。ユーザー、グループ、権限、sudoは、Linuxコースで実践を通して詳しく扱います。