Linuxエンジニア養成講座 第11回|全36回・フェーズ2「Linux基礎」の8回目です。
前回までに学んだこと: ユーザーとグループの仕組み、/etc/passwd と /etc/shadow の読み方、useradd・usermod・userdel、sudo の仕組み(第10回)。
今回学ぶこと: ファイルのパーミッション(rwx)と所有権、chmod・chown・umask、特殊パーミッション(SUID/SGID/Sticky Bit)の概念。
この記事を読み終えると、以下のことができるようになります。
ls -lの出力からファイルの所有者・グループ・パーミッション(rwx)を読み取れる- シンボリック表記(u+x, g-w 等)で chmod を使ってパーミッションを変更できる
- オクタル表記(755, 644 等)を読み書きでき、chmod で使用できる
- chown でファイルの所有者・グループを変更できる
- umask の仕組みを理解し、デフォルトパーミッションとの関係を説明できる
- SUID/SGID/Sticky Bit の概念を説明できる
alma-mainにSSH接続した状態で進めます。以降のコマンドはすべてalma-main上で実行します。
なぜパーミッションを学ぶのか
前回、ユーザーとグループの仕組みを学びました。その末尾で「trainee01 が developer のファイルにアクセスできないのはなぜか」という問いを残しました。答えは「パーミッション」です。
Linuxでは、すべてのファイルとディレクトリに「誰が読めるか」「誰が書けるか」「誰が実行できるか」というルールが設定されています。このルールがパーミッション(権限)です。ユーザーとグループが「誰なのか」を決める仕組みだとすれば、パーミッションは「その人が何をできるか」を決める仕組みです。
前回、/etc/passwd は一般ユーザーでも読めるのに /etc/shadow は root しか読めないことを確認しました。この違いを生んでいるのがパーミッションです。実際にパーミッションの数字で確認してみます。
実行コマンド:
$ ls -la /etc/passwd /etc/shadow
実行結果:
-rw-r--r--. 1 root root 1001 3月 29 18:25 /etc/passwd
----------. 1 root root 733 3月 29 18:25 /etc/shadow
/etc/passwd の左端は -rw-r--r--、/etc/shadow は ---------- です。この文字列がパーミッションを表しています。第3回「セキュリティ意識の基本」で学んだ「最小権限の原則」がLinux上でどう実装されているか、今回はその仕組みを手を動かしながら理解します。
パーミッションの設定ミスは現場でトラブルに直結します。Webサーバーの公開ディレクトリに不適切な権限を設定すれば、外部からファイルを書き換えられるセキュリティ事故につながります。逆に権限を絞りすぎれば、サービスが動作しません。今回学ぶ内容は、第29回でWebサーバーを構築する際にも必須になります。
ls -l の出力を読み解く
これまでの回で ls -l の出力は何度も目にしてきました。左端に並ぶ drwxr-xr-x のような文字列の正体を、今回ようやく解明します。
10文字の意味
ホームディレクトリの内容を確認してみます。
実行コマンド:
$ ls -la /home/developer/
実行結果:
合計 16
drwx------. 3 developer developer 95 3月 24 13:06 .
drwxr-xr-x. 3 root root 23 3月 29 18:25 ..
-rw-------. 1 developer developer 46 3月 24 13:45 .bash_history
-rw-r--r--. 1 developer developer 18 4月 30 2024 .bash_logout
-rw-r--r--. 1 developer developer 141 4月 30 2024 .bash_profile
-rw-r--r--. 1 developer developer 492 4月 30 2024 .bashrc
drwx------. 2 developer developer 29 3月 24 13:06 .ssh
左端の10文字に注目します。この10文字は、ファイルの種別とパーミッション(アクセス権限)を表しています。

