ユーザ・グループ・権限を設計する

STEP 02 · グループを作る

設計はグループから始めます。「誰を入れるか」より先に「どんな役割があるか」を決めるのが順序です。

sudo groupadd labgroup
getent group labgroup

labgroup:x:1005:

labgroup:x:<GID>: の形なら成功です。GID の数字は環境によって変わります。末尾が空なのは、まだ誰も所属していないからです。

STEP 03 · ユーザを作ってグループに入れる

# ホームディレクトリ付き・ログインシェルは bash
sudo useradd -m -s /bin/bash labuser01

# labgroup に「追加」する（-a を忘れない）
sudo usermod -aG labgroup labuser01

id labuser01

uid=1005(labuser01) gid=1006(labuser01) groups=1006(labuser01),1005(labgroup)

読み方が 2 つあります。gid=1006(labuser01) がプライマリグループ（useradd が自動で作った同名のグループ）、groups= が所属する全グループです。ここに labgroup が入っていれば成功です。

パスワードは設定しません: labuser01 にはパスワードを与えないので、この時点でアカウントはロック状態です。つまりパスワードでは入れません。STEP ⑦ で鍵を配ることが、このユーザへの唯一のログイン手段になります。

STEP 04 · 共有ディレクトリを setgid つきで作る

sudo mkdir /srv/labshared

# ディレクトリのグループを labgroup にする
sudo chgrp labgroup /srv/labshared

# 2775 = setgid(2) + owner:rwx + group:rwx + others:r-x
sudo chmod 2775 /srv/labshared

ls -ld /srv/labshared

drwxrwsr-x 2 root labgroup 4096 7月 28 10:03 /srv/labshared

drwxrwsr-x の s が setgid の証拠です。ここが x のままなら、以降のグループ継承は起きません。先に進む前に s を目で確認してください。

STEP 05 · setgid が効いていることを確かめる

ファイルを 1 つ置いて、グループが引き継がれるかを見ます。

echo "root が作ったファイル" | sudo tee /srv/labshared/ops-file.txt
ls -l /srv/labshared/

合計 4
-rw-r--r-- 1 root labgroup 30 7月 28 10:03 ops-file.txt

注目すべきは 所有者は root なのに、グループは labgroup という点です。setgid が無ければグループも root になっていました。

setgid が制御するのは group だけ: 所有者（owner）は「作った人」のまま変わりません。setgid が引き継がせるのはグループだけです。owner・group・setgid はそれぞれ独立した仕組みなので、混ぜて覚えると後で混乱します。

STEP 06 · 壊す ── グループの書き込みを奪う

設計を意図的に壊します。labgroup のメンバーが書き込めない状態を作ります。

# グループの書き込み権限を外す
sudo chmod g-w /srv/labshared
ls -ld /srv/labshared

drwxr-sr-x 2 root labgroup 4096 7月 28 10:03 /srv/labshared

drwxrwsr-x だった w が消えて drwxr-sr-x になりました。変わったのは 1 文字だけです。この 1 文字が何を分けるのかを、次のステップで実際に体験します。

ここで ops のまま書き込みを試しても意味がありません: ops は sudo を持っているので、権限を外しても sudo を付ければ書けてしまいます。壊れたことを確認できるのは、権限を持たないユーザだけです。

STEP 07 · labuser01 でログインするための鍵を配る

labuser01 にはパスワードがないため、鍵認証だけがログイン手段です。鍵を作り、ops の権限で置きにいきます。

まず workstation01 で新しいターミナルを開いてください（learner01 への ops 接続とは別のものです）。

# 鍵ペアを作る（既にあればスキップ）
ls ~/.ssh/labuser01_ed25519 2>/dev/null && echo "鍵は既に存在します" || \
  ssh-keygen -t ed25519 -N '' -f ~/.ssh/labuser01_ed25519

# 公開鍵の中身を表示する（この 1 行をコピーする）
cat ~/.ssh/labuser01_ed25519.pub

ssh-ed25519 AAAA… ops@workstation01

この ssh-ed25519 … の 1 行をコピーします。次は learner01 の ops ターミナルに戻って、置きにいきます。

