1台のLinuxを複数ユーザーで安全に共有する運用｜権限とホーム分離の考え方【2026年版】

複数ユーザー共有でよく起きるトラブルの構造

1台のLinuxを複数人で使う状況は珍しくありません。開発チームが共有するビルドサーバー、部署で使う分析マシン、教育用の学習環境など、現場では今でも頻繁に登場するシナリオです。ところが「とりあえず全員にアカウントを配った」だけでは、想定外のトラブルが起きます。

典型的なのは「他ユーザーのホームを覗けてしまった」「共有ディレクトリに書き込めない」「sudo を使いすぎてシステムファイルを壊した」といったケースです。多くのディストリビューションでは、useradd で作成したホームディレクトリに対してパーミッション 755 が設定され、他のユーザーに読み取りが許可された状態になります。また sudo をまとめて付与すると権限の粒度が粗くなりすぎます。こうした「デフォルトのまま使うと穴が開く」ポイントを1つずつ埋めるのが、マルチユーザー共有運用の本質です。

ホームディレクトリの分離とユーザー作成の手順

まず各ユーザーのホームディレクトリを他者から遮断します。Ubuntu/Debian 系では adduser コマンドが対話式でアカウントとホームを同時に作成します。RHEL/AlmaLinux 系では useradd を明示的に使います。

# Ubuntu / Debian 系
sudo adduser alice

# RHEL 9 / AlmaLinux 9 系
sudo useradd -m -s /bin/bash alice
sudo passwd alice

作成後、ホームディレクトリのパーミッションを確認・修正します。

ls -ld /home/alice
# drwxr-xr-x と表示された場合は他ユーザーに読み取り権限がある状態

sudo chmod 700 /home/alice
# drwx------ に変更。本人のみ読み書き実行可能になる

Ubuntu 22.04 以降では /etc/login.defs に HOME_MODE 0700 を設定することで、以後作成するユーザーに自動的に 700 を適用できます。既存ユーザーには個別に chmod を実行してください。

umask の見直し

各ユーザーの .bashrc や /etc/profile で umask が設定されています。デフォルトは 0022（ファイル 644、ディレクトリ 755）で、グループメンバーへの書き込みは許可されません。後述する共有ディレクトリを活用するチームでは、0002（ファイル 664、ディレクトリ 775）への変更も選択肢になります。ただしシステム全体への適用は影響範囲が広いため、対象ユーザーの .bashrc 内で個別に設定するほうが安全です。

sudo 権限をユーザーごとに絞り込む

「全員を sudo グループに追加すれば楽」という判断が事故の温床になります。一般ユーザーが誤って sudo rm -rf /etc/ を実行できる状態は安全とは言えません。現行のベストプラクティスは、ユーザー（またはグループ）ごとに許可するコマンドを限定することです。

設定は /etc/sudoers.d/ 以下にファイルを追加する方法が推奨されます。visudo で直接 /etc/sudoers を編集するより、ファイル分割のほうが管理しやすく、削除による切り戻しも容易です。

# /etc/sudoers.d/alice を作成（パーミッションは自動で 440 になる）
sudo visudo -f /etc/sudoers.d/alice

ファイルの内容例として、alice に nginx の再起動のみを許可する場合は次のように記述します。

alice ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart nginx, /usr/bin/systemctl status nginx

グループ単位での管理はさらに整理しやすくなります。%ops ALL=(ALL) NOPASSWD: /usr/bin/systemctl のように記述すると、ops グループのメンバー全員に systemctl の実行を許可できます。ユーザーをグループへ追加・除外するだけで権限を制御できるため、人数が増えても運用コストが上がりにくいです。

共有ディレクトリをグループ権限で安全に管理する

チームで成果物を共有するディレクトリは、所有グループと setgid ビットを組み合わせて管理するのが定番の手法です。setgid を設定したディレクトリ内に作られるファイルやサブディレクトリは、自動的に親ディレクトリのグループを継承します。「誰が作ったファイルでもグループが一致している」状態を維持できるため、書き込み権限のトラブルが激減します。

# グループ作成とユーザー追加
sudo groupadd developers
sudo usermod -aG developers alice
sudo usermod -aG developers bob

# グループ追加は次回ログイン時に有効になる
# 即時反映するには newgrp developers または再ログインが必要

