Linuxパーミッションとユーザー管理の完全理解 ― VPSの事故の9割を防ぐ権限設計

「Permission deniedと言われて先に進めない」「chmod 777にしたら動いたのでそのままにしている」── VPSを触り始めた人が必ず通る道だ．だがこの権限まわりの曖昧な理解こそ，サーバー事故の最大の温床である．

Linuxのパーミッションは，仕組みさえ掴めば極めて論理的でシンプルだ．逆に，分からないまま777を連発すると，誰でも書き換えられるファイルを世界に晒すという重大な穴を自分の手で開けることになる．

この記事は，VPSでアプリやWebサイトを公開する個人開発者，権限エラーに毎回つまずくエンジニアに向けて書いている．rwxの読み方からWebアプリの実践的な権限設計まで，「なぜそうするのか」を含めて一気に理解できる状態を目指す．

読み終えたとき，あなたはls -lの出力を一瞬で読み解き，chmod 777に頼らず適切な最小権限を自分で設計できるようになっている．これはセキュリティの土台であり，一度身につければ一生効く知識だ．

なぜ権限の理解がセキュリティの土台なのか

公開サーバー上のファイルは，「誰が・何を・できるか」が権限によって決まる．この設計を誤ると，本来読めないはずの設定ファイルが読まれ，書き換えられないはずのコードが改ざんされる．

とくに危険なのが安易なchmod 777だ．これは「世界中の誰でも，読み・書き・実行できる」という意味になる．Webサーバー経由で侵入された場合，777のファイルやディレクトリは格好の足がかりになる．

また権限はアプリの安定動作にも直結する．「ログファイルに書き込めずアプリが落ちる」「アップロード先に権限がなくエラー」といったトラブルの大半は，権限設計で解決できる．

つまり権限の理解は，セキュリティと安定性の両方を支える基礎体力だ．ここを固めれば，VPS運用の不安の多くが消える．

権限モデルの全体像 ― 「誰に」「何を」の二軸で考える

Linuxの権限は，「誰に対して(対象)」×「何を許すか(操作)」という単純な二軸でできている．まずこの構造を頭に入れれば，あとは細部を埋めるだけだ．

「誰に」は3種類．所有者(user)・所有グループ(group)・その他全員(others)だ．「何を」も3種類．読み(r)・書き(w)・実行(x)．3×3の組み合わせが，Linux権限のすべての出発点になる．

操作の意味は，ファイルとディレクトリで微妙に異なる点に注意したい．これを知らないと「ディレクトリに入れない」謎に悩まされる．

ファイルとディレクトリでrwxの意味が変わる

ファイルでは直感どおり，r=中身を読む，w=中身を書き換える，x=プログラムとして実行するだ．

ところがディレクトリでは意味が変わる．r=中のファイル一覧を見る，w=中にファイルを作成/削除する，x=その中に入る(cdする)・中のファイルにアクセスする．とくにxが無いとディレクトリに入れないのが盲点で，「中のファイルは読めるはずなのにアクセスできない」原因の多くはこれだ．

パーミッションの読み方 ― ls -l と数値の対応

ls -lの出力を読めれば，権限の8割は理解できたも同然だ．先頭の文字列が，まさに「誰に何を許すか」を表している．

ls -l の出力を読む

$ ls -l
-rw-r--r-- 1 deploy deploy  1240 Jun  9 10:00 config.yml
drwxr-xr-x 2 deploy deploy  4096 Jun  9 10:00 logs
#^__/__/__/
#| u   g   o
#先頭1文字: -=ファイル d=ディレクトリ

-rw-r--r--を分解すると，先頭-はファイル，続くrw-が所有者(読み書き)，r--がグループ(読みのみ)，r--がその他(読みのみ)を表す．つまり「所有者だけ編集でき，他は読むだけ」という，設定ファイルの典型的な権限だ．

数値(8進数)との対応を暗記する

権限は数値でも表現する．r=4，w=2，x=1を足し算するだけだ．rwx=7，rw-=6，r-x=5，r--=4．これを所有者・グループ・その他の順に3桁並べる．

頻出パターンは丸暗記してしまうのが速い．644(設定ファイル)，755(ディレクトリ・実行ファイル)，600(秘密ファイル)，700(専用ディレクトリ)．この4つを覚えれば日常はほぼ足りる．

chmod実践 ― 記号モードと数値モードを使い分ける

権限の変更はchmodで行う．数値モード(一括指定)と記号モード(差分指定)の2つの書き方があり，場面で使い分けると速い．

chmod の2つの書き方

# 数値モード: 権限を一括で設定
chmod 644 config.yml
chmod 600 .env
chmod 755 deploy.sh

# 記号モード: 既存権限に差分を加える
chmod +x deploy.sh        # 全員に実行権を追加
chmod u+w,go-w file       # 所有者に書込追加,他から書込削除
chmod -R 755 public/      # ディレクトリ配下を再帰的に

