ユーザ・グループ・sudo LinuC102 第5回

LinuC レベル1 102試験対策シリーズの第5回です。前回はネットワーク障害の切り分けとDNSクライアント設定を扱いました。今回は 「Linuxにログインできるのは誰か」「誰が何の権限を持つか」 を決める仕組み、つまり ユーザ・グループ・sudo を扱います。

/etc/passwd /etc/shadow /etc/group の3ファイルの構造、useradd usermod userdel passwd chage groupadd gpasswd によるアカウント操作、そして visudo による安全な sudoers 編集 までを実機で読み解きます。

今ここマップ

LinuC 102 試験対策シリーズ（全12回）

  第1回 シェル環境のカスタマイズ
  第2回 Bashスクリプト入門
  第3回 ネットワーク基礎
  第4回 ネットワークトラブルシューティングとDNS
▶ 第5回 ユーザ・グループ管理と sudo 設定    ← いまここ
  第6回 ジョブスケジューリングと時刻管理
  第7回 ログ管理実践
  第8回 メール配送エージェント(MTA)の基本
  第9回 ファイアウォールと SELinux 入門
  第10回 暗号化によるデータ保護
  第11回 クラウドセキュリティの基礎
  第12回 オープンソースの文化

この記事で身につくこと

1. /etc/passwd /etc/shadow /etc/group の各フィールドを説明できる
2. useradd usermod userdel passwd でユーザを作成・変更・削除できる
3. groupadd gpasswd groups id でグループを管理できる
4. sudoers の構文を読み、visudo で安全に編集する手順を説明できる
5. chage でパスワードエージング（有効期限・警告日数）を設定・確認できる

第1章：なぜユーザーとグループを分けるのか

1.1 アクセス制御の基本：「誰が、何を、どうできるか」

Linuxのファイルやサービスへのアクセス制御は、まず 「誰なのか」 を識別することから始まります。識別の単位がユーザー（UID）であり、複数のユーザーをまとめた単位がグループ（GID）です。アクセス権の決定は次の3要素で構成されます。

• 誰が（ユーザーID／所属グループID）
• 何に対して（ファイル／ディレクトリ／デバイス／プロセス）
• どうできるか（読む／書く／実行する／所有者を変える）

第8回（101シリーズ）で扱った chmod や chown はこの3要素のうち 「どうできるか」 を決める仕組みでした。今回はその前提となる 「誰が」 の作り方と管理を学びます。

1.2 個人アカウントと共有アカウント ── なぜ個人で分けるのか

「サーバの作業を全員 root で行う」「全員で operator アカウントを共有する」という運用は、技術的には可能ですが現場では強く避けられます。理由は次の3点で、どれも「誰のために」を考えると見えてきます。

• セキュリティ部門のため：パスワードが流出したとき、影響を1人に局所化したい。共有アカウントだと「誰の管理失敗か」が追えない
• 運用・監査部門のため：「誰が、いつ、何のコマンドを実行したか」を auth.log や /var/log/secure から追跡したい
• 退職対応のため：退職者の権限を1ファイル／1コマンドで剥奪したい。共有アカウントだと全員のパスワードを変更しなくてはならない

つまり「ユーザを個別に作る」のは技術制約ではなく 運用上の要請 です。LinuC試験でも「アカウント管理」は主題1.08.1として独立して扱われており、運用エンジニアにとっての基礎中の基礎と位置づけられています。

第2章：/etc/passwd ── ユーザ定義の本丸

2.1 7つのフィールド

linuc-alma で実機を覗いてみます。

実行コマンド（linuc-alma）：

$ head -5 /etc/passwd

実行結果：

root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
adm:x:3:4:adm:/var/adm:/sbin/nologin
lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin

1行が1ユーザー定義です。コロン区切りで 7フィールド あります。

2行目以降の bin daemon adm lp はすべて shell が /sbin/nologin になっています。これらは サービス専用のシステムユーザ で、人間がログインする目的では使わないアカウントです。

2.2 getent で nsswitch 経由で引く

head でファイルを直接見るだけでなく、getent でも引けます。getent は /etc/nsswitch.conf の passwd: 行に従って、ローカルファイル・LDAP・SSSD などを統合的に検索します。

