RHEL 基礎 #5 ユーザー/グループ/権限 — UID/GID、sudo、ACL

#4 の systemd unit に User=nobody のような一行を書きました。そのユーザーがシステムにどのように存在し、どのファイルにアクセスできるかが今回のテーマです。運用の課題の半分は権限問題で、権限事故の半分は広すぎる権限から起きます。

RHEL 基礎 シリーズでこの記事の位置:

• #1 RHEL とは — Fedora から RHEL まで、そして AlmaLinux と Rocky Linux
• #2 セットアップ — RHEL 9 インストール、Subscription Manager、初ログイン
• #3 dnf とパッケージ管理 — repo、modules、AppStream
• #4 systemd 入門 — サービス、target、journalctl
• #5 ユーザー/グループ/権限 — UID/GID、sudo、ACL ← この記事
• #6 ファイルシステムの基本 — XFS、mount、/etc/fstab
• #7 基本セキュリティ — firewalld、SSH ハードニング

ユーザーはどこに住むのか — /etc/passwd / /etc/shadow #

Linux のユーザーは二つのファイルに分けて書かれています。

/etc/passwd #

$ grep curtis /etc/passwd
curtis:x:1000:1000:Curtis Kim:/home/curtis:/bin/bash

コロン区切りで 7 フィールド:

このファイルは すべてのユーザーが読めます (ユーザー → UID のマッピングがシステムのあちこちで使われるため)。

/etc/shadow #

$ sudo grep curtis /etc/shadow
curtis:$6$abc...$xyz...:19457:0:99999:7:::

パスワードハッシュと有効期限ポリシーが入ったファイル。600 (root only) 権限なので一般ユーザーには見えません。

UID の意味 #

   0          → root
   1 ~ 999    → システムユーザー (サービスが自分のユーザーで起動するとき)
   1000~      → 一般ユーザー

useradd が次の空いている一般 UID を自動で割り当てます。通常 1000 から開始。

システムユーザーが別にある理由 — nginx、postgres、mysql のようなデーモンが root で立ち上がっていると、一度突破されたらシステム全体が危険。だからパッケージインストール時に nginx、postgres のようなシステムユーザーが自動で作られ、デーモンはそのユーザーで起動します。RHEL の nginx パッケージをインストールしたら id nginx で UID が確認できます。

グループ — /etc/group #

$ grep curtis /etc/group
wheel:x:10:curtis
curtis:x:1000:

• curtis:x:1000: — curtis ユーザーの デフォルトグループ (UID と同じ GID で自動生成。RHEL の user private group パターン)
• wheel:x:10:curtis — curtis が追加で入っているグループ。wheel は sudo 権限を受けるグループ

$ id
uid=1000(curtis) gid=1000(curtis) groups=1000(curtis),10(wheel)

$ groups
curtis wheel

デフォルトグループは一つ、追加グループは複数入れられます。

useradd / usermod / userdel #

$ sudo useradd -m -s /bin/bash -G wheel alice
$ sudo passwd alice

useradd のよく使うオプション:

$ sudo usermod -aG wheel alice          # wheel グループに追加 (-a がないと既存グループを上書き!)
$ sudo usermod -s /bin/zsh alice        # シェル変更
$ sudo usermod -L alice                 # ロック (パスワード無効化)
$ sudo usermod -U alice                 # ロック解除

落とし穴 — -G だけ使うと 既存の追加グループをすべて上書きします。 必ず -aG (--append --groups) で書いてください。これを一度間違えると、ユーザーが突然 sudo できなくなる事故になります。

$ sudo userdel alice                    # ユーザーだけ削除 (ホームは残る)
$ sudo userdel -r alice                 # ホームディレクトリとメールスプールまで削除

運用マシンで userdel -r は慎重に — ホームに大事なファイルがあるかもしれません。通常は usermod -L でロックする程度で十分。

パスワードポリシー #

$ sudo chage -l curtis
Last password change                         : Apr 12, 2026
Password expires                             : never
Password inactive                            : never
Account expires                              : never
Minimum number of days between password change : 0
Maximum number of days between password change : 99999

$ sudo chage -M 90 -m 7 -W 14 curtis    # 90 日で期限、7 日以内は変更不可、14 日前から警告

ファイル権限 — rwx の意味 #

Linux のファイル / ディレクトリには三つのユーザー領域 (所有者 / グループ / その他) ごとに三つの権限 (r/w/x) があります。

