1-3_パーミッション

1-3. パーミッション - 権限・所有者・sudo

所要時間: 25-50分（がっつりなら2セッション分） ゴール: rwx / 数値（755, 644）の両方の表記が読めて書ける。なぜ .ssh が 700 でないと動かないのか説明できる コミット内容: 今日の操作履歴を ~/log/linux_day03.log に保存

この章が終わるとできること

• ls -l の出力 -rwxr-xr-x を見て即「755」と読み替えできる
• chmod 755 / 644 / 700 / 600 の4つを 「何用の権限か」 付きで暗記している
• chown user:group file で所有者・グループを同時に変えられる
• ~/.ssh/ が 700、秘密鍵が 600 でないと弾かれる理由を説明できる
• sudo が「root になる」ではなく「1コマンドだけ権限を借りる」と理解している

Day 1-2 とのつながり

• Day 1 で見た ls -l の左端 -rwxr-xr-x の正体に、今日ついに踏み込む
• Day 2 で cp -p の「属性を保持する」と言った時の「属性」が、今日の主役（権限・所有者）
• 「Permission denied を見たら、まず ls -l」が Day 1→3 で繋がる典型ムーブ

これができると何が嬉しいか

• 本番デプロイで遭遇する権限エラーの 8 割が その場で原因特定できる
• chmod 777 をコピペして塞ぐ「最悪のセキュリティホール量産」から卒業できる
• Day 14 (SSH) で Permissions are too open を絶対に踏まない

---

大前提: なぜパーミッションを学ぶのか

LinuxはマルチユーザーOSとして設計されている。1台のサーバーに複数人がログインして、それぞれの作業領域を持ち、システム全体は壊さない、という前提で動く。これを実現する仕組みがパーミッション（権限） と ユーザー / グループ の概念。

バックエンドエンジニアが詰まる典型シーン：

• 本番にデプロイしたら nginx が Permission denied で起動しない → 設定ファイルの権限が間違ってる
• ssh user@server で Permissions are too open と弾かれて入れない → ~/.ssh/ の権限が緩すぎる
• アプリがログを書けない → ログディレクトリの所有者が違う
• pip install できない → システム領域は一般ユーザーに書き込み権限がない

これらは全部権限を理解していれば3分で解決する問題。逆に理解していないと、Stack Overflow で chmod 777 をコピペして「動いた！」で済ませてしまい、後でセキュリティホールを作る。今日でその病気を治す。

---

セッション①: パーミッションの仕組みと chmod（25-30分）

0. 録画スタート＆作業ディレクトリ

mkdir -p ~/log ~/learn/linux/day03
cd ~/learn/linux/day03
script ~/log/linux_day03.log

1. パーミッションの読み方（復習＋深掘り）

Day 1 で ls -l の左端に出た -rw-r--r-- のような文字列を眺めた。あれが パーミッション文字列（permission string） で、「誰が・何を・できるか」をたった10文字に凝縮したものだった。ここではその10文字を1文字ずつ意味を解剖し、「読めるようになる」状態を作る。

なぜ「読める」だけで重要かというと、本番で起きる多くの権限事故は 「ls -l の出力を読めば原因がその場で見える」もの。Permission denied を見た瞬間に ls -l で対象ファイルの権限を確認し、3秒で「あ、グループに w が無いから書けないのか」と判断できる人と、Stack Overflow を漁って chmod 777 をコピペする人の差はここで生まれる。

# サンプルファイルを作る
touch sample.txt
mkdir sample_dir
ls -l

出力例:

-rw-r--r--  1 takato  staff   0 May 16 10:00 sample.txt
drwxr-xr-x  2 takato  staff  64 May 16 10:00 sample_dir

パーミッション文字列の構造

左端10文字は、10個の独立したスロットとして読む。

位置	取りうる値	意味
1	- / d / l	ファイル種別（-=通常ファイル / d=ディレクトリ / l=シンボリックリンク）
2	r or -	所有者の読み権限
3	w or -	所有者の書き権限
4	x or -	所有者の実行権限
5	r or -	グループの読み権限
6	w or -	グループの書き権限
7	x or -	グループの実行権限
8	r or -	その他の読み権限
9	w or -	その他の書き権限
10	x or -	その他の実行権限

権限は3種類しかない:

• r (read): 読める
• w (write): 書ける / 削除できる
• x (execute): 実行できる

- は 「そのスロットが空（権限なし）」を示すマーカー であって、4つ目の権限ではない。信号機の「消えてるライト」と同じ発想。

位置2以降は r → w → x の3文字セットが3回繰り返す構造:

位置:  2 3 4 | 5 6 7 | 8 9 10
枠:    r w x | r w x | r w x
       所有者  グループ  その他

各セットは必ず3文字。「権限あり」ならその文字、「権限なし」なら - が入る。

例: -rw-r--r-- の場合

• 位置1 = - → 通常ファイル
• 位置2-4 = rw- → 所有者: 読み✓ 書き✓ 実行✗
• 位置5-7 = r-- → グループ: 読みのみ
• 位置8-10 = r-- → その他: 読みのみ

ディレクトリの x は「実行」じゃない

ざっくり言うと

ファイルの x は「実行できる」だが、ディレクトリの x は「中に入れる」。同じ文字なのに意味が違う。ここを知らないと「権限あるはずなのに cd できない」で詰まる。

まず普通のパターン