実行コマンド（linuc-alma）：

$ getent passwd developer

実行結果：

developer:x:1000:1000:developer:/home/developer:/bin/bash

developer ユーザーは UID 1000（一般ユーザ領域の先頭）、GID 1000、home は /home/developer、shell は /bin/bash です。実務では grep developer /etc/passwd よりも getent passwd developer を使うのが王道です。LDAP 認証のサーバでも同じコマンドで通用するからです。

第3章：/etc/shadow ── 暗号化パスワードと有効期限

3.1 9つのフィールド

/etc/shadow は root しか読めない ファイルです。passwd 側に置くと一般ユーザにハッシュが見えてしまうため、別ファイルに分離されました。

実行コマンド（linuc-alma）：

$ sudo getent shadow developer

実行結果：

developer:$6$ros/Bz2jd4nj8ZBA$B3nclftSdrvNQw/.rI4I6nKnxxr7OSZDeLff.j6oGTBMKbX.GPSI9ypC.94yYMgx7rboikBn4G.dj4Jw49NpK1::0:99999:7:::

こちらもコロン区切りで、9フィールド あります（末尾の ::: は空フィールド3つ）。

3.2 パスワード欄の先頭記号

パスワード欄の先頭の $6$ は 暗号化アルゴリズムの識別子 です。

passwd -l user でロックすると、ハッシュの先頭に ! が付加されます。passwd -u user で外れます。これがロック／解除の実装です。

3.3 chage でエージング情報を確認

shadow を直接読むよりも、chage -l（lowercase L）で読みやすく整形できます。

実行コマンド（linuc-alma）：

$ sudo chage -l developer

実行結果（LANG=ja_JP.UTF-8 の環境）：

最終パスワード変更日				:なし
パスワード期限:					: なし
パスワード無効化中					: なし
アカウント期限切れ						: なし
パスワードが変更できるまでの最短日数		: 0
パスワードを変更しなくてよい最長日数		: 99999
パスワード期限が切れる前に警告される日数		: 7

ロケールにより表記が変わる点に注意してください。試験では英語表記（Last password change、Password expires、Minimum number of days between password change など）で問われることが多いので、両方の対応関係を覚えておきます。

主な chage オプションは次のとおりです。

第4章：/etc/group ── 複数ユーザのまとめ単位

4.1 4つのフィールド

実行コマンド（linuc-alma）：

$ head -5 /etc/group

実行結果：

root:x:0:
bin:x:1:
daemon:x:2:
sys:x:3:
adm:x:4:

こちらは 4フィールド です。

4.2 プライマリグループとサブ（補助）グループ

あるユーザが所属するグループは 1つのプライマリと、0個以上のサブ（補助）グループ に分かれます。

• プライマリグループ：/etc/passwd の 4 番目のフィールドで指定。ファイルやディレクトリを新規作成すると既定でこのグループが所有者になる
• サブ（補助）グループ：/etc/group の 4 番目のフィールドにユーザ名が並ぶ。複数所属可能

実機の developer で所属を見てみます。

実行コマンド（linuc-alma）：

$ groups developer
$ id developer

実行結果：

developer : developer wheel
uid=1000(developer) gid=1000(developer) groups=1000(developer),10(wheel)

プライマリは developer（GID 1000）、サブで wheel（GID 10）に所属しています。wheel は RHEL系で sudo を許可される伝統的なグループ名です（後述）。

4.3 RHEL系の「ユーザプライベートグループ」方式

AlmaLinux で useradd foo とすると、同名のグループ foo が同時に作られ、プライマリに設定されます。これを「ユーザプライベートグループ（UPG）」と呼びます。 /etc/login.defs の USERGROUPS_ENAB yes によって有効化されています。利点は、umask 002 等と組み合わせて「自分の作るファイルは自分のグループだけが共有できる」を簡単に実現できる点です。

第5章：useradd / usermod / userdel

5.1 useradd の典型形

新規ユーザを作る一般的な書式は次のとおりです。

実行コマンド（linuc-alma、テスト用なので作成後にすぐ削除します）：

$ sudo useradd -m -s /bin/bash -c "LinuC Test User 01" linuc-test01

主なオプションは次のとおりです。