「特定の操作だけ足したい/削りたい」なら記号モード(+xなど)，「権限を確定的に決めたい」なら数値モード(644など)が向く．-Rでの再帰指定は強力だが，ファイルとディレクトリに同じ権限を当ててしまう危険があるので次の点に注意する．

ファイルとディレクトリを分けて再帰指定する

chmod -R 755 .のように一括指定すると，ファイルにまで実行権(x)が付いてしまう．本来ファイルは644，ディレクトリは755が正しい．findと組み合わせて分けて適用するのがプロの作法だ．

ファイルは644・ディレクトリは755に分けて適用

find /var/www/site -type d -exec chmod 755 {} ;
find /var/www/site -type f -exec chmod 644 {} ;

所有者とグループ ― chown / chgrp で「誰のものか」を変える

権限の「誰に」を決める所有者・グループ自体を変えるのがchownだ．アプリのファイルを実行ユーザーの所有にするのは，権限設計の出発点になる．

所有者とグループの変更

# 所有者をdeployユーザーに
sudo chown deploy /home/deploy/app/server.js
# 所有者:グループ を同時に
sudo chown deploy:deploy /home/deploy/app/server.js
# ディレクトリ配下を再帰的に
sudo chown -R deploy:www-data /var/www/site

chown deploy:www-dataのように所有者は操作する人，グループはWebサーバー(www-data等)に設定すると，「自分は編集でき，Webサーバーは読める」という実用的な構成が作れる．これはWebアプリの権限設計の定番パターンだ．

特殊権限 ― setuid・setgid・sticky bit

通常のrwxに加え，Linuxには3つの特殊権限がある．普段は意識しなくてよいが，知らないとls -lでsやtを見たときに混乱するし，権限事故の理解にも必要だ．

個人開発で実用上よく使うのはディレクトリへのsetgidだ．共有ディレクトリにsetgidを付けると，その中で作られるファイルが自動的に同じグループを継承するため，チームやWebサーバーとのファイル共有が破綻しにくくなる(chmod g+s ディレクトリ)．

ユーザーとグループの管理 ― 最小権限の作業環境を作る

VPS運用では，用途ごとにユーザーを分けるのが鉄則だ．rootで全部やる，1ユーザーで全アプリを動かす，は事故とセキュリティリスクの元になる．

ユーザー・グループの基本操作

# デプロイ用ユーザーを作成
sudo adduser deploy
# グループ作成と所属
sudo groupadd webadmin
sudo usermod -aG webadmin deploy   # -a を忘れると既存グループが消える
# 所属グループの確認
groups deploy
id deploy

最重要の注意点は，usermod -aGの-a(append)を絶対に忘れないことだ．-a無しのusermod -Gは，指定したグループ以外の所属をすべて消してしまう．これでsudoグループから外れて作業不能になる事故は定番中の定番だ．

sudoの設計 ― rootを配らず権限を貸す

sudoは「一時的にroot権限を借りる」仕組みだ．ポイントはrootのパスワードを共有せず，必要な人に必要な権限だけを与えられること．これが最小権限の原則を実現する．

日常作業用ユーザーをsudoグループ(Ubuntu/Debian)またはwheelグループ(RHEL系)に入れれば，そのユーザーは自分のパスワードでroot権限を行使できる．rootへの直接ログインは無効化し，操作は必ずsudo経由にするのが安全な構成だ．

特定コマンドだけ許可する(visudo)

「このユーザーには再起動だけ許したい」といった細かい権限委譲も可能だ．visudoで編集すれば，特定コマンドだけをパスワードなしで許可できる．自動化スクリプト用のユーザーに最小限の権限を与えるときに有効だ．

visudo で特定コマンドだけ許可

# sudo visudo で編集
# deployユーザーにアプリ再起動だけ許可(パスワード不要)
deploy ALL=(ALL) NOPASSWD: /bin/systemctl restart myapp

Webアプリの実践的な権限設計 ― 644/755と専用ユーザーの黄金パターン

ここまでの知識を，実際のWebアプリ運用に落とし込もう．「アプリは専用ユーザーが所有・実行し，Webサーバーは読むだけ，書き込みが必要な場所だけ最小限に許可」── これが黄金パターンだ．

Webアプリの権限設計の例

# 所有者=deploy, グループ=www-data(Webサーバー)
sudo chown -R deploy:www-data /var/www/site
# ディレクトリ755 / ファイル644
find /var/www/site -type d -exec chmod 755 {} ;
find /var/www/site -type f -exec chmod 644 {} ;
# 書き込みが必要なのはuploadsだけ → グループに書込許可
sudo chmod -R 775 /var/www/site/uploads
# 秘密ファイルは所有者だけ
chmod 600 /var/www/site/.env

ポイントは「書き込み権限を，本当に必要な場所だけに限定する」ことだ．コードやテンプレートは644(読むだけ)，アップロード先やキャッシュだけ書き込み可にする．これだけで，万一Webサーバー経由で侵入されてもコード本体を書き換えられない状態を作れる．chmod 777を全体に当てるのとは，安全性が天と地ほど違う．