たとえば -rw-r--r-- は次のように分解できます。
- rw- r-- r--
| | | |
| | | +-- その他(other): r-- = 読み取りのみ
| | +------ グループ(group): r-- = 読み取りのみ
| +---------- 所有者(user) : rw- = 読み書き
+------------ ファイル種別 : - = 通常ファイル
1文字目はファイルの種別を示します。
-: 通常ファイルd: ディレクトリl: シンボリックリンク
残りの9文字は3文字ずつ3組に分かれ、それぞれ「所有者(user)」「グループ(group)」「その他(other)」の権限を表します。各文字の意味は以下のとおりです。
r: 読み取り(read)w: 書き込み(write)x: 実行(execute)-: 権限なし
先ほどの出力で .bash_history は -rw------- です。所有者(developer)だけが読み書きでき、グループにもその他にも一切の権限がありません。コマンド履歴が他のユーザーに見えないようになっています。一方、.bashrc は -rw-r--r-- なので、所有者は読み書きでき、他のユーザーも読み取りだけは可能です。
所有者・グループ・その他
あるファイルにアクセスするとき、Linuxは次の順序で「どの権限を適用するか」を判定します。
- アクセスしたユーザーが、ファイルの所有者か? → 所有者の権限(1〜3文字目)を適用
- 所有者でなければ、ファイルのグループに所属しているか? → グループの権限(4〜6文字目)を適用
- どちらでもなければ → その他の権限(7〜9文字目)を適用
あなたは所有者か?
├── Yes → 所有者(user)の rwx を適用
└── No → あなたはグループメンバーか?
├── Yes → グループ(group)の rwx を適用
└── No → その他(other)の rwx を適用
※ 上から順に判定し、最初に一致した時点で確定。合算はされない。
この判定は上から順に行われ、最初に該当した区分の権限だけが適用されます。所有者がグループにも所属している場合でも、所有者の権限が優先され、グループの権限は使われません。
先ほどの出力を見ると、各行に developer developer と表示されています。左が所有者、右がグループです。前回学んだ id コマンドで確認したユーザーとグループの情報が、ここで活きてきます。
ディレクトリの rwx
ファイルの rwx は直感的に理解しやすいですが、ディレクトリに対する rwx は意味が異なります。初学者がつまずきやすいポイントなので、整理しておきます。
| 権限 | ファイル | ディレクトリ |
|---|---|---|
| r(読み取り) | ファイルの内容を読める | ディレクトリ内のファイル一覧を取得できる(ls) |
| w(書き込み) | ファイルの内容を変更できる | ディレクトリ内にファイルを作成・削除できる |
| x(実行) | プログラムとして実行できる | ディレクトリに cd で移動できる |
ディレクトリの x 権限は「実行」ではなく「移動できる」という意味になります。ホームディレクトリ /home/developer/ のパーミッションが drwx------ であるのは、所有者の developer だけが中に入れる(cd できる)ようにするためです。他のユーザーはこのディレクトリに cd することも、中のファイル一覧を見ることもできません。前回の予告で述べた「trainee01 が developer のファイルにアクセスできない」理由がこれです。
chmod — パーミッションを変更する
chmod(change mode)は、ファイルやディレクトリのパーミッションを変更するコマンドです。表記方法は2種類あります。まずシンボリック表記から学び、その後にオクタル表記を紹介します。
シンボリック表記(u+x, g-w 等)
シンボリック表記は「誰に」「何を」「どうする」を英字で指定する方法です。
対象(誰に):
u: 所有者(user)g: グループ(group)o: その他(other)a: 全員(all = u + g + o)
操作(どうする):
+: 権限を追加-: 権限を削除=: 権限を指定した内容に設定(既存の権限はリセットされる)
権限(何を):
r: 読み取りw: 書き込みx: 実行
組み合わせの例を見てみます。
| コマンド | 意味 |
|---|---|
chmod u+x script.sh | 所有者に実行権限を追加 |
chmod go-w file.txt | グループとその他から書き込み権限を削除 |
chmod a+r readme.txt | 全員に読み取り権限を追加 |
chmod u=rwx,go=rx dir | 所有者にrwx、グループとその他にrxを設定 |
シンボリック表記の利点は「何を変えたいか」が英語として読めることです。u+x は「user に execute を追加する」とそのまま読めます。
オクタル表記(755, 644 等)
現場ではシンボリック表記よりもオクタル(8進数)表記のほうがよく使われます。「chmod 755」「chmod 644」のように数字3桁で指定する方法です。短く書けるうえに、一度に全権限を指定できるため、設定ファイルや手順書では数字で書かれることがほとんどです。
各権限には次の数字が割り当てられています。
r(読み取り)= 4w(書き込み)= 2x(実行)= 1
これらの合計で1桁の数字を作り、所有者・グループ・その他の3桁で表現します。計算で覚えるよりも、パターンとして覚えるのが実用的です。
| 数字 | 権限 | シンボリック |
|---|---|---|
| 7 | 読み書き実行 | rwx |
| 6 | 読み書き | rw- |
| 5 | 読み取り実行 | r-x |
| 4 | 読み取りのみ | r– |
| 0 | 権限なし | — |
現場でよく見るパーミッションの組み合わせを整理します。
| オクタル | シンボリック | 用途の例 |
|---|---|---|
| 644 | rw-r–r– | 設定ファイル(/etc/hostname 等) |
| 755 | rwxr-xr-x | 実行ファイル、ディレクトリ |
| 600 | rw——- | 秘密鍵、.bash_history |
| 700 | rwx—— | .ssh ディレクトリ、ホームディレクトリ |
先ほど ls -la で見た .bashrc のパーミッション -rw-r--r-- は 644、.ssh ディレクトリの drwx------ は 700 です。
stat コマンドを使うと、オクタル表記とシンボリック表記の両方を一度に確認できます。
実行コマンド:
$ stat /etc/hostname
実行結果:
File: /etc/hostname
Size: 10 Blocks: 8 IO Block: 4096 通常ファイル
Device: fd00h/64768d Inode: 101494470 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Context: system_u:object_r:hostname_etc_t:s0
Access: 2026-03-28 16:01:08.989105903 +0900
Modify: 2026-03-24 12:32:28.910340561 +0900
Change: 2026-03-24 12:32:28.910340561 +0900
Birth: 2026-03-24 12:32:28.910340561 +0900
Access: (0644/-rw-r--r--) の部分で、オクタル表記(0644)とシンボリック表記(-rw-r–r–)の両方が表示されています。先頭の 0 は特殊パーミッション(後述)が設定されていないことを示します。Context: の行は SELinux のラベルです。第28回で扱うため、今は読み飛ばして構いません。
-R オプション(再帰的な変更)
chmod -R は、ディレクトリとその中のファイル・サブディレクトリに対して再帰的にパーミッションを変更します。
$ chmod -R 755 /path/to/directory
便利なオプションですが、注意が必要です。ディレクトリには x 権限が必要ですが、通常のファイルには x 権限を付けないのが原則です。chmod -R 755 を使うと、すべてのファイルにも実行権限が付与されてしまいます。本当に再帰的な変更が必要な場面かどうか、実行前に考える習慣を持ってください。
chown — 所有者とグループを変更する
chown(change owner)は、ファイルやディレクトリの所有者とグループを変更するコマンドです。基本の書式は以下のとおりです。
$ sudo chown ユーザー:グループ ファイル名
所有者だけを変更する場合はグループを省略できます。グループだけを変更する場合は :グループ名 のようにコロンの前を空にします。
| コマンド | 意味 |
|---|---|
sudo chown developer:developer file.txt | 所有者とグループを developer に変更 |
sudo chown root file.txt | 所有者を root に変更(グループは変わらない) |
sudo chown :wheel file.txt | グループを wheel に変更(所有者は変わらない) |
sudo chown -R developer:developer /path/to/dir | ディレクトリ以下を再帰的に変更 |
chown には sudo が必要です。一般ユーザーが自分のファイルの所有者を別のユーザーに変更できたら、他人になりすましてファイルを操作する抜け道になってしまいます。所有権の変更はセキュリティに直結するため、root 権限が求められます。
umask — デフォルトパーミッションの仕組み
touch でファイルを作成すると、パーミッションは毎回 644 になります。mkdir でディレクトリを作ると 755 になります。これは偶然ではなく、umask(ユーマスク)という仕組みが働いています。
実行コマンド:
$ umask
実行結果:
0022
umask は「新規ファイル作成時に、ここで指定した権限を除外する」マスク値です。仕組みは以下のとおりです。
- ファイルの基本パーミッション: 666(rw-rw-rw-) から umask 022 を引く → 644(rw-r–r–)
- ディレクトリの基本パーミッション: 777(rwxrwxrwx) から umask 022 を引く → 755(rwxr-xr-x)
実際にファイルを作って確認します。
実行コマンド:
$ touch /tmp/perm-test.txt
実行コマンド:
$ ls -la /tmp/perm-test.txt
実行結果:
-rw-r--r--. 1 developer developer 0 3月 29 18:52 /tmp/perm-test.txt
umask 0022 のとおり、644(rw-r–r–)でファイルが作成されました。ファイルの基本パーミッションが 666 で 777 ではない理由は、通常ファイルに実行権限が不要だからです。必要な場合だけ chmod u+x で付与します。
umask はシステムのデフォルト値(0022)のまま運用するのが一般的です。変更が必要になる場面は限定的なので、「こういう仕組みでデフォルトパーミッションが決まっている」と理解しておけば十分です。
SUID・SGID・Sticky Bit(概念紹介)
rwx の基本パーミッションに加えて、Linux には3つの特殊なパーミッションがあります。ここでは「こういう仕組みがある」という概念の理解にとどめます。設定方法は今は覚える必要はありません。
SUID(Set User ID)– passwd コマンドの謎
前回、/etc/shadow のパーミッションが 000(----------)であることを確認しました。所有者の root でさえ読み書きの権限が表示されていません。しかし実際には root はこのファイルを読み書きできます。root は CAP_DAC_OVERRIDE というカーネルのケーパビリティ(特権)を持っており、通常のパーミッション(DAC)を無視してアクセスできるためです。
では、一般ユーザーが passwd コマンドでパスワードを変更するとき、/etc/shadow はどうやって更新されるのでしょうか。passwd コマンドの権限を確認します。
実行コマンド:
$ ls -la /usr/bin/passwd
実行結果:
-rwsr-xr-x. 1 root root 32656 4月 14 2022 /usr/bin/passwd
所有者の実行権限が x ではなく s になっています。これが SUID です。SUID が設定されたファイルは、実行時に「実行したユーザー」ではなく「ファイルの所有者」の権限で動作します。/usr/bin/passwd の所有者は root なので、一般ユーザーが passwd を実行しても root の権限で動作し、/etc/shadow を更新できるのです。オクタルでは 4755 と表記されます(先頭の 4 が SUID を意味します)。
SGID(Set Group ID)
SUID と似た仕組みで、SGID はグループの権限に対して同じことを行います。
実行コマンド:
$ ls -la /usr/bin/write
実行結果:
-rwxr-sr-x. 1 root tty 23984 3月 13 2025 /usr/bin/write
グループの実行権限が s になっています。write コマンドは実行時に tty グループの権限で動作します。
Sticky Bit — /tmp ディレクトリの仕組み
/tmp ディレクトリのパーミッションを確認します。
実行コマンド:
$ ls -ld /tmp
実行結果:
drwxrwxrwt. 10 root root 4096 3月 29 19:03 /tmp
末尾が x ではなく t になっています。これが Sticky Bit です。/tmp は全ユーザーがファイルを作成できるディレクトリですが、Sticky Bit が設定されていることで「自分が作成したファイルしか削除できない」という制限がかかります。オクタルでは 1777 と表記されます(先頭の 1 が Sticky Bit を意味します)。
第6回で /tmp は一時ファイル置き場であると学びました。全員が使える場所だからこそ、他人のファイルを勝手に消せないようにする仕組みが必要です。
SUID/SGID/Sticky Bit の設定には chmod u+s、chmod g+s、chmod +t といったコマンドを使いますが、現時点では「こういう特殊なパーミッションが存在する」ことを知っておけば十分です。
やってみよう — パーミッションを操作する
ここまで学んだ内容を、一連の操作として実践します。ファイルの作成からパーミッションの変更、確認、所有者の変更まで通して行います。
ステップ1: 演習用ディレクトリとファイルを作成する
実行コマンド:
$ mkdir ~/perm-exercise && cd ~/perm-exercise
実行コマンド:
$ touch myfile.txt
実行コマンド:
$ echo '#!/bin/bash' > myscript.sh && echo 'echo Hello' >> myscript.sh
ステップ2: 現在のパーミッションを確認する
実行コマンド:
$ ls -l
umask 0022 の環境なので、両方とも 644(rw-r–r–)で作成されているはずです。
ステップ3: シンボリック表記でパーミッションを変更する
myscript.sh に実行権限を付与します。
実行コマンド:
$ chmod u+x myscript.sh
実行コマンド:
$ ls -l myscript.sh
所有者に x が追加されて -rwxr--r-- になっていることを確認します。実行してみます。
実行コマンド:
$ ./myscript.sh
「Hello」と表示されれば成功です。次に、myfile.txt からグループとその他の読み取り権限を削除します。
実行コマンド:
$ chmod go-r myfile.txt
実行コマンド:
$ ls -l myfile.txt
-rw------- になり、所有者だけが読み書きできる状態になったことを確認します。
ステップ4: オクタル表記でパーミッションを変更する
実行コマンド:
$ chmod 644 myfile.txt
実行コマンド:
$ chmod 755 myscript.sh
実行コマンド:
$ ls -l
myfile.txt が -rw-r--r--(644)、myscript.sh が -rwxr-xr-x(755)になっていることを確認します。
ステップ5: chown で所有者を変更する
実行コマンド:
$ sudo chown root:root myfile.txt
実行コマンド:
$ ls -l myfile.txt
所有者とグループが root に変わっていることを確認します。パーミッションは 644 のままなので、developer は「その他」の権限(読み取りのみ)で myfile.txt にアクセスすることになります。
実行コマンド:
$ cat myfile.txt
読み取り権限があるため、内容を表示できます(ファイルは空です)。では書き込みはどうでしょうか。
実行コマンド:
$ echo "test" >> myfile.txt
「許可がありません」(Permission denied)と表示されます。developer は「その他」に分類されるため、書き込み権限がありません。パーミッションが正しく機能していることを体感できます。元に戻しておきます。
実行コマンド:
$ sudo chown developer:developer myfile.txt
ステップ6: stat でオクタル表記を確認する
実行コマンド:
$ stat myfile.txt
Access: (0644/-rw-r--r--) の行で、オクタル表記とシンボリック表記が同時に確認できます。
やらかし体験: 全権限を奪ってみる
実行コマンド:
$ chmod 000 myfile.txt
実行コマンド:
$ cat myfile.txt
「許可がありません」(Permission denied)と表示されます。所有者である自分自身にも読み取り権限がないため、ファイルの中身を見られません。復旧します。
実行コマンド:
$ chmod 644 myfile.txt
所有者であれば、パーミッションを変更する権限は残っています。復旧できることを確認してください。
クリーンアップ
演習で使ったファイルと umask の確認で作ったファイルを削除します。
実行コマンド:
$ rm -rf ~/perm-exercise
実行コマンド:
$ rm /tmp/perm-test.txt
現場のヒヤリハット — chmod 777 で「解決」した話
ある新人エンジニアが、Webサーバーのファイルにアクセスできないトラブルに遭遇しました。原因を調べずに chmod 777 を実行して「動いた」と安心していたところ、後日セキュリティ監査で発覚しました。chmod 777 は全ユーザーに読み書き実行の全権限を許可するパーミッションです。外部からファイルを書き換えられる状態になっていたため、セキュリティインシデントとして報告されました。
「アクセスできない」と思ったときに取るべき手順は以下のとおりです。
ls -lで現在のパーミッションを確認する- 誰がアクセスする必要があるかを考える
- 必要最小限の権限だけを付与する
「とりあえず 777」は第3回で学んだ最小権限の原則に反する行為です。本番サーバーでは絶対にやってはいけません。
自走のヒント
シンボリック表記の全パターンや細かいオプションは man chmod で確認できます。すべてを暗記する必要はありません。ls -l と stat で現状を確認し、man chmod で構文を調べれば、必要なパーミッション変更は行えます。
余裕があれば、以下のファイルのパーミッションとその理由を考えてみてください。
/etc/passwd(644)– なぜ全ユーザーが読めるのか/etc/shadow(000)– なぜこれほど厳しいのか/usr/bin/passwd(4755)– 先頭の 4 は何を意味するか/tmp(1777)– 先頭の 1 は何を意味するか
理解度チェック
以下の文が正しければ○、間違っていれば×と答えてください。
- パーミッション
-rwxr-xr--は、所有者が読み書き実行でき、グループは読み取りと実行、その他は読み取りのみである - ディレクトリの x 権限は、そのディレクトリ内のファイルを実行する権限である
- chmod 755 は rwxr-xr-x と同じ意味である
- オクタル表記で r=4, w=2, x=1 である
- chown は一般ユーザーでも自由にファイルの所有者を変更できる
- /usr/bin/passwd に設定されている SUID により、一般ユーザーでもパスワードを変更できる
- umask 0022 の環境で touch コマンドで作成したファイルのパーミッションは 755 になる
- /tmp ディレクトリの Sticky Bit により、他のユーザーが作成したファイルを誰でも削除できる
解答
- ○ ―― rwx=所有者は読み書き実行、r-x=グループは読み取りと実行、r–=その他は読み取りのみ
- × ―― ディレクトリの x 権限は「cd でそのディレクトリに移動できる」権限。ファイルの実行とは異なる
- ○ ―― 7=rwx、5=r-x、5=r-x なので rwxr-xr-x と一致する
- ○ ―― r=4, w=2, x=1 の合計でパーミッションを表す
- × ―― chown にはsudo(root権限)が必要。一般ユーザーは自由に所有者を変更できない
- ○ ―― SUID により passwd コマンドは root の権限で実行され、/etc/shadow を更新できる
- × ―― ファイルのデフォルトパーミッションは 666 – 022 = 644。755 はディレクトリの場合
- × ―― Sticky Bit は「所有者しか削除できない」制限。他のユーザーのファイルは削除できない
まとめ
今回はLinuxのパーミッションと所有権の仕組みを学びました。
- パーミッションは10文字で表され、ファイル種別(1文字) + 所有者(3文字) + グループ(3文字) + その他(3文字) の構成
- r=読み取り、w=書き込み、x=実行。ディレクトリの x は「cd で移動できる」意味になる
- chmod はシンボリック表記(u+x, go-w 等)とオクタル表記(755, 644 等)の2通りで指定できる
- chown で所有者とグループを変更できる(sudo が必要)
- umask はデフォルトパーミッションを決めるマスク値。0022 ならファイルは 644、ディレクトリは 755
- SUID は実行時にファイル所有者の権限で動作する仕組み(例: /usr/bin/passwd)
- Sticky Bit はディレクトリ内で他人のファイルを削除できなくする仕組み(例: /tmp)
- 「とりあえず chmod 777」は最小権限の原則に反する。本番サーバーでは絶対に使わない
次回の第12回「プロセス管理」では、「動いているプログラム(プロセス)」を管理する方法を学びます。プロセスにも所有者がいます。今回学んだユーザーの概念がプロセス管理でも活きてきます。サービスが動かない原因がパーミッション不足だった、というトラブルシューティングにもつながる内容です。
シリーズ一覧
フェーズ1: エンジニアのいろは(第1回〜第3回)
フェーズ2: Linux基礎(第4回〜第15回)
- 第4回 Linuxとは何か+環境確認
- 第5回 SSH接続とターミナル操作
- 第6回 ファイルシステムとディレクトリ構造
- 第7回 基本コマンド(ファイル操作)
- 第8回 基本コマンド(テキスト処理・パイプとリダイレクト)
- 第9回 viエディタ
- 第10回 ユーザーとグループ管理
- 第11回 パーミッションと所有権(この記事)
- 第12回 プロセス管理
- 第13回 systemd
- 第14回 シェルスクリプト入門
- 第15回 フェーズ2まとめ演習
フェーズ3: ネットワークとインフラ基盤(第16回〜第27回)
- 第16回 ネットワーク基礎
- 第17回 ネットワーク設定と疎通確認
- 第18回 企業ネットワークの仕組み
- 第19回 パッケージ管理
- 第20回 ファイアウォール(firewalld)
- 第21回 ボンディング/チーミング
- 第22回 VLAN
- 第23回 ログ管理
- 第24回 cron / systemd timer
- 第25回 ストレージ管理(LVM)
- 第26回 シェルスクリプト実践
- 第27回 SSH応用
フェーズ4: サーバー構築と運用(第28回〜第36回)