スクリプトファイルに x を付ける:

chmod +x script.sh
./script.sh         # 実行できる

これは直感どおり。問題はここから。

困るケース: ディレクトリで何が起きるか

r だけ付けて x を外したディレクトリ:

chmod 644 mydir/    # rw-r--r--
ls mydir/           # ← 名前は見える
cd mydir/           # ← エラー: Permission denied
cat mydir/file.txt  # ← エラー: Permission denied

「読めるはずなのに中に入れない」現象。なぜ？

ファイルとディレクトリで r/w/x の意味が違う

権限	ファイルの場合	ディレクトリの場合
r	中身を読める	中のファイル名一覧が見える（ls）
w	中身を書ける	中の ファイルを作る・消す ができる
x	実行できる	中に入れる（cd、中のファイルにアクセス）

x だけ、意味がガラッと変わる。

図で見る: 4つのパターン

ディレクトリ mydir/ の権限による違い

rwx (フル):    名前見える / 入れる / 中身読み書きOK
r-- (rだけ):   名前見える / 入れない / アクセス不可
--x (xだけ):   名前見えない / 入れる / 名前を直接知ってればアクセス可
r-x (一般的):  名前見える / 入れる / 中身読める

イメージ

• ファイルの x = 「プログラムとして動かせる」
• ディレクトリの x = 「門を通れる」

ディレクトリは「中に入る」という概念があるから、x がそれを意味する。

「x なしディレクトリ」の連鎖事故

ls mydir/        # ← OK（rがあるから）
  ↓
cat mydir/file   # ← NG（xが無いと中のファイルに到達できない）

「入れない部屋の中の本のタイトルは見えるが、開けない」状態。

ちょっと変わった使い方: --x だけのディレクトリ

chmod 111 secret/    # --x--x--x

「名前は見えないけど、知ってる人だけ直接アクセスできる」状態。パスワードで守る発想に近い。実務ではあまり使わないが、/home/ がこういう設定の場合あり。

一番覚えやすい説明

• ファイルの x = 動かせる
• ディレクトリの x = 入れる
• 同じ x でも、対象がファイルかディレクトリかで意味が反転する

2. chmod シンボル形式（人間に優しい）

chmod (change mode) は ファイル/ディレクトリのパーミッションを変更するコマンド。指定の仕方には2系統あって、まずは「シンボル形式」（u+x, go-w のような文字列指定）から覚えるのが直感的。「誰の」「どの権限を」「追加/削除/セット」を文字で書くので意図がそのまま英語に近い。

シンボル形式の使い所:

• 既存の権限はいじらず、ピンポイントで x だけ追加: chmod u+x script.sh（よくある「スクリプトに実行権限を付ける」）
• 誤って付けた他人への書き込み権限だけ剥がす: chmod go-w file
• 公開ファイルの読み権限を全員に与える: chmod a+r index.html

「全部書き直す」ではなく「差分だけ操作する」のがシンボル形式の強み。数値形式（後述）と使い分けると現場で困らない。

# 所有者に実行権限を追加
chmod u+x script.sh
 
# グループから書き込み権限を削除
chmod g-w shared.txt
 
# その他にすべて権限なし
chmod o= secret.txt
 
# 全員に読みだけ
chmod a=r readonly.txt
 
# 複数指定（カンマ区切り）
chmod u+x,g-w,o-r mixed.txt

chmod u+x vs chmod 755 どう使い分ける？

ざっくり言うと

• シンボル形式 (u+x) = 「差分だけいじる」（既存の権限はそのまま）
• 数値形式 (755) = 「権限を全部書き換える」（既存の権限は消える）

両者は思想が違うので、状況によって正解が変わる。

まず普通のパターン

スクリプトに実行権限を付けたい:

# シンボル形式
chmod u+x script.sh
 
# 数値形式
chmod 755 script.sh

どっちも動く。でも 既存の権限が違うと結果も違う。

状況① スクリプトに x だけ追加したい時

# 元の状態: -rw-r--r-- (644)
chmod u+x script.sh
# 結果: -rwxr--r-- (744)   ← user の x だけ追加された

u+x は「user に x を「足す」」だけ。他は触らない。

これを数値で書くと:

chmod 744 script.sh   # 元の権限を知っていれば書ける

→ 元の権限を覚えていないと数値が書けない。シンボル形式なら「足す」だけだから楽。

状況② 完全に新しい状態にしたい時

# 元の状態: -rwxrwxrwx (777) ← 危険状態
chmod 644 script.sh
# 結果: -rw-r--r-- (644)   ← 強制的にこの状態に

数値形式は 「強制リセット」。元が何であろうと、指定した値にする。これが必要な時もある。

シンボルで同じことをすると:

chmod u=rw,g=r,o=r script.sh

→ 書ける、けど数値の方が圧倒的に短い。

図で見る

シンボル形式 (u+x):
元: rw-r--r--
   ↓ user に x を足す
新: rwxr--r--    ← 既存の権限は維持

数値形式 (755):
元: rw-r--r--（何でもいい）
   ↓ 強制的に755にセット
新: rwxr-xr-x    ← 元と無関係に上書き

対比表

	シンボル形式	数値形式
書き方	chmod u+x file	chmod 755 file
思想	既存の権限に差分を足し引き	権限を全部上書き
強み	既存を維持しつつ修正できる	短い、結果が一意
弱み	やや長い	元の権限が消える
向く場面	「x だけ追加」「w だけ削除」	「この状態にしたい」が明確な時
手順書での出現	少ない	多い（755 644 600 の定型句）