# 共有ディレクトリ作成と権限設定
sudo mkdir /srv/shared
sudo chown root:developers /srv/shared
sudo chmod 2775 /srv/shared
# 先頭の「2」が setgid。775 でグループ書き込みを許可

設定後、alice が /srv/shared 内にファイルを作成すると、所有グループが自動的に developers になります。bob からも書き込み可能な状態が継続されます。

ACL による細粒度の制御

グループ設計だけでは対応しきれない場合（特定のディレクトリへのアクセスを一部のユーザーだけに許可するなど）は、ACL（アクセス制御リスト）を使います。

# alice だけ /srv/project に読み書き実行を許可（グループ外）
sudo setfacl -m u:alice:rwx /srv/project

# 設定内容の確認
getfacl /srv/project

ACL は ext4 や xfs ではデフォルトで有効になっています。ただし ACL が多くなると管理の見通しが悪くなるため、基本はグループ権限で設計し、例外対応に ACL を使うという使い分けが現場では定着しています。

設定後の検証と切り戻し手順

設定が意図どおりに効いているかを確認するには、実際に対象ユーザーに切り替えて操作するのが確実です。su - でユーザーを切り替え、ホームや共有ディレクトリへのアクセスを試します。

# bob から alice のホームにアクセスできないことを確認
sudo su - bob
ls /home/alice
# Permission denied が返ればホーム分離は機能している

# 共有ディレクトリへの書き込みとグループ継承を確認
touch /srv/shared/test.txt
ls -l /srv/shared/test.txt
# グループが developers になっていることを確認

sudo の権限制限も同様に、許可したコマンドが実行でき、許可していないコマンドが拒否されることをユーザーとして実際に試します。

sudo su - alice
sudo systemctl restart nginx   # 許可済みなので成功するはず
sudo systemctl restart sshd    # sudoers 未定義なら拒否される

切り戻しが必要になった場合の手順は次のとおりです。

• ユーザーの削除：sudo userdel alice（ホームも削除するには -r オプションを追加。実行前にバックアップを忘れずに）
• グループからの除外：sudo gpasswd -d alice developers
• sudo 権限の取り消し：sudo rm /etc/sudoers.d/alice
• ACL の削除：sudo setfacl -x u:alice /srv/project

userdel -r はホームディレクトリごと削除するため、実行前に必ずデータを確認してください。誤削除後の復旧はファイルシステムレベルの作業になります。

2026年現行環境での注意点

systemd-homed の現状

systemd-homed はユーザーのホームディレクトリをポータブルに管理するしくみで、Fedora 39 以降ではオプションとして利用できます。ただし Ubuntu 24.04 LTS や RHEL 9 ではデフォルト採用に至っておらず、2026年時点においても多くの本番環境では従来の /home/username 方式が主流です。systemd-homed はラップトップ向けのユースケース（暗号化ホームのポータブル化）に強みがあり、固定サーバーでの共有運用では必ずしもメリットになりません。採用の際は既存のユーザー管理ツールとの互換性を事前に確認してください。

RHEL 9 / AlmaLinux 9 での変更点

RHEL 9 系では useradd のデフォルト値がいくつか変わっています。ホームディレクトリのパーミッションは従来の 755 から 700 がデフォルトになりました（/etc/login.defs の HOME_MODE が 0700 に設定）。また SHA-512 に代わって yescrypt がパスワードハッシュのデフォルトになっています。既存の構築スクリプトで useradd 後に chmod 700 を実行している場合、RHEL 9 環境では二重適用になりますが動作に問題はありません。スクリプトを棚卸しする際に整理しておくと保守性が上がります。

polkit と doas の動向

一部のディストリビューションでは sudo の代替として doas（OpenBSD 由来）の採用が進んでいます。設定ファイルがシンプルで攻撃面が小さいという点が評価されていますが、RHEL/Ubuntu の本番環境では sudo が事実上の標準です。systemd 連携の権限制御には polkit（旧 PolicyKit）が使われるケースも増えており、systemd サービスの権限管理では polkit のルールも把握しておくと対応範囲が広がります。

権限設計は一度決めたら終わりではなく、人員変更やプロジェクト変更に合わせて定期的な棚卸しが必要です。getent passwd でアカウント一覧を確認し、不要になったアカウントを速やかに無効化・削除する習慣が、長期的なセキュリティリスクの低減につながります。