# .ssh ディレクトリを用意する
sudo -u labuser01 mkdir -p /home/labuser01/.ssh
sudo chmod 700 /home/labuser01/.ssh
sudo chown labuser01:labuser01 /home/labuser01/.ssh

次に公開鍵を書き込みます。下のコマンドの <ここに公開鍵を貼り付ける> の行を、さきほどコピーした 1 行に置き換えてから実行してください。

sudo -u labuser01 tee /home/labuser01/.ssh/authorized_keys << 'EOF'
<ここに公開鍵を貼り付ける>
EOF

sudo chmod 600 /home/labuser01/.ssh/authorized_keys
sudo chown labuser01:labuser01 /home/labuser01/.ssh/authorized_keys

# 配置を確認（sudo が要ることに注目）
sudo ls -la /home/labuser01/.ssh/

合計 12
drwx------ 2 labuser01 labuser01 4096 7月 28 10:03 .
drwxr-x--- 3 labuser01 labuser01 4096 7月 28 10:03 ..
-rw------- 1 labuser01 labuser01   99 7月 28 10:03 authorized_keys

sudo を付けずに ls すると失敗します（実測）: ls: '/home/labuser01/.ssh/' にアクセスできません: 許可がありません と出ます。これは失敗ではなく、他人の領域が覗けないという設計が効いている証拠です。ただし、止まっている場所は .ssh ではありません。

どこで止まっているのかは、経路を 1 階層ずつ表示する namei -l で切り分けられます。

namei -l /home/labuser01/.ssh

f: /home/labuser01/.ssh
drwxr-xr-x root      root      /
drwxr-xr-x root      root      home
drwxr-x--- labuser01 labuser01 labuser01
                               .ssh - 許可がありません

止まっているのは ホームディレクトリ /home/labuser01（drwxr-x--- ＝ 0750）です。useradd -m が作るホームは既定で others に権限がなく、ops は labuser01 グループに属していないため、ここで弾かれます。.ssh の 0700 はその先にあり、この確認では試されていません（.ssh を 0755 に緩めても ops からは見えないことを実測で確認しています）。

SSH 側にも鍵ファイルの置き方に対する検査があります（sshd の StrictModes）。ただし拒否の条件は「権限が緩いこと」ではなく、本人以外が書き換えられる状態になっていることです。

読み取りが緩いだけでは拒否されません。それでも 0700 / 0600 を使うのは、この条件を確実に満たし、かつ鍵を他人に読ませないためです。「拒否されないから緩くてよい」ではないことに注意してください。

STEP 08 · 別のユーザの目で「壊れた状態」を見る

この章の核心です。ops のターミナルはそのまま残して、workstation01 でもう 1 つターミナルを開きます。

# 作ったユーザとしてログインする（鍵認証）
ssh -i ~/.ssh/labuser01_ed25519 labuser01@learner01

# 自分が何者かを確認する
id

# 共有ディレクトリへの書き込みを試す
echo "labuser01 が書いたファイル" > /srv/labshared/labuser01-file.txt

uid=1005(labuser01) gid=1006(labuser01) groups=1006(labuser01),1005(labgroup)
bash: 行 1: /srv/labshared/labuser01-file.txt: 許可がありません

「許可がありません」が正解です。ここが重要なところで、id を見ると labuser01 はちゃんと labgroup に所属しています。グループには入っているのに書けない ── STEP ⑥ で外した w の 1 文字が、そのまま効いています。

ops で試しても代わりにはなりません（実測）: ops は labgroup に属していないので、壊す前（2775）の時点ですでに書けません。つまり ops の「許可がありません」は、STEP ⑥ で外した w とは無関係です（others として弾かれているだけ）。外した 1 文字がそのまま効いていることを確かめられるのは labuser01 だけです。「一般ユーザなら誰でもいい」ではなく、その権限の対象になっているユーザで検証してください。

この labuser01 のターミナルは閉じないでください。次のステップで、同じ場所にもう一度書き込みます。

STEP 09 · 戻す ── 直した瞬間に書けるようになるか

ops のターミナル（管理者役）に切り替えて、権限を戻します。

sudo chmod g+w /srv/labshared
ls -ld /srv/labshared