イメージ

• シンボル形式 = 追記モード（赤ペンで足したり消したり）
• 数値形式 = 上書きモード（白紙にしてから書き直す）

一番覚えやすい説明

• 「既存を残しつつ部分修正」 → シンボル（u+x, go-w）
• 「権限を確定状態にする」 → 数値（755, 644, 600）
• 手順書で見るのは数値が多いから、結果的に数値の方が頻出

シンボル形式の実務ユースケース

• スクリプトに実行権限を付ける: chmod +x deploy.sh（u+x の省略形でも可）
• 誤って他人に書き込み権限を与えてしまった: chmod go-w file
• 誰でも読める設定にする（公開ファイル）: chmod a+r index.html

シンボル形式の落とし穴

• chmod +x だけだと user / group / others 全員に x が付く（umaskの影響を受ける）。所有者だけにしたいなら明示的に u+x
• = は破壊的: chmod u=rw file は「user に r と w だけ」セットなので、既存の x が消える。気付かず実行ファイルが起動しなくなる事故あり

3. chmod 数値形式（実務で頻出）

chmod 755 file のような 3桁の数字で権限を一気に指定する書き方。シンボル形式が「差分操作」なのに対し、数値形式は「今ある権限を全部書き換える絶対指定」。実務のドキュメントや手順書では数値表記が圧倒的に多いので、こちらに慣れる必要がある。

なぜ実務では数値が好まれるか:

• タイプ量が短い: chmod u=rwx,go=rx file より chmod 755 file の方が圧倒的に速い
• 手順書に書きやすい: 「.ssh は 700」「秘密鍵は 600」のように、数字パターンが定型化している
• 意図が一意に決まる: シンボルだと「既存の権限次第」で結果が変わるが、数値は常に同じ状態を作る

r=4, w=2, x=1 を足すと各桁の数字になる、というルールを腹落ちさせれば暗算で書けるようになる。「755 と 644 と 700 と 600」の4パターンを覚えるだけで実務の9割は片付く。

# 所有者: rwx, グループ: r-x, その他: r-x
chmod 755 script.sh
 
# 所有者: rw-, グループ: r--, その他: r--
chmod 644 config.txt
 
# 所有者だけが読み書き可能（秘密鍵など）
chmod 600 secret.key
 
# 所有者だけが全権限（ディレクトリ向け）
chmod 700 ~/.ssh
 
# 全権限解放（基本やってはいけない）
chmod 777 anything

rwx と数値（755/644/600）の対応

ざっくり言うと

rwx を 数字3桁 に変換するだけ。r=4, w=2, x=1 を足すルールが分かれば、暗算で chmod 755 を rwxr-xr-x に翻訳できる。

まず普通のパターン

シンボル形式で書くと:

chmod u=rwx,g=rx,o=rx script.sh

これと同じことを数値で書くと:

chmod 755 script.sh

圧倒的に短い。同じ意味なら短い方が現場で勝つ。

仕組み: r=4, w=2, x=1 を足す

r = 4
w = 2
x = 1

これを「所有者・グループ・その他」の3枠でそれぞれ足し算する。

rwx = 4+2+1 = 7
rw- = 4+2   = 6
r-x = 4+1   = 5
r-- = 4
--- = 0

図で見る: 755 を分解

755
│││
│││└─ その他: 5 → r-x
││└── グループ: 5 → r-x
│└─── 所有者: 7 → rwx
└──── （ファイル種別は別、ここでは権限のみ）

→ rwxr-xr-x

図で見る: 644 を分解

644
│││
│││└─ その他: 4 → r--
││└── グループ: 4 → r--
│└─── 所有者: 6 → rw-

→ rw-r--r--

対比表（実務で覚える4パターン）

数値	rwx 表記	用途
755	rwxr-xr-x	実行ファイル、ディレクトリ
644	rw-r--r--	設定ファイル、HTML、画像
700	rwx------	~/.ssh/ ディレクトリ
600	rw-------	秘密鍵、.env

全パターン早見表

数値	2進数	rwx	よく使う？
7	111	rwx	はい
6	110	rw-	はい
5	101	r-x	はい
4	100	r—	はい
3	011	-wx	ほぼ使わない
2	010	-w-	ほぼ使わない
1	001	—x	たまに
0	000	---	はい（権限なし）

イメージ

数値1桁 = r=4, w=2, x=1 の足し算結果 3桁 = 所有者 / グループ / その他

一番覚えやすい説明

• r=4、w=2、x=1 を足す
• 3桁並べる順番は 「所有者 → グループ → その他」
• 実務は 755 / 644 / 700 / 600 の4つを覚えればOK

実務で頻出する数値の組み合わせ

数値	意味	典型用途
755	所有者だけ書ける、全員読み実行	スクリプト、実行ファイル、公開ディレクトリ
644	所有者だけ書ける、全員読める	設定ファイル、HTML、画像
700	所有者以外アクセス不可（ディレクトリ）	~/.ssh/、個人作業ディレクトリ
600	所有者だけ読み書き、他は何もできない	秘密鍵、.env、認証情報
666	全員読み書き可能	ほぼ使わない（危険）
777	全員フル権限	使ってはいけない（後述）