5.2 既定値の確認 ── useradd -D と /etc/login.defs

新規ユーザに何が割り当てられるかの既定値は、2つのファイルで決まります。

実行コマンド（linuc-alma）：

$ useradd -D
$ grep -E '^UID_MIN|^UID_MAX|^GID_MIN|^GID_MAX' /etc/login.defs

実行結果：

GROUP=100
HOME=/home
INACTIVE=-1
EXPIRE=
SHELL=/bin/bash
SKEL=/etc/skel
CREATE_MAIL_SPOOL=yes
UID_MIN                  1000
UID_MAX                 60000
GID_MIN                  1000
GID_MAX                 60000

useradd -D は /etc/default/useradd の内容を表示します。SHELL=/bin/bash や SKEL=/etc/skel（ホームディレクトリの雛形）が定義されています。/etc/login.defs の UID_MIN=1000 によって「一般ユーザは UID 1000 から振られる」が決まっています。

5.3 作成後の確認

linuc-test01 を作った直後の状態を確認します。

実行コマンド（linuc-alma）：

$ getent passwd linuc-test01
$ id linuc-test01
$ sudo ls -ld /home/linuc-test01

実行結果：

linuc-test01:x:1001:1001:LinuC Test User 01:/home/linuc-test01:/bin/bash
uid=1001(linuc-test01) gid=1001(linuc-test01) groups=1001(linuc-test01)
drwx------. 2 linuc-test01 linuc-test01 62  5月 13 23:20 /home/linuc-test01

UID 1001、同名プライマリグループ 1001、home ディレクトリは 0700 パーミッション（他ユーザは中を見られない）で作られました。AlmaLinux 9 の既定はこの 0700 で、他人のホームを覗けないようになっています。

5.4 usermod ── 既存ユーザの変更

サブグループの追加が現場で一番よく使う操作です。-a（append）を付け忘れると既存所属が全て上書きされる ので要注意です。

実行コマンド（linuc-alma）：

$ sudo groupadd dev-team
$ sudo usermod -aG dev-team linuc-test01
$ id linuc-test01

実行結果：

uid=1001(linuc-test01) gid=1001(linuc-test01) groups=1001(linuc-test01),1002(dev-team)

サブに dev-team（GID 1002）が追加されました。主な usermod オプションは次のとおりです。

5.5 userdel ── ユーザ削除

削除も実演します。-r でホームディレクトリも消えます。

実行コマンド（linuc-alma）：

$ sudo userdel -r linuc-test01
$ id linuc-test01 2>&1

実行結果：