drwxrwsr-x 2 root labgroup 4096 7月 28 10:03 /srv/labshared

次に labuser01 のターミナルへ戻ります。ログインし直す必要はありません。

# さっきと同じコマンドをもう一度
echo "labuser01 が書いたファイル" > /srv/labshared/labuser01-file.txt
ls -l /srv/labshared/

合計 8
-rw-rw-r-- 1 labuser01 labgroup 35 7月 28 10:04 labuser01-file.txt
-rw-r--r-- 1 root      labgroup 30 7月 28 10:03 ops-file.txt

今度は書けました。しかも labuser01-file.txt のグループが labgroup になっています ── setgid が効いた結果です。作成者のプライマリグループ（labuser01）ではありません。

2 つのファイルでモードが違う理由: labuser01-file.txt は -rw-rw-r--（664）ですが、STEP ⑤ で root が作った ops-file.txt は -rw-r--r--（644）です。この差は umask から来ます（labuser01 は 0002、root は 0022）。umask は「新しく作るファイルから外す権限」の設定で、setgid とは別の仕組みです。umask を確かめたいときは、そのユーザのシェルで umask と実行してください。

ここが設計上の落とし穴です: グループが labgroup でも、644 のファイルには他のメンバーは書けません。実際 ops-file.txt は labgroup のものですが、labuser01 からは追記できません（試すなら echo x >> /srv/labshared/ops-file.txt）。setgid はグループを揃えるだけで、書けることまでは保証しません。環境の umask が 0022 なら、この STEP の出力も -rw-r--r-- になります ── それでも setgid は成功しています。見るべきはグループ名です。

再ログインが要らないのはなぜか: chmod によるパーミッションの変更は即座に反映されます。一方、usermod -aG によるグループ所属の変更は既存セッションには反映されません（ログインし直すか newgrp が必要）。同じ「権限まわり」でも挙動が違うので、区別して覚えてください。

確認できたら labuser01 のセッションを exit で終了します。ログインしたままだと次のクリーンアップが失敗します。

STEP 10 · 章末クリーンアップ

ops のターミナルで、作ったものをすべて撤去します。

# 共有ディレクトリごと削除
sudo rm -rf /srv/labshared

# ユーザを削除（-r でホームディレクトリも）
sudo userdel -r labuser01

# メールスプールの残骸を念のため削除
sudo rm -f /var/mail/labuser01

# グループを削除（ユーザを消した後で）
sudo groupdel labgroup

# 消えたことを確認
id labuser01 2>&1 || echo "labuser01 は削除されました"
getent group labgroup 2>&1 || echo "labgroup は削除されました"

userdel: labuser01 のメールスプール (/var/mail/labuser01) がありません
id: `labuser01': そのようなユーザは存在しません
labuser01 は削除されました
labgroup は削除されました

1 行目はエラーではありません。userdel -r はメールスプールも消そうとしますが、この環境ではメールを扱っていないため最初から存在しないだけです（userdel 自体は成功しています）。続く rm -f /var/mail/labuser01 も、-f があるので対象が無くても黙って終わります。

削除は作成と逆の順序です。ユーザを消してからグループを消します。理由は「グループを先に消すと拒否されるから」ではありません ── labgroup は labuser01 の補助グループなので（主グループは useradd が自動で作った同名の labuser01）、順序を逆にしても groupdel は成功してしまいます。成功してしまうからこそ順序が要るのであって、先にグループを消すと、どのグループに属していたか分からないユーザが残ります。片付けは「参照している側から先に消す」が原則です。

groupdel が拒否されるのはどんなときか: そのグループを主グループにしているユーザが居る場合です（例: labuser01 をユーザごと消す前に groupdel labuser01 を実行した場合）。補助グループは対象外なので、labgroup ではこの拒否は起きません。

最後に workstation01 のターミナルで、演習用の鍵を削除します。

rm -f ~/.ssh/labuser01_ed25519 ~/.ssh/labuser01_ed25519.pub
ls ~/.ssh/labuser01_ed25519* 2>&1 || echo "演習鍵 削除済み（クリーン）"

ls: cannot access '/home/ops/.ssh/labuser01_ed25519*': No such file or directory
演習鍵 削除済み（クリーン）