「755 と 644 と 600 と 700 の4つを覚えるだけ」で実務の9割カバーできる。

chmod 777 は典型的なアンチパターン

「権限エラーが出る → とりあえず chmod 777」は最悪の解決法。

• 誰でも書き換えられる = 攻撃者にコード書き換えのフリーパス
• 共有サーバーでは即セキュリティ事故
• 本来の問題（所有者違い、Webサーバーユーザーで動いていない等）が隠蔽される

エラーが出たら、まず ls -l で現在の所有者・権限を確認 → 何が足りないか判断 → 最小限の権限変更を行う。777 を打つ前に深呼吸。

4. ディレクトリへの再帰適用

chmod -R は chmod をディレクトリ配下の全ファイル・全サブディレクトリにまとめて適用するモード。プロジェクト一式の権限をまるごと整えたい時に便利だが、「ファイルとディレクトリで本来必要な権限が違う」点に注意が必要。

実務で詰まりがちなパターン:

• デプロイ後、Webアプリ全体に chmod -R 755 → 設定ファイル（.env 等）まで実行権限が付き、エディタや一部ツールが警告を出す
• chmod -R 644 src/ → サブディレクトリにも 644 が適用され、x が消えて中に入れなくなる事故

正しいパターンは「ディレクトリは 755、ファイルは 644」と分けて適用すること。これには find -type d / -type f と組み合わせる定石（Day 2 で習った find の応用）を使う。

# サブディレクトリ含めて全部 755 に
chmod -R 755 myproject/
 
# ファイルだけ 644、ディレクトリだけ 755 に分けたい場合
find myproject -type f -exec chmod 644 {} \;
find myproject -type d -exec chmod 755 {} \;

chmod -R の落とし穴

chmod -R 755 dir/ でディレクトリの中身も全部 755 にすると、本来 644 でいいファイルにまで x が付く。実行可能ファイルとして扱われると、エディタや一部ツールが警告を出す。

正しい使い分け:

• ディレクトリ: 755（中に入れる必要があるから x が要る）
• ファイル: 644（読み書きだけ、実行は通常不要）

区別したい時は find -type f / -type d を使う（上のコード）。

---

セッション②: 所有者・グループ・sudo・.ssh（25-30分）

5. ユーザーとグループの実体

権限を語る前提として、Linux における「ユーザー」と「グループ」が何か を押さえる必要がある。ls -l で表示される「所有者」「グループ」の正体、自分が今どのアカウントとして動いているのか、所属グループは何か、を確認するコマンド群がここで使う whoami / groups / id / /etc/passwd / /etc/group。

実務で重要なのは:

• OS が区別しているのは「名前」ではなく「UID（ユーザーID）」: ls -l で名前が出るのは数値→名前の逆引きをしているだけ
• 1人のユーザーは複数のグループに所属できる: チーム共有領域を「グループ単位で許可」する設計の土台
• /etc/passwd と /etc/group がユーザー/グループ情報の一次情報: Web上の図解より、まずこのファイルを開いて構造を見る方が早い

sudo chown で所有者を変える時、ここで触れる UID / GID の感覚が無いと「なぜ root が必要なのか」「グループだけ変えるとはどういう状態か」が腹落ちしない。

# 自分が誰か
whoami
 
# 自分が所属するグループ一覧
groups
 
# UID と GID を見る
id
 
# システムに登録された全ユーザー
cat /etc/passwd
 
# システムに登録された全グループ
cat /etc/group

/etc/passwd の中身

1行 = 1ユーザー。コロン区切りで以下の情報:

takato:*:501:20:Takato:/Users/takato:/bin/zsh

フィールド	例	意味
1	takato	ユーザー名
2	* or x	パスワード（実際は /etc/shadow に暗号化保存）
3	501	UID（ユーザーID、数値）
4	20	プライマリGID（所属する主要グループ）
5	Takato	コメント（フルネームなど）
6	/Users/takato	ホームディレクトリ
7	/bin/zsh	ログインシェル

OSが区別しているのは「名前」ではなく「UID」。ファイル所有者の実体はUID（数値）。ls -l で名前が出るのは、/etc/passwd を見て数値→名前を逆引きしてくれているだけ。

グループとは「共有相手のセット」

1人のユーザーは複数のグループに所属できる。

• プライマリグループ: そのユーザーが新規ファイルを作った時、自動でつくグループ
• セカンダリグループ: 追加で所属しているグループ

実務での使い所:

• 開発チーム全員を developers グループに入れて、ソースコードに chmod 770 →「チームメンバーは全員読み書き可、外部はアクセス不可」を実現
• Webサーバーが動くユーザー（www-data / nginx）をログディレクトリのグループに入れて、複数プロセスが同じログを書ける構成にする

6. chown / chgrp - 所有者・グループの変更

chown (change owner) / chgrp (change group) は ファイルの「所有者」「グループ」を変更するコマンド。chmod が「所有者が誰かは変えず、権限の中身だけ書き換える」のに対し、chown は「そもそも誰が所有してるか」を書き換える、より根本的な操作。

実務での頻出シーン:

• デプロイ後、Webサーバーがファイルを読めるように所有権を整える: sudo chown -R deploy:www-data /var/www/myapp
• CI で root として作られた成果物を、開発ユーザー所有に戻す: sudo chown -R $USER:$USER ./build（$USER は現在ログイン中のユーザー名が自動で入る環境変数。例えば takato としてログインしていれば takato:takato に展開される。環境変数は Linux 2-2 で詳しく扱う）
• ログ収集ツール用のグループ追加: sudo chgrp -R logger /var/log/myapp