id: `linuc-test01': no such user

passwd / shadow / group の3ファイルからも消え、/home/linuc-test01 も削除されました。-r を付けないと home が残るため、ディスク掃除を別途行う必要があります。退職対応では「権限剥奪はすぐ、home の削除は引き継ぎ後」という分け方をすることも多く、まず passwd -l でロックし、後日 userdel -r で完全削除 という流れが現場の定石です。

第6章：passwd と chage

6.1 passwd の使い分け

passwd は引数なしで実行すると自分自身のパスワードを変更します。ユーザ名を引数に取ると、root 権限が必要です。

passwd -d はパスワード認証を「無し」にしてしまうため、SSH の PasswordAuthentication を有効にしているサーバでは 致命的なセキュリティホール になります。鍵認証専用に運用しているサーバでも、設定ミスで戻ったときに丸裸になるため、本番では使わないのが鉄則です。

6.2 chage の典型操作

第3章で見た chage -l 以外に、有効期限や警告日数を変更する操作があります。例：90日でパスワード強制変更、変更前14日から警告。

実行コマンド（linuc-alma、想定例）：

$ sudo chage -M 90 -W 14 username

これで「最後の変更から90日でパスワード強制変更」「期限の14日前から警告」となります。社内ポリシー（90日ごとに変更等）の実装はこの2オプションで足ります。

第7章：groupadd / gpasswd / groupdel

7.1 groupadd と groupdel

グループの作成は groupadd、削除は groupdel です。実行例は第5章で dev-team の作成を扱いました。書式と主なオプションを整理します。

groupdel は、削除しようとするグループを誰かのプライマリグループとして使っている場合に失敗します。サブグループのメンバーは消しても問題ありません。誰のプライマリになっているかは awk -F: '$4=="GID" {print $1}' /etc/passwd 等で確認できます。

7.2 gpasswd ── グループへのメンバー追加

usermod -aG の代わりに gpasswd -a でもサブグループへの追加ができます。挙動はほぼ同じです。

現場では usermod -aG のほうが定着していますが、試験では gpasswd もよく出題されます。

第8章：sudo の仕組みと visudo

8.1 su と sudo の違い

同じ「root 権限を得る」手段でも、su と sudo はモデルが大きく違います。

現代の Linux 運用では 「root に直接ログインさせず、sudo 経由で必要な操作だけ昇格させる」 が標準です。誰のためかというと、監査担当・セキュリティ担当・運用責任者のためです。「誰が、いつ、何のコマンドを root 権限で実行したか」を後から追えるからです。

8.2 /etc/sudoers の構文

sudoers の基本書式は次のとおりです。

who   where=(as_who)   what

• who：ユーザ名（developer）またはグループ（%wheel、先頭の % がグループの印）
• where：実行を許可するホスト（ALL または specific hostname）
• as_who：どのユーザとして実行するか（既定は root）
• what：実行可能コマンドのパス（ALL または specific path）

AlmaLinux の既定の sudoers から代表的な行を見てみます。

実行コマンド（linuc-alma）：

$ sudo grep -E '^[^#]' /etc/sudoers | grep -v '^$' | head -10

実行結果：

Defaults   !visiblepw
Defaults    always_set_home
Defaults    match_group_by_gid
Defaults    always_query_group_plugin
Defaults    env_reset
Defaults    env_keep =  "COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS"

先頭の Defaults 行は sudo の挙動を細かく設定するもので、AlmaLinux ではセキュリティ重視の既定が並びます。実際の許可ルールは下のほうにある %wheel ALL=(ALL) ALL（wheel グループに root 権限を与える）が代表例です。

8.3 /etc/sudoers.d/ ── 分割管理

/etc/sudoers 本体を直接編集せず、/etc/sudoers.d/ 配下に1ファイルずつ置く管理が推奨です。本シリーズの linuc-alma にも、developer 用のファイルが既に置かれています。

実行コマンド（linuc-alma）：

$ sudo ls -la /etc/sudoers.d/
$ sudo cat /etc/sudoers.d/developer

実行結果：

合計 16
drwxr-x---.  2 root root   23  5月  9 19:30 .
drwxr-xr-x. 84 root root 8192  5月 13 23:20 ..
-r--r-----.  1 root root   33  5月  9 19:30 developer
developer ALL=(ALL) NOPASSWD:ALL

ディレクトリ /etc/sudoers.d/ は 0750、配下のファイルは 0440（読み取り専用）です。NOPASSWD: はパスワード入力なしで sudo を許可する指定で、本シリーズの検証環境用に設定されています。本番ではパスワードを求めるのが標準です。

分割管理の利点は次の3つです。

• パッケージごと・チームごとに1ファイルで管理できる（変更影響範囲が見える）
• Ansible 等の構成管理ツールで ファイル単位で配布 できる
• うっかり編集ミスで sudoers 本体を壊すリスクを下げられる

8.4 visudo ── 安全な編集の作法

sudoers を編集するときは 必ず visudo を経由 します。理由は3つあります。

• 排他制御：他人が同時に編集しないようロックする
• 構文チェック：保存時に文法エラーがあると、上書き前に警告して中断する
• 戻し機構：エラーがあれば再編集／破棄／強制保存を選べる

vi /etc/sudoers で直接編集して構文ミスを保存してしまうと、sudo 自体が起動できなくなり、root にも昇格できなくなる という事故が起こります（後述のヒヤリハット）。

/etc/sudoers.d/ 配下を編集するときも visudo -f でファイルを指定するのが定石です。書き込みを伴わない構文チェックだけなら、次のコマンドが安全です。

実行コマンド（linuc-alma）：

$ sudo visudo -c

実行結果：

/etc/sudoers: 正しく構文解析されました
/etc/sudoers.d/developer: 正しく構文解析されました

-c はチェック専用（check）モードで、/etc/sudoers と /etc/sudoers.d/ 配下の全ファイルを検証します。Ansible で sudoers を配布した直後にこれを走らせる、というのが現場のテンプレです。

8.5 sudo -l ── 自分の許可コマンドを見る

自分が sudo で何を実行できるかは sudo -l で確認できます。

実行コマンド（linuc-alma、developer で実行）：

$ sudo -l

実行結果（冒頭の Defaults 行は長いため省略）：

既定値のエントリと照合中 (ユーザー名 developer) (ホスト名
    linuc-alma):
    !visiblepw, always_set_home, ...（中略）...
    secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin

ユーザー developer は linuc-alma 上で コマンドを実行できます
    (ALL) ALL
    (ALL) NOPASSWD: ALL

下半分の「コマンドを実行できます」のブロックが本題です。2行表示されているのは、/etc/sudoers 本体の %wheel ALL=(ALL) ALL ルール（developer は wheel メンバー）と、/etc/sudoers.d/developer の NOPASSWD ルールが両方マッチしているからです。後ろのルールほど優先されるため、結果として「パスワード不要で何でも実行できる」になっています。

第9章：現場での使いどころ

現場での使いどころ

本章で扱った内容は、現場の以下の場面で日常的に使われます。

• 新規メンバーのアカウント発行：useradd -m -c "氏名" でユーザ作成 → passwd -e で初回ログイン時に強制変更 → usermod -aG team でチームグループに追加。手順をテンプレート化して Ansible や Slack ワークフローに組み込むのが一般的
• 退職者の権限剥奪：当日中に passwd -l または usermod -L でロック → SSH 公開鍵を ~/.ssh/authorized_keys から除去 → 引き継ぎ完了後に userdel -r で完全削除。即削除しないのは、メールや作業履歴の引き継ぎが残るため
• 運用ロールの分離：read-only 作業者には sudo -l でログ閲覧コマンドだけ許可（%audit ALL=(ALL) NOPASSWD: /usr/bin/journalctl, /usr/bin/cat /var/log/*）／ 本番デプロイ者には systemctl と nginx -t だけ ／ root 並み権限は %wheel ALL=(ALL) ALL で最少人数に
• sudo 実行履歴の追跡：誰が何を実行したかは /var/log/secure（AlmaLinux）に記録される。journalctl _COMM=sudo や grep sudo /var/log/secure で抽出できる。インシデント対応の最初の手掛かりになる
• パスワードポリシーの実装：90日変更ルールは chage -M 90 -W 14 user をユーザ作成スクリプトに組み込む。組織共通の規約として /etc/login.defs の PASS_MAX_DAYS も合わせて設定する
• サービスアカウントの作成：アプリ専用ユーザは useradd -r -s /sbin/nologin -d /var/lib/myapp myapp で UID<1000、ログイン不可、home は /var/lib/ 配下に置く。systemd の User= 指定と組み合わせて使う

第10章：ヒヤリハット

>>> /etc/sudoers: syntax error near line N <<<
sudo: /etc/sudoers の解析エラー、行 N 付近
sudo: 構文エラーが見つかりました
sudo: 設定ファイル /etc/sudoers の読み込みエラー
sudo: 終了します。

第11章：やってみよう

linuc-alma にログインして次の4つの演習を順に実行してください。所要時間は20〜30分です。すべて検証用ユーザ／グループを使うため、既存の developer や /etc/sudoers 本体には影響しません。

演習1：3つの設定ファイルを読む

実行コマンド（linuc-alma）：

$ head -5 /etc/passwd
$ sudo head -5 /etc/shadow
$ head -5 /etc/group
$ getent passwd developer
$ groups developer
$ id developer

確認ポイント：

• passwd の各行が7フィールドあること
• shadow は sudo を付けないと 許可がありません になること
• developer の UID が 1000、wheel に所属していること

演習2：ユーザ作成 → 確認 → 削除

実行コマンド（linuc-alma）：

$ sudo useradd -m -s /bin/bash -c "LinuC Test User 01" linuc-test01
$ getent passwd linuc-test01
$ id linuc-test01
$ sudo ls -ld /home/linuc-test01
$ sudo chage -l linuc-test01
$ sudo userdel -r linuc-test01
$ id linuc-test01 2>&1

確認ポイント：

• linuc-test01 の UID が 1001（既存の最大 UID + 1）
• ホームディレクトリのパーミッションが 0700
• 削除後は id: 'linuc-test01': no such user になる

演習3：グループ作成と補助グループ追加

実行コマンド（linuc-alma）：

$ sudo groupadd dev-team
$ getent group dev-team
$ sudo useradd -m linuc-test02
$ sudo usermod -aG dev-team linuc-test02
$ groups linuc-test02
$ id linuc-test02
$ sudo userdel -r linuc-test02
$ sudo groupdel dev-team
$ getent group dev-team 2>&1 || echo "group deleted"

確認ポイント：

• linuc-test02 のプライマリは同名のユーザプライベートグループ、サブに dev-team が入る
• 削除後 getent は何も返さず group deleted が表示される

演習4：sudoers を読む（変更はしない）

実行コマンド（linuc-alma）：

$ sudo grep -E '^[^#]' /etc/sudoers | grep -v '^$' | head -10
$ sudo ls -la /etc/sudoers.d/
$ sudo cat /etc/sudoers.d/developer
$ sudo -l
$ sudo visudo -c

確認ポイント：

• sudoers 本体の Defaults 行を眺める（覚えなくてよい）
• developer のルールが /etc/sudoers.d/developer に分離されていることを確認
• sudo -l で wheel グループ経由と NOPASSWD の2系統が見えること
• visudo -c がすべて 正しく構文解析されました を返すこと（壊れていない証拠）

困ったらマニュアルを引きます。man useradd man usermod man userdel man passwd man chage man groupadd man gpasswd man sudoers man visudo はすべてインストール済みです。useradd -h や chage --help でオプションの一覧も即座に取り出せます。暗記より、必要なときに引ける状態を目指してください。

理解度チェック

次の5問を ○×（または該当オプション）で答えてください。解答は記事末尾にあります。

1. /etc/passwd のフィールド数は8つである。
2. /etc/shadow のパスワード欄が $6$ で始まる場合、ハッシュアルゴリズムは SHA-256 である。
3. usermod -G dev-team linuc-test01（-a なし）を実行すると、linuc-test01 の既存サブグループ所属はすべて失われ、dev-team だけになる。
4. userdel でホームディレクトリも同時に削除するオプションは -r である。
5. sudoers を編集するとき、vi /etc/sudoers で直接編集するのが推奨される。

解答

1. ×（7つ：name : passwd-flag : UID : GID : GECOS : home : shell）
2. ×（$6$ は SHA-512。SHA-256 は $5$）
3. ○（-a なしの -G はサブグループを置き換える。所属を残したいなら -aG）
4. ○（-r でホームと mail spool も削除）
5. ×（必ず visudo を使う。構文チェックと排他制御が働く）

次回予告

次回（第6回）は 「ジョブスケジューリングと時刻管理」 です。cron と systemd timer の使い分け、chrony による NTP クライアント設定、timedatectl でのタイムゾーン管理を扱います。バックアップ・ログローテーション・ヘルスチェックといった「定期実行」と、ログ調査で必須の「正確な時刻」をセットで学びます。

LinuC 102 試験対策シリーズ（全12回）

1. シェル環境のカスタマイズ：環境変数・エイリアス・履歴・ロケール
2. Bashスクリプト入門：if/for/関数で書く現場の自動化スクリプト
3. ネットワーク基礎：TCP/IP・ip コマンド・NetworkManager
4. ネットワークトラブルシューティングとDNSクライアント設定
5. ユーザ・グループ管理と sudo 設定の実務（useradd, visudo）
6. ジョブスケジューリングと時刻管理：cron, systemd timer, chrony, NTP
7. ログ管理実践：journalctl と rsyslog の使い分け
8. メール配送エージェント(MTA)の基本：postfix の動作確認
9. ファイアウォール（firewalld / ufw）と SELinux 入門
10. 暗号化によるデータ保護：SSH鍵認証・GnuPG・OpenSSL
11. クラウドセキュリティの基礎：IAM・公開鍵管理・SSH踏み台構成
12. オープンソースの文化：主要ライセンス（GPL/MIT/Apache）とコミュニティ