こんにちは、かつコーチです。
Linuxを触り始めると、ls -lを打ったときに出てくる-rwxr-xr--のような謎の文字列に戸惑った経験はありませんか。
この記事では、Linuxのパーミッション（アクセス権限）の仕組みを、Ubuntu 26.04 LTSでの実例を交えながら初心者向けに解説します。
パーミッションとは？
パーミッションの定義：誰が何をできるかのルール
パーミッションとは、ファイルやディレクトリに対して「誰が」「何を」できるかを定めたアクセス権限のことです。
Linuxは複数のユーザーが同時に使うことを前提に設計されたOSです。
そのため、自分のファイルを他人に勝手に読まれたり、書き換えられたりしないように、ファイル単位で権限を細かく管理する仕組みが備わっています。
これがパーミッションの正体です。
なぜパーミッションが必要なのか
例えば、Webサーバーの設定ファイルに誰でも書き込めてしまうと、悪意のある第三者や誤操作によって、サイトが簡単に壊れてしまいます。
パーミッションを適切に設定することで、以下のようなことが実現できます。
- 重要な設定ファイルを、管理者以外は書き換えられないようにする
- 実行ファイルだけに「実行権限」を与え、意図しないファイルが実行されるのを防ぐ
- 複数人でサーバーを共有する場合に、他人のファイルを誤って削除できないようにする
つまり「意図しない変更・実行・閲覧を防ぐ」ためのセキュリティの土台が、パーミッションです。
基本の書き方：rwxを読み解く
ls -lの出力を分解する
まずは実際にターミナルで確認してみましょう。
$ ls -l sample.txt
-rw-r--r-- 1 katsu katsu 1024 9月 2 10:00 sample.txt
先頭の-rw-r--r--という10文字が、パーミッションの表示です。
これは以下のように分解できます。
| 位置 | 内容 | 例 |
|---|---|---|
| 1文字目 | ファイルの種類 | -（通常ファイル）、d（ディレクトリ） |
| 2〜4文字目 | 所有者（オーナー）の権限 | rw- |
| 5〜7文字目 | 所有グループの権限 | r-- |
| 8〜10文字目 | その他のユーザーの権限 | r-- |
所有者とはそのファイルを作成した（あるいは所有権を持つ）ユーザー、所有グループとはそのユーザーが属するグループのことです。
それ以外の全ユーザーが「その他」に分類されます。
r・w・xがそれぞれ意味すること
3文字1組のrwxは、それぞれ次の権限を表します。
r（read）：ファイルの中身を読む権限w（write）：ファイルの中身を書き換える権限x（execute）：ファイルをプログラムとして実行する権限
権限がない場合は-で表示されます。
例えばrw-なら「読み書きはできるが実行はできない」、r-xなら「読むことと実行はできるが書き込みはできない」という意味になります。
ディレクトリの場合は少し意味が変わり、rは「中の一覧を見る」、wは「中にファイルを作成・削除する」、xは「そのディレクトリに移動する（cdする）」権限を指します。
このディレクトリのx権限を見落とすと、後述するようなつまずきに直結するので注意してください。
数字表記（8進数）の読み方
パーミッションはrwxr-xr--のような文字表記のほか、754のような数字（8進数）でも表現されます。
これはr=4、w=2、x=1として、権限がある文字の数字を足し合わせたものです。
$ chmod 754 script.sh
例えば754を分解すると以下のようになります。
- 所有者：
7 = 4+2+1 = rwx（読み書き実行すべて可能） - グループ：
5 = 4+0+1 = r-x（読む・実行のみ） - その他：
4 = 4+0+0 = r--（読むのみ）
数字表記は一見取っつきにくいですが、慣れると文字表記より短く書けるので、現場ではよく使われます。
よくあるつまずきポイント・エラー対処
ディレクトリのx権限を忘れてPermission deniedになる
私が初めてUbuntuサーバーで作業していたとき、あるディレクトリの中にあるファイルの中身を読もうとして、以下のエラーに何度もハマりました。
$ cat /home/deploy/app/config/app.php
cat: /home/deploy/app/config/app.php: Permission denied
ファイル自体にはr--r--r--と読み取り権限がついているのに、なぜかエラーになる。
原因を調べたところ、途中のappディレクトリにx権限がついていなかったことが判明しました。
❌Before：ファイルの権限だけを見て「読めるはずなのに読めない」と悩み続ける
✅After：ファイルまでのパス上にあるすべてのディレクトリのx権限を確認する
$ ls -ld /home/deploy/app
drwxr-x--- 2 deploy deploy 4096 9月 2 10:00 /home/deploy/app
ls -ld（-dオプション）でディレクトリ自体の権限を確認すると、その他ユーザーにはx権限すらないことが分かりました。
ディレクトリにxがないと、そもそもそのディレクトリの中へ移動（アクセス）できないため、中のファイルがどんな権限でも読めません。
このように「ファイルの権限」と「そこに至るディレクトリすべての権限」は別物だと意識しておくと、無駄な調査時間を減らせます。
自分のファイルなのにPermission deniedになる
もう1つよくあるのが、所有者と実行ユーザーの不一致です。
$ ./deploy.sh
bash: ./deploy.sh: Permission denied
これはdeploy.shに実行権限（x）がそもそも付いていないケースがほとんどです。
❌Before：ファイルが存在するのに実行できず、パスの指定ミスだと勘違いする
✅After：ls -lでx権限の有無を確認し、なければ付与する
$ ls -l deploy.sh
-rw-r--r-- 1 katsu katsu 512 9月 2 10:00 deploy.sh
xが1つもついていないため、実行権限を付与すれば解決します（具体的な変更方法は次回のchmod・chown編で解説します）。
応用・一歩先の使い方
umaskによるデフォルト権限の理解
新しくファイルを作成したとき、デフォルトでrw-r--r--（644）のような権限がつくのを不思議に思ったことはないでしょうか。
これはumaskという値によって、作成時のデフォルト権限が制御されているためです。
$ umask
0022
Ubuntuの一般ユーザーではumaskの初期値が022であることが多く、ファイルは最大権限666から022を差し引いた644、ディレクトリは777から022を差し引いた755が初期値になります。
サーバー構築時に「なぜか作成したファイルが想定より緩い権限になっている」と感じたら、umaskの設定を疑ってみましょう。
SUID・SGID・スティッキービットの存在
rwxの3種類に加えて、特殊な権限としてSUID・SGID・スティッキービットが存在します。
これらは「実行時だけ所有者の権限で動作させる」「共有ディレクトリで他人のファイルを削除させない」といった、より高度な制御に使われます。
例えばpasswdコマンドがSUID付きになっているからこそ、一般ユーザーでも自分のパスワードを変更できます。
この仕組みは中級以上の内容になるため、まずはrwxの基本を固めてから学ぶのがおすすめです。
まとめ
この記事のポイント
- パーミッションはファイル・ディレクトリごとの「誰が何をできるか」を定めるルール
rwxはそれぞれ読み取り・書き込み・実行を意味し、所有者・グループ・その他の3段階で設定される- 数字表記（例：
754）はr=4, w=2, x=1の合計で表す - ディレクトリの
x権限がないと、中のファイルにアクセスできない点は特に見落としやすい - デフォルト権限はumaskによって制御される
次に読むべき記事
パーミッションの仕組みが分かったら、次は実際に権限を変更する「chmod・chownでパーミッションを変更する」に進んでみてください。
今回学んだrwxと数字表記の知識が、そのままコマンドの理解に直結します。
タグ: Linux, 初心者向け, 権限管理