自分が所有していないファイルの所有者を変える操作は root 権限が必要（sudo 必須）。これは「他人のファイルを勝手に乗っ取れない」ためのセキュリティ設計。Day 1 で軽く触れた「ファイルは UID と紐づく」という話が、ここで実感を伴って理解できるはず。

# 所有者を変更（sudo が必要なことが多い）
sudo chown newuser file.txt
 
# グループだけ変更
sudo chgrp staff file.txt
 
# 所有者とグループを同時に
sudo chown newuser:staff file.txt
 
# ディレクトリ配下を再帰的に
sudo chown -R deploy:www-data /var/www/myapp

sudo chown -R deploy:www-data /var/www/myapp を分解する

上の最後のコマンドはWebアプリのデプロイで頻出する書き方。要素ごとに分解する。

sudo  chown  -R  deploy:www-data  /var/www/myapp
└┬─┘ └─┬──┘ └┬┘ └──────┬──────┘ └──────┬──────┘
特権  所有者 再帰  ユーザー:グループ   対象パス
実行  変更

要素	意味
sudo	root 権限で実行（chown は root にしかできない）
chown	change owner = 所有者変更コマンド
-R	recursive = 配下の全ファイル・全ディレクトリに再帰適用
deploy:www-data	ユーザー:グループ の形式。所有者を deploy、グループを www-data に変える
/var/www/myapp	対象ディレクトリ

意図: 「deploy ユーザーが書き込み、www-data グループ（=Webサーバー）が読み取り」という権限分離の確立。デプロイ担当はファイルを更新できる、Webサーバーは読むだけ、第三者は何もできない。最小権限の原則 の典型適用例で、セキュリティ章（Week 7 以降）で繰り返し出てくる発想。

chmod vs chown vs chgrp どう違う？

ざっくり言うと

3つとも「権限まわり」のコマンドだが、触る対象が違う。

• chmod = 権限の中身を変える
• chown = 所有者を変える
• chgrp = グループを変える

まず普通のパターン

ls -l の出力をもう一度見る:

-rw-r--r--  1 takato  staff  1234 May 14 16:00 memo.txt
└─┬──────┘    └─┬─┘   └─┬─┘
  ↑             ↑       ↑
chmod が触る  chown   chgrp
              が触る   が触る

つまり、ls -l の出力の どの列を書き換えたいか で3コマンドを使い分ける。

それぞれの守備範囲

chmod = 権限部分（rwx）

chmod 755 memo.txt

→ rw-r--r-- の部分が rwxr-xr-x になる。所有者は変わらない。

chown = 所有者

sudo chown deploy memo.txt

→ takato の部分が deploy になる。権限は変わらない。

chgrp = グループ

sudo chgrp www-data memo.txt

→ staff の部分が www-data になる。所有者も権限も変わらない。

図で見る: 3つの違い

変更前:  -rw-r--r--  takato  staff  memo.txt
            ↓ chmod 755
変更後:  -rwxr-xr-x  takato  staff  memo.txt
            ↑ ここだけ変わる

変更前:  -rw-r--r--  takato  staff  memo.txt
            ↓ chown deploy
変更後:  -rw-r--r--  deploy  staff  memo.txt
                       ↑ ここだけ変わる

変更前:  -rw-r--r--  takato  staff  memo.txt
            ↓ chgrp www-data
変更後:  -rw-r--r--  takato  www-data  memo.txt
                              ↑ ここだけ変わる

chown で全部まとめて変えられる裏ワザ

実は chown は : で区切ると、所有者とグループの両方を同時に変えられる:

sudo chown deploy:www-data memo.txt   # 両方変更
sudo chown :www-data memo.txt         # グループだけ（= chgrp と同じ）

なので「chown だけ覚えれば chgrp は要らない」とも言える。

対比表

コマンド	何を変える	sudo 必要？	書式
chmod	権限（rwx）	自分のファイルなら不要	chmod 755 file
chown	所有者	必要（他人のファイルは奪えない）	chown user file
chgrp	グループ	通常必要	chgrp group file
chown user:group	所有者＋グループ	必要	chown user:group file

なぜ chown だけ常に sudo が必要？

自分のファイルの所有権を他人に渡せると、「悪意のあるファイルを他人の名前で残す」攻撃ができてしまう。だから 所有権の変更は root だけ、というのが Unix の鉄則。

イメージ

chmod = 鍵の種類（rwx）を変える
chown = 家の名義人を変える
chgrp = 同居グループを変える

一番覚えやすい説明

• ls -l の出力で「どこを変えたいか」で選ぶ
• 権限 → chmod、所有者 → chown、グループ → chgrp
• 迷ったら chown user:group で2つ同時にいける

chown / chgrp の実務ユースケース

• デプロイ後の権限調整: chown -R www-data:www-data /var/www/myapp でWebサーバーがファイルを読み書きできるように
• CIで作られたファイルを開発者所有に戻す: sudo chown -R $USER:$USER ./build
• ログ収集ツールが書けるようにグループ追加: chgrp -R logger /var/log/myapp

chown -R の落とし穴