よくある権限トラブルと即効の対処

最後に，現場で頻出する権限トラブルと対処をまとめる．エラーメッセージから原因を逆引きできるようにしておこう．

「Permission denied」で実行できない

スクリプトなら実行権(x)の欠落が大半だ(chmod +x script.sh)．ディレクトリへのアクセスなら，その上位ディレクトリすべてにx権限が必要な点を見落としがちだ．パスを上流からたどって確認しよう．

「アップロード/ログ書き込みに失敗する」

Webサーバーの実行ユーザー(www-data等)に，書き込み先ディレクトリの書き込み権限が無いのが原因だ．該当ディレクトリの所有グループをwww-dataにし，グループ書込(g+w)を許可する．間違っても全体を777にしないこと．

「.sshや鍵が効かない」

SSHは権限が緩いと鍵を拒否するセキュリティ仕様だ．.sshは700，authorized_keysや秘密鍵は600でなければならない．「鍵を置いたのにログインできない」ときは，まずこの権限を確認する．

.ssh の正しい権限

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

補論：権限設計は「壊しても戻せる環境」で練習するのが最速

権限まわりは，頭で理解しても実際にファイルを作り，権限を変え，わざとアクセスを失敗させ，直す体験を通してしか本当には身につかない．そして権限の操作は，一歩間違えると自分がログインできなくなるような事故にも繋がる．

だからこそ，スナップショットで元に戻せるVPSを1台用意して練習するのが圧倒的に安全で速い．chmodやchownを大胆に試し，もし作業不能になっても数分で巻き戻せる．たとえば 高速NVMe・50種類以上のOSテンプレートに対応した国内VPS─シン・VPS─ はスナップショットとコンソールアクセスを備えるため，「sudo権限から外れてしまった」「.sshを壊した」といった事故からも復旧でき，権限の実験場として理想的だ．

実運用に移すなら，独自ドメインを取ってWebアプリを公開し，本記事の644/755＋専用ユーザーの設計を実地で組んでみよう．取り扱い400種類以上のドメイン取得サービス─ムームードメイン─ でドメインを取得してVPSに向ければ，「適切な権限で守られた本番サイト」を月数百円〜で運用できる．正しい権限設計は，最も安価で効果の大きいセキュリティ投資だ．

よくある質問(FAQ)

Q1．結局 chmod 777 はなぜダメなのか？

「世界中の誰でも読み・書き・実行できる」という意味だからだ．Webサーバー経由で侵入された際，777のファイル/ディレクトリは改ざんやマルウェア設置の足場になる．動かないからと777にするのは，鍵を壊して扉を開けっ放しにするのと同じ．正しくは「誰に何が必要か」を考え，644/755/600を使い分ける．

Q2．644と755の使い分けが覚えられない

ディレクトリと実行ファイルは755，それ以外の普通のファイルは644，と覚えれば9割対応できる．ディレクトリは「入る」ためにx権限が要るので755，通常ファイルは実行しないのでxを外して644，という理屈だ．

Q3．所有者とグループはどう設計すべき？

所有者=ファイルを編集する人(deploy等)，グループ=アクセスが必要なサービス(www-data等)が基本形だ．chown deploy:www-dataで「自分は編集，Webサーバーは読む」を実現できる．

Q4．usermodでハマったと聞くが何に注意？

usermod -aGの-aを絶対に忘れないこと．-a無しだと既存の所属グループがすべて消え，sudoグループから外れて作業不能になる事故が起きる．グループ追加は必ず-aGとセットで覚える．

Q5．rootで作業し続けてはいけない理由は？

rootは何でもできるため，1つのミスやマルウェアがシステム全体を破壊しうる．日常は専用一般ユーザーで作業し，必要なときだけsudoで権限を借りる．これが最小権限の原則で，事故と侵害の被害を局所化する．

Q6．権限を一括で正しくリセットしたい

findでファイルとディレクトリを分けて適用する(type d→755，type f→644)．そのうえで秘密ファイル(.env・鍵)を個別に600へ，書き込みが必要なディレクトリだけ最小限にg+wを許可する，という順で整えると安全だ．

まとめ ― 権限を制すれば事故は激減する

Linuxの権限は，「誰に(u/g/o)」×「何を(r/w/x)」というシンプルな構造でできている．この読み方とchmod/chown，そして644/755＋専用ユーザーの設計を押さえれば，VPSの事故の大半は未然に防げる．

今日やるべきことは，自分のサーバーでls -lを打ち，気になるファイルの権限を読み解くこと．そしてchmod 777になっている場所があれば，適切な値に直す．それだけで，あなたのサーバーは一段安全になる．

権限設計は地味だが，最も費用対効果の高いセキュリティだ．スナップショットで戻せるVPSがあれば，今夜から恐れずに練習できる．