$ ls -l
-rw-r--r--. 1 curtis curtis  256 Apr 13 10:00 notes.txt
drwxr-xr-x. 2 curtis curtis    6 Apr 13 09:55 docs

   - rw- r-- r-- .
   │ │   │   │   └── SELinux context 表示 (.) — [#7] でちらっと
   │ │   │   └────── その他 (other): r-- (読み取りのみ)
   │ │   └────────── グループ (group):  r-- (読み取りのみ)
   │ └────────────── 所有者 (user): rw- (読み書き)
   └──────────────── 種類: - 通常ファイル / d ディレクトリ / l シンボリック / b ブロック / c キャラクタ

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

ディレクトリの x が直感とずれる部分です。ディレクトリに x がないと、その中のファイルはどんな権限でもアクセスできません。 「ファイル権限はすべて開いているのに何で読めない?」となったら 99% これです。

chmod — 二つの表記 #

8 進数 (numeric) 表記 #

各権限をビットで:

r = 4, w = 2, x = 1
rwx = 7   r-x = 5   r-- = 4   --- = 0

三つの領域 (所有者/グループ/その他) を一桁ずつ:

$ chmod 644 file.txt          # rw-r--r--   通常ファイルのデフォルト
$ chmod 600 secret.key        # rw-------   非公開ファイル (SSH 鍵など)
$ chmod 755 script.sh         # rwxr-xr-x   実行可能スクリプト
$ chmod 700 ~/.ssh            # rwx------   SSH ディレクトリ
$ chmod 750 dir               # rwxr-x---   所有者 + グループアクセス、外部遮断

運用で一番よく出会う 4-5 パターンなので手に馴染ませると良いです。

シンボリック (symbolic) 表記 #

$ chmod u+x script.sh         # 所有者に x を追加
$ chmod g-w file              # グループの w を削除
$ chmod o= file               # その他の権限をすべて削除
$ chmod a+r file              # all (全員) に r を追加
$ chmod u=rw,g=r,o= file      # 絶対指定 (= で)

人間に少し優しいので、一つの権限だけ抜いたり足したりするときによく使います。

chown / chgrp — 所有者を変える #

$ sudo chown alice file              # 所有者だけ
$ sudo chown alice:devs file         # 所有者とグループ同時
$ sudo chgrp devs file               # グループだけ
$ sudo chown -R alice:devs /var/app  # ディレクトリ全体を再帰的に

-R は運用でよく使いますが危険なオプションです。一度間違えるとシステムディレクトリの所有者が丸ごと変わって起動不能になりかねません。パスを二度確認してから押してください。

特殊ビット — SUID / SGID / Sticky #

rwx だけでは足りないケースがあるので、ビットがさらに三つあります。

$ ls -l /usr/bin/passwd
-rwsr-xr-x. 1 root root ... /usr/bin/passwd       # rws — SUID 付き

$ ls -ld /tmp
drwxrwxrwt. ... /tmp                               # rwt — sticky 付き

$ chmod 4755 myprog          # SUID + 755
$ chmod g+s shared-dir       # ディレクトリに SGID
$ chmod +t /shared           # sticky

運用で自分が SUID を付けることは稀で、既に付いている SUID バイナリの一覧を定期点検する のがセキュリティ管理の基本です (find / -perm -4000 のようなコマンドで)。

umask — 新規ファイルのデフォルト権限 #

新しく作ったファイルの権限が通常 644、ディレクトリが 755 なのは umask のためです。

$ umask
0022

umask は「デフォルトの最大権限から引くビット」です。ファイルのデフォルト最大は 666、ディレクトリは 777。そこから 022 を引くと:

ファイル:     666 - 022 = 644 (rw-r--r--)
ディレクトリ: 777 - 022 = 755 (rwxr-xr-x)

サーバーでは通常 umask 027 または 077 でもっと狭く — 新規ファイルがその他のユーザーから見えないように。/etc/profile、/etc/bashrc、または各ユーザーの ~/.bashrc で設定。

ACL — rwx では足りないとき #

標準の rwx は一人のユーザーと一つのグループしか扱えません。二つのグループに別の権限 を与えたり、特定の一人のユーザーにだけ追加権限 を与えるケースには足りません。そこで使うのが ACL (Access Control List) です。

確認 — getfacl #

$ getfacl /var/data
# file: var/data
# owner: root
# group: data
user::rwx
group::r-x
other::---

ACL が追加されていないファイルは普通の rwx と同じ情報が表示されます。

設定 — setfacl #

$ sudo setfacl -m u:alice:rwx /var/data
$ getfacl /var/data
# file: var/data
# owner: root
# group: data
user::rwx
user:alice:rwx              ← 新しく追加
group::r-x
mask::rwx
other::---

$ sudo setfacl -m g:devs:r-x /var/data

$ sudo setfacl -x u:alice /var/data           # 一項目だけ削除
$ sudo setfacl -b /var/data                   # すべての ACL を削除

ACL が付いたファイルは ls -l で権限の末尾に + が表示されます。

$ ls -l /var/data
drwxrwx---+ 2 root data 6 Apr 13 11:00 /var/data
                    ↑
                    ACL が追加で付いている印

default ACL — 新しく作られるファイルに自動適用 #

ディレクトリの default ACL は、その中で 新しく作られる ファイル/ディレクトリに自動で適用されます。

$ sudo setfacl -d -m u:alice:rwx /var/data    # -d が default

この一行だけ付けておけば、その中で作られるすべてのファイルに alice の権限が自動で付いていきます。共有ディレクトリ運用の核心です。

sudo — 権限の委譲 #

root パスワードを共有せずに、特定のユーザーに特定のコマンドだけ root 権限で実行させるツール。RHEL 9 のデフォルトポリシーは:

%wheel  ALL=(ALL)       ALL

「wheel グループはどのホストからでもすべてのユーザーですべてのコマンドを実行できる」。usermod -aG wheel alice だけで alice が sudo できるようになります。

/etc/sudoers と /etc/sudoers.d/ #

/etc/sudoers を直接編集しないでください。visudo を使ってください。

$ sudo visudo                              # /etc/sudoers 自体
$ sudo visudo -f /etc/sudoers.d/mycompany  # 分離ファイル

visudo は保存直前に文法チェックをします。文法が壊れた状態で保存すると sudo 自体が壊れてシステム復旧が難しくなります。直接 vi /etc/sudoers は危険。

最近はほぼ /etc/sudoers.d/ に別ファイルとして分けます。パッケージ / 役割ごとに一ファイルずつ。

限定的 sudo #

運用では「このユーザーはこのコマンドだけ」のように絞ります。

deploy  ALL=(ALL) NOPASSWD: /bin/systemctl restart myapp, /bin/systemctl status myapp

• NOPASSWD: — このコマンドにはパスワードなしで (自動化用)
• 二つのコマンドだけ列挙 — それ以外は sudo 権限なし

自動デプロイツールがマシンに SSH 接続して sudo systemctl restart myapp だけ叩けば良いパターン。他のところに権限が漏れるのを防ぎます。

よく使う sudo コマンド #

$ sudo whoami                   # → root (一番速い sudo 動作確認)
$ sudo -i                       # root シェルに入る (`sudo su -` と似ている)
$ sudo -u alice cmd             # alice ユーザーで cmd を実行
$ sudo -l                       # 自分が使える sudo コマンド一覧
$ sudo -k                       # 認証キャッシュを即座に失効 (次の sudo でパスワード再要求)

wheel vs sudo グループ — 一部の他ディストリビューション (Ubuntu など) は sudo グループを使います。RHEL は伝統的に wheel。両グループとも同じ役割ですが名前が違います。Ubuntu から来た方が sudo グループを作っても RHEL では動きません — wheel で。

よく使うコマンド一表 #

よく出会う落とし穴 #

「-aG を忘れてグループを上書き」 #

$ sudo usermod -G devs curtis   # ← curtis が wheel グループから外れて sudo できなくなる!

必ず -aG (append)。引っかかったら root に戻って再度 usermod -aG wheel curtis。

「ディレクトリ権限が閉じているのに中のファイルが全部開いている」 #

権限構造ではディレクトリが優先。親ディレクトリに x がなければ 中のファイルはどう開いておいてもアクセス不可です。セキュリティ点検時はディレクトリ権限から見ます。

「chmod 777 で一旦開けて忘れる」 #

障害デバッグ中に chmod -R 777 /var/app でいったん開けて動作確認するパターン — 後で戻し忘れると SELinux/監査ポリシーに引っかかってもっと大事故。開けたら必ず戻し、運用は最初から正確な権限で。

「ssh 鍵の権限が緩すぎて拒否される」 #

~/.ssh             700
~/.ssh/authorized_keys   600
~/.ssh/id_rsa            600

これより緩いと SSH が鍵認証を拒否します。Ubuntu から RHEL に移ってきた方が一番よく出会う症状。

「ACL を付けたのに SELinux に止められる」 #

ACL を通っても RHEL の SELinux がもう一層チェックします。ACL は OK なのにアクセス拒否 (Permission denied) なら SELinux のラベル問題の可能性。中級 #1 SELinux で扱います。

まとめ #

この記事で押さえた絵:

• ユーザーは /etc/passwd (公開) + /etc/shadow (非公開) に住む。UID 1000+ が一般ユーザー。
• useradd -m -s /bin/bash -G wheel <u> が一番よく使う新規ユーザー作成パターン。wheel が sudo グループ。
• usermod -G ではなく -aG — 一度間違えると sudo 権限がまるごと消える。
• 権限ビット rwx — ディレクトリの x は進入 (= アクセス) の意味であるという落とし穴。
• chmod の 8 進数とシンボリックの二つの表記、chown/chgrp の -R は慎重に。
• 標準権限が足りないときは ACL — setfacl -m u:alice:rwx、default ACL で新規ファイルに自動適用。
• sudo は /etc/sudoers.d/ に分離、visudo でだけ編集。
• RHEL の sudo グループは wheel (Ubuntu の sudo グループとは違う)。

次 — ファイルシステム #

権限が刻まれる舞台のファイルシステム自体が次の記事のテーマです。ディスクがどのように mount されてツリーに入り、新しいディスクを追加するときに何を書くか。

#6 ファイルシステムの基本 — XFS、mount、/etc/fstab では RHEL 9 のデフォルトファイルシステム XFS の形 (ext4 との違い)、lsblk / df / du でのディスクの見方、新しいディスクを追加してパーティショニングし mkfs.xfs でフォーマットしてマウント までの一サイクル、/etc/fstab に永続登録 (UUID で安全に)、そして swap の運用までを押さえます。