• シンボリックリンクの扱い: デフォルトはリンクの「実体」の所有者を変える。リンク自体だけ変えたい場合は -h
• / から実行すると地獄: sudo chown -R user / でシステム全体の所有権を書き換えると、起動できなくなる事故が起きる。再帰オプション付き chown は対象パスを声に出して確認してから

7. sudo - 一時的にrootとして実行

sudo (Substitute User Do) は 「指定したコマンドを別ユーザー（デフォルトは root）の権限で1回だけ実行する」仕組み。「root に変身する」ではなく「そのコマンドだけ root として動かす」のがポイント。実行のたびに自分のパスワード（root のではない）で認証する。

なぜ「root に直接ログインせず、毎回 sudo」なのか:

• 誤操作の被害を最小化: 普段は権限の低い一般ユーザーで作業し、必要な瞬間だけ root の力を借りる
• 監査ログが残る: 「ユーザーA が sudo で X を実行した」という記録が /var/log/auth.log などに残るので、後で誰が何をしたか追える
• 権限の細分化: /etc/sudoers で「特定コマンドだけ sudo を許可」のような細かい制御ができる

本番Linuxサーバーは多くの場合 root の SSH ログインを禁止しており、必ず一般ユーザーで入ってから sudo を使う運用。「sudo を打つ瞬間は、特権が動く一瞬」と意識するクセを付けると事故が減る。

# 単発のコマンドを root として実行
sudo apt update
 
# 何度も sudo するのが面倒なら（タイムアウトまで認証維持）
sudo -v
 
# 完全にroot状態のシェルを起動（非推奨）
sudo -i
 
# 別のユーザーで実行
sudo -u www-data ls /var/www

sudo (Substitute User Do) とは

「特定のコマンドだけ 別ユーザー（デフォルトはroot）の権限で実行する」仕組み。実行のたびに自分のパスワードを聞かれる（rootのパスワードではない）。

rootは「神」: ファイルシステム全部に対して read/write/execute、プロセス管理、ユーザー管理、何でもできる。だから危険。

設計思想: 普段は権限の低い一般ユーザーで作業 → 必要な時だけ sudo で局所的にroot権限を借りる → 操作ログが残る（後で監査できる）。

なぜroot直接ログインを禁止するのか

多くのLinuxサーバーは root での SSH ログインを禁止している。理由：

1. 誤操作の被害が甚大: rootは確認なしに何でもできる。rm -rf / を間違って打ったら終わり
2. 監査ログが取れない: 全員 root でログインすると「誰が何をしたか」分からない。sudo 経由なら「ユーザーAが sudo で X を実行した」のログが残る
3. 総当たり攻撃の的: root ユーザーは100%存在することが分かっている → パスワード突破を狙われる。一般ユーザー名は推測されにくい

sudoers とは

/etc/sudoers ファイルで「誰が」「どのコマンドを」sudo で実行できるかを定義する。直接編集せず必ず visudo コマンドで開く（文法エラーを防ぐため）。

例: 開発者は systemctl restart nginx だけ sudo 可能、削除コマンドは禁止、のような細かい権限制御ができる。

# sudoers 抜粋例
%developers ALL=(ALL) /bin/systemctl restart nginx, /bin/systemctl status nginx

多くの環境では %admin や %wheel グループに所属するユーザーが「sudo で何でもできる」設定になっている。

sudo まわりの落とし穴

• sudo を打ち忘れて怒られる: apt install xxx → Permission denied → sudo !! （直前のコマンドにsudo付けて再実行）の小技を覚えておく
• 環境変数が引き継がれない: sudo 経由だと $HOME や $PATH が root のものになる。スクリプトで sudo 使うときは -E で環境を保持
• sudo rm -rf は地獄の門: 一般ユーザーなら自分の領域しか壊せないが、sudo を付けるとシステム全体を破壊できる。実行前に対象パスを必ず確認

8. .ssh ディレクトリと厳格な権限要件

~/.ssh は SSH 鍵認証で使う秘密鍵・公開鍵・設定ファイルを置く場所。バックエンドエンジニアにとって本番サーバーへの接続経路そのもので、ここの権限がズレているだけで SSH が起動を拒否するほどシビアな扱いを受ける。

SSH の世界では「秘密鍵を持っている = 本人」とみなされる。だから秘密鍵が他人に読まれる可能性が少しでもあれば、認証システム全体が危険に晒される。OpenSSH はこのリスクを防ぐため、「他人が読める権限のままなら、その鍵は無効として扱う」 という厳格な方針を取る。

実務でハマる典型エラー:

Permissions 0644 for '/home/user/.ssh/id_ed25519' are too open.
It is required that your private key files are NOT accessible by others.

これを見たら反射で chmod 600 ~/.ssh/id_ed25519 を打てるようになるのが目標。SSH 接続で詰まったらまず ls -la ~/.ssh で権限確認、というクセを身体に染み込ませる。

# .ssh が無ければ作る
mkdir -p ~/.ssh
 
# 厳密な権限設定（これが「正しい」状態）
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519        # 秘密鍵
chmod 644 ~/.ssh/id_ed25519.pub    # 公開鍵
chmod 600 ~/.ssh/authorized_keys   # ログイン許可キー
chmod 600 ~/.ssh/config            # SSH設定
 
ls -la ~/.ssh

なぜ .ssh は権限がうるさいのか

SSH は「秘密鍵を持っている人 = 本人」として扱う認証方式。秘密鍵が漏れたら、サーバーに自由にログインされてしまう。

