先日、チームにジュニアエンジニアをオンボーディングしたとき、彼が最初に聞いてきたのが：“サーバーに新しいユーザーを作るにはuseraddとadduser、どちらを使えばいいですか？”という質問でした。一見シンプルに見えますが、これがきっかけで、Linuxを長年使っているユーザーでも混乱しがちなテーマが浮かび上がってきました。
10台以上のVPSを3年間管理してきた中で、sudoの設定ミスでサーバーからロックアウトされた経験があります。また、uploadディレクトリのpermission設定ミスが原因でサイトが約2時間ダウンした現場も見てきました。ユーザーとpermissionは、ほんの少しのミスがすぐに深刻な結果をもたらします――通常のコードならgit revertで戻せますが、これはそうはいきません。
1. ユーザー作成：useradd vs adduser — どちらを使うべき？
この2つのコマンドは見た目は似ていますが、動作は大きく異なります。
useradd — 低レベル、最小限の設定
useraddは低レベルのコマンドで、最小限のパラメータでユーザーを作成します。フラグを追加しない場合、ホームディレクトリは作成されず、適切なデフォルトシェルも設定されず、パスワードも設定されません。
# シンプルなuseradd — 多くの設定が不足している
sudo useradd newuser
# 結果：ユーザーは作成されるがホームディレクトリなし、デフォルトシェルは/bin/sh
# 使えるようにするには十分なフラグが必要
sudo useradd -m -s /bin/bash -c "Nguyen Van A" newuser
# -m：ホームディレクトリを作成
# -s：シェルを指定
# -c：コメント（通常はフルネーム）adduser — 高レベル、対話型、よりユーザーフレンドリー
Debian/Ubuntuのadduserはラッパースクリプトで、ホームディレクトリの自動作成、パスワードの確認、コメント入力などを自動で行います。CentOS/RHELではadduserは単にuseraddへのシンボリックリンクなので、まったく同じ動作をします。
# Ubuntu/Debianのadduser — 対話型でより使いやすい
sudo adduser newuser
# スクリプトが確認：パスワード、フルネーム、電話番号など
# /home/newuserを自動作成し、/etc/skelからスケルトンをコピーどちらを使うべき？
- useradd：すべてのディストリビューションで利用可能、スクリプト自動化に適しているが、各フラグを自分で管理する必要があり見落としやすい
- adduser：手動での使用に親しみやすいが、Debianベースのみで使用可能。クロスプラットフォームスクリプトでは使用不可
まとめ：Ubuntu/Debianで手動操作ならadduser。自動スクリプトを書くかCentOS/RHELで実行するなら、十分なフラグを付けたuseradd -m -s /bin/bashを使用してください。
2. Permission：chmod数値 vs chmod記号
多くの人が「魔法の数字を覚えるだけ」という学び方をして、その理由を理解しないまま使っています――行き詰まるとchmod 777で解決しようとして、後でなぜサイトが侵害されたのか分からなくなるのです。
chmod数値（Octal）— 慣れれば速い
# 計算式：read=4、write=2、execute=1
# 755 = rwxr-xr-x
# Owner: 4+2+1=7 | Group: 4+1=5 | Others: 4+1=5
chmod 755 /var/www/html
# 644 = rw-r--r--（通常のファイル）
chmod 644 index.html
# 600 = rw-------（機密ファイル：SSHキー、パスワードファイル）
chmod 600 ~/.ssh/id_rsa
# 700 = rwx------（オーナーのみが使用するディレクトリ）
chmod 700 ~/privatechmod記号（Symbolic）— 初心者に分かりやすい
# u=user/owner, g=group, o=others, a=all
# +追加、-削除、=正確に設定
# オーナーにexecuteを追加
chmod u+x deploy.sh
# グループとothersのwriteを削除
chmod go-w config.yaml
# 正確に設定：オーナー rwx、グループ r-x、others は何もなし
chmod u=rwx,g=rx,o= script.shどちらをいつ使う？
- Octal：入力が速いが、頭の中で計算が必要――疲れているときはミスしやすい
- Symbolic：より明確で、他の部分を変更せずに必要なビットだけを変更できる――既存のpermissionを修正するときにより安全
実践的なTip：stat -c "%a %n" filenameを使うとpermissionをoctal形式で確認できます――別の場所にコピーする必要があるときはls -lより便利です。
# permissionをoctal形式で確認
stat -c "%a %n" /etc/passwd
# Output: 644 /etc/passwd
# 複数のファイルを同時に確認
stat -c "%a %n" /var/www/html/*3. Ownership：chownとchgrp
permissionが正しくてもownerが間違っていればアクセスは拒否されます。これはWebアプリをデプロイするときによくあるミスです――rootで作成したファイルを、nginx/apacheがwww-dataユーザーで動作しているため読み取れないというケースです。
# オーナーを変更
sudo chown www-data /var/www/html/uploads
# オーナーとグループを同時に変更
sudo chown www-data:www-data /var/www/html/uploads
# ディレクトリ全体を再帰的に変更 — -Rに注意！
sudo chown -R www-data:www-data /var/www/html/
# グループのみ変更
sudo chgrp developers /var/log/app.log警告：chown -Rを使う際は、パスが正しいことを確認してください。パスを間違えて/var全体をchownしてしまい、ownership設定が狂って多くのサービスが起動できなくなった事例を見たことがあります。
4. Sudo：適切な権限付与
よく見かける2つの極端なパターンがあります：利便性のためにすべてのユーザーをsudoグループに追加するか、完全にロックしてroot権限が必要な作業はすべて専用アカウントでSSHするかです。どちらもそれぞれの問題があります。
方法1：sudoグループへの追加 — シンプルだがリスクあり
# Ubuntu/Debian
sudo usermod -aG sudo username
# CentOS/RHEL/Fedora
sudo usermod -aG wheel username
# ユーザーが所属するグループを確認
id username
groups username方法2：sudoers経由で具体的な権限付与 — より安全
# 必ずvisudoで編集すること — 保存前に構文を自動チェックする
sudo visudo
# または/etc/sudoers.d/に個別ファイルを作成（推奨）
sudo visudo -f /etc/sudoers.d/deployer
# 'deployer'ユーザーがパスワードなしでnginxをreloadできるように許可
deployer ALL=(ALL) NOPASSWD: /usr/bin/systemctl reload nginx
# 'developers'グループがログを閲覧できるように許可
%developers ALL=(ALL) NOPASSWD: /usr/bin/tail -f /var/log/nginx/access.logなぜフルsudo権限が危険なのか？
- sudoグループへのフルアクセス：開発環境では便利ですが、ユーザーはproductionで何でもできてしまいます――誤って削除してしまうことも含めて
- 具体的なsudoers設定：最小権限の原則に従い――必要な操作だけを許可し、それ以上でもそれ以下でもない
Productionでは、サービスアカウントに対して常に具体的なsudoers設定を使用しています。deployユーザーはnginxのreloadとappサービスのrestartしかできません――やりたくても他のことは何もできない設定です。
5. Permission監査 — このステップを省略しないでください
permissionの設定方法を知ることと、現在のシステムが正しく設定されているかを確認することは別の話です。新しいサーバーをレビューするとき――特に他の人から引き継いだサーバーの場合は――次のコマンドをよく使います：
# SUIDビットを持つファイルを検索（セキュリティリスクの可能性あり）
find / -perm /4000 -type f 2>/dev/null
# world-writableなファイルを検索 — 誰でも書き込めるため非常に危険
find /var/www -perm -002 -type f 2>/dev/null
# オーナーが存在しないファイルを検索（孤立ファイル）
find /home -nouser -o -nogroup 2>/dev/null
# ユーザーがsudoで実行できるコマンドを確認
sudo -l -U usernameまとめ：最初から正しく設定する
- Productionサーバー：専用サービスユーザーを作成（rootを使わない）、最小限の権限を付与、必要なコマンドごとに具体的なsudoers設定を行う
- Dev/staging：より柔軟でも構いませんが、開発者がrootを直接使うのは避けるべき――productionで悪い習慣につながります
- Webサーバーのファイル：ownerはwebユーザー（www-data/nginx）、ファイルはpermission 644、ディレクトリは755、機密ファイルは600
- スクリプト自動化：十分なフラグを付けた
useraddを使用し、各ディストリビューションのデフォルト動作に依存しないこと
最初から守っているルールがあります：chmod 777は怠慢のサインであり、解決策ではない。permission deniedに遭遇したときは、すべての権限を開放する前に立ち止まって原因を理解してください。
まずVMやコンテナで練習して、各コマンドをしっかり理解してからproductionに適用する――それが自分の学び方であり、業界に入ったばかりの人へのアドバイスです。