そのため OpenSSH は 「他人が秘密鍵を読める可能性がある状態」を許さない。具体的には:

• ~/.ssh/ ディレクトリ: 700（所有者以外アクセス不可）。これより緩いと中に入れない
• 秘密鍵（id_* の .pub でない方）: 600（所有者だけ読み書き）。グループ・othersに少しでも r があると SSH が起動時に拒否
• 公開鍵（*.pub）: 644（みんな読んでOK）。公開鍵は「公開」していいデータ
• authorized_keys: 600。これが緩いと、第三者が勝手にキーを追記してログインルートを作る攻撃が成立する

エラーメッセージ例:

Permissions 0644 for '/home/user/.ssh/id_ed25519' are too open.
It is required that your private key files are NOT accessible by others.

直し方は chmod 600 ~/.ssh/id_ed25519。SSH接続でハマったら、まず ls -la ~/.ssh で権限確認するクセを。

.ssh でやらかしがちなこと

• 公開鍵をコピペする時に改行・余白が入る → authorized_keys が壊れて入れない。cat ~/.ssh/id_ed25519.pub の出力を1行で渡す
• ~/ 自体の権限が緩い → chmod 700 ~/.ssh してもダメな場合がある。chmod 755 ~ が必要（macOSはこれが多い）
• ホームディレクトリの所有者が違う → root で操作したファイルが混ざると認証が壊れる。sudo chown -R $USER:$USER ~/.ssh で戻す

9. umask - デフォルト権限を決める仕掛け

umask は 「これから新しく作られるファイル/ディレクトリの初期権限」を決めるシェルの設定値。touch newfile.txt で作ったファイルが、なぜ毎回 -rw-r--r--（644）になるのか――それは umask が「そこから奪う権限」をあらかじめ決めているから。

実務で意識する場面:

• 共有サーバーでチーム作業中、新規ファイルがいきなり他人に読まれるのを防ぎたい: umask 077 で「自分以外完全シャットアウト」がデフォルトに
• 逆に「全員読める前提」のWebサーバーディレクトリでは緩めに設定: 一般的な umask 022 のままで OK
• chmod を毎回打つ手間を減らす: 「全部 600 にしたい」なら umask で初期値を変えれば、その後 chmod 不要

chmod が「個別ファイルの権限を変える」操作なのに対し、umask は「新規ファイルの権限のデフォルト値を仕込んでおく」設定。両者をセットで理解すると権限管理の全体像が見える。

# 現在のumask確認
umask
 
# 例: 022 と出る
# touch して権限確認
touch newfile.txt
ls -l newfile.txt    # -rw-r--r--（644）
 
# 一時的に変更
umask 077
touch private.txt
ls -l private.txt    # -rw-------（600）

umask の計算

新規ファイルやディレクトリを作った時のデフォルト権限は、ベース権限から umask を引いた値で決まる。

• ファイルのベース: 666（rw-rw-rw-）
• ディレクトリのベース: 777（rwxrwxrwx）

umask 022 の場合:

• ファイル: 666 - 022 = 644（rw-r—r—）
• ディレクトリ: 777 - 022 = 755（rwxr-xr-x）

umask 077 の場合:

• ファイル: 666 - 077 = 600（rw-------）
• ディレクトリ: 777 - 077 = 700（rwx------）

意味: umask は「奪う権限」を指定する。022 なら「グループとothersから書き込み権限を奪う」。

umask の実務的意味

• 多くのLinuxのデフォルト: 022（=作ったファイルは644、ディレクトリは755）。共有サーバー前提のバランス
• セキュリティ重視のサーバー: 077（自分以外アクセス不可がデフォルト）に設定する場合あり
• .zshrc / .bashrc に umask 022 を書いて固定するのが推奨。シェルごとに違うとファイル管理が混乱する

umask の落とし穴

• 既存ファイルには影響しない: umaskは「新規作成時の初期値」だけ決める。すでにあるファイルの権限は変わらない
• 「引き算」と表現したが厳密には & ~umask（ビットマスク）: 数値が小さい権限同士だと直感と合わない場合がある。ただし日常では 022 / 077 の2択でほぼ事足りる

10. 実践課題

# 1. 練習ディレクトリ
mkdir -p ~/learn/linux/day03/practice
cd ~/learn/linux/day03/practice
 
# 2. 「秘密鍵もどき」ファイルを作って、適切な権限に
touch secret.key
chmod 600 secret.key
ls -l secret.key    # -rw------- になっているか
 
# 3. シェルスクリプトを実行可能にする
# ↓ cat > file <<'EOF' ... EOF は「ヒアドキュメント」と呼ばれる構文。Linux 1-5 で扱う。
#   1行目の #!/bin/bash は「shebang」と呼ばれ、「このファイルを bash で実行してね」と
#   OS に教える宣言行（詳細は Linux 2-2 で扱う）。今は「シェルスクリプトの先頭に書くおまじない」程度のイメージでOK。
#   ここではコピペで OK、目的は chmod u+x で実行権限を付けて ./hello.sh が動くこと。
cat > hello.sh <<'EOF'
#!/bin/bash
echo "Hello from script"
EOF
chmod u+x hello.sh
./hello.sh   # 実行できればOK
 
# 4. ディレクトリだけ 755、ファイルだけ 644 にする練習
mkdir -p webapp/{html,css,js}
touch webapp/index.html webapp/style.css webapp/app.js
chmod -R 777 webapp/    # わざと「全権限」にしてから
find webapp -type d -exec chmod 755 {} \;
find webapp -type f -exec chmod 644 {} \;
ls -lR webapp           # ディレクトリ755、ファイル644になっているか確認
 
# 5. .ssh の権限チェック（既存ならそのまま、なければ作って整える）
#    ↓ `2>/dev/null` は「エラーメッセージを画面に出さず捨てる」リダイレクト（詳細は Linux 1-5）。
#      `||` は「左のコマンドが失敗したら右を実行」というシェルの制御演算子（詳細は Linux 2-3）。
#      この行は「.ssh があれば一覧表示、無ければ作る」をワンライナーで書いただけ。
ls -la ~/.ssh 2>/dev/null || mkdir -p ~/.ssh
chmod 700 ~/.ssh
ls -ld ~/.ssh    # drwx------ になっていれば成功

---

締め: 振り返り（10分）

1. セッション録画を終了

exit

2. 今日の発見

このノートに追記:

- chmod の数値とシンボル、どっちが直感的に感じた:
  慣れたら数値が直感的に使えると思う
- .ssh の権限要件、納得できた・できなかった点:
  .sshは難しいが、基本的に700のように自分意外では
　　読み取り、書き込み、実行できない方がベスト
- 「これ事故るな」と思った操作:
  　下手に777をやるとセキュリティ的にかなり危ない
- 明日やりたいこと:
  特になし

---

チェックリスト

• ls -l の出力からファイル種別・所有者・権限が読める
• chmod 755 と chmod 644 を意味付きで使い分けられる
• chmod u+x script.sh と chmod 755 script.sh が同じ結果になることを確認した
• chown user:group file で所有者とグループ両方変えた
• ~/.ssh が 700、秘密鍵が 600 になっていることを確認した
• umask の値を 022 と 077 で切り替えて挙動を観察した
• sudo を「単発昇格」として理解できた（rootに「なる」のではない）

---

詰まった時のチートシート

やりたいこと	コマンド
権限を確認	ls -l <ファイル>
実行権限を所有者に追加	chmod u+x <ファイル>
スクリプトを実行可能に	chmod 755 <スクリプト>
設定ファイルの標準権限	chmod 644 <ファイル>
秘密鍵の権限	chmod 600 <ファイル>
.ssh ディレクトリの権限	chmod 700 ~/.ssh
所有者を変更	sudo chown <user> <ファイル>
所有者とグループ変更	sudo chown <user>:<group> <ファイル>
再帰的に変更	chmod -R / chown -R
ディレクトリだけ755に	find <path> -type d -exec chmod 755 {} \;
自分のグループ確認	groups
自分のUID/GID確認	id
デフォルト権限確認	umask
直前コマンドをsudoで再実行	sudo !!

---

「実務OK」基準

• 755 / 644 / 700 / 600 の4つを暗記し、何のためか説明できる
• chmod 777 を「最終手段」と認識し、安易に使わない
• Permission denied を見たら、まず ls -l で権限・所有者を確認するクセがある
• .ssh で Permissions are too open エラーを見たら、即 chmod 600 で直せる
• sudo を「root に変身する」ではなく「単発で権限を借りる」と理解している

ここまで来れば「権限まわりで詰まらない人」。明日 Day4 で テキスト処理（grep / awk / sed / sort / uniq） に進む。

---

アンチパターン / 初心者やらかし事例

NG 1: 困ったら chmod 777

# アプリがファイル読めない → 苦し紛れに
chmod -R 777 /var/www/myapp

→ 全世界に 書き込み権限を開放 している。ハッキング後、攻撃者が任意ファイルを置ける。対策: 所有者を正しく変える chown -R appuser:www-data /var/www/myapp のほうが本筋。

NG 2: chmod -R 644 ~/.ssh

# 「全部644にしとけば安全だろ」
chmod -R 644 ~/.ssh

→ ディレクトリには x（中に入る権限）が必要。~/.ssh は 700、ファイルは 600。ディレクトリとファイルで必要権限が違う ことを忘れがち。

→ 対策: find ~/.ssh -type d -exec chmod 700 {} \; と find ~/.ssh -type f -exec chmod 600 {} \; を分ける。

NG 3: sudo をパスワード保存代わりに使う

# .bash_history に sudo のパスワード平文で残してる人
echo "mypass" | sudo -S apt update

→ ヒストリ・スクリプトに平文パスワードを残す悪手。対策: NOPASSWD を sudoers で限定的に設定、または専用デプロイユーザーを作る（Day 3-2 / 3-6 で扱う）。

NG 4: 秘密鍵に 644 を付けて Git に上げそうになる

chmod 644 id_rsa   # 「読みやすくしとこ」

→ SSH クライアントは秘密鍵の 権限が緩いとエラーで停止する（Permissions are too open）。これは事故防止の仕様。秘密鍵は常に 600、絶対に git add しない。

---

次のレッスン: Day 4 - テキストツール

明日は grep / awk / sed / sort / uniq / wc ─ 「ログを読む人」のための武器一式。

今日まで「ファイル全体を見る cat / less」しか持っていなかったが、Day 4 では「ログから ERROR 行だけ取り出す」「IPアドレス別にカウントする」みたいな「ピンポイントで情報を抜く」技を覚える。

→ Day 4: テキストツール へ