第6章：権限管理 - セキュリティの第一歩

6.0 前提（検証環境）

OS: Linux（systemd 前提。例: Ubuntu 22.04/24.04）
シェル: bash
権限: 章内で sudo を付けた操作は管理者権限が必要
ネットワーク: 追加パッケージ導入時のみインターネット接続が必要
任意ツール: ACL の例では acl パッケージ、演習 2 では gcc を使用

6.1 はじめに：なぜ権限管理が必要なのか

想像してください。あなたの家に100人が住んでいるとします。全員が家のすべての部屋に自由に出入りでき、誰の持ち物でも自由に使えるとしたら、どうなるでしょうか？

プライバシーは守られず、大切なものは壊され、混乱が生じるでしょう。

Linuxシステムも同様です。複数のユーザーとプロセスが同じシステムを共有する環境では、「誰が何をできるか」を明確に定義する必要があります。これが権限管理の本質です。

6.2 マルチユーザーシステムの必然性

なぜマルチユーザーなのか

歴史的背景：高価なコンピュータの共有

1970年代、コンピュータは非常に高価でした：

1台のメインフレーム：数億円
↓
複数の端末を接続
↓
多数のユーザーが同時利用

この環境では、以下が必須でした：

各ユーザーのファイルを保護
システムリソースの公平な配分
悪意あるユーザーからの防御

現代における意義

現在でもマルチユーザーの概念は重要です：

# 典型的なWebサーバーのユーザー
$ cat /etc/passwd | cut -d: -f1 | grep -E "www-data|mysql|postgres|nginx"
www-data    # Webサーバー用
mysql       # データベース用
postgres    # データベース用
nginx       # Webサーバー用

各サービスが独立したユーザーで動作することで：

サービス間の干渉を防ぐ
一つのサービスが侵害されても被害を限定
最小権限の原則を実現

ユーザーとグループの概念

ユーザー（User）

# ユーザー情報の確認
$ id
uid=1000(username) gid=1000(username) groups=1000(username),4(adm),24(cdrom),27(sudo)

# /etc/passwdの構造
username:x:1000:1000:User Name:/home/username:/bin/bash
#   │    │  │    │      │           │            │
#   │    │  │    │      │           │            └─ ログインシェル
#   │    │  │    │      │           └─ ホームディレクトリ
#   │    │  │    │      └─ コメント（フルネーム等）
#   │    │  │    └─ プライマリグループID
#   │    │  └─ ユーザーID（UID）
#   │    └─ パスワード（xは/etc/shadowを参照）
#   └─ ユーザー名

グループ（Group）

# グループ情報
$ cat /etc/group | grep developers
developers:x:1001:alice,bob,charlie
#     │    │  │      └─ グループメンバー
#     │    │  └─ グループID（GID）
#     │    └─ パスワード（通常は未使用）
#     └─ グループ名

# ユーザーをグループに追加
sudo usermod -aG developers alice

6.3 最小権限の原則とその実装

最小権限の原則とは

「各ユーザー・プロセスには、その作業を完了するために必要な最小限の権限のみを与える」

実例：Webサーバーの権限設計

# 悪い例：すべてをrootで実行
sudo nginx  # rootの全権限でWebサーバー起動

# 良い例：専用ユーザーで実行
# nginx.conf
user www-data;  # 限定的な権限のユーザー

# www-dataユーザーの権限
$ sudo -u www-data whoami
www-data

$ sudo -u www-data ls /root
ls: cannot open directory '/root': Permission denied

Linuxの権限モデル

基本的な権限（rwx）

$ ls -la
drwxr-xr-x  5 alice developers  4096 Mar 15 10:00 project/
-rw-r--r--  1 alice developers  1234 Mar 15 09:30 README.md
-rwxr-x---  1 alice developers  5678 Mar 15 09:45 script.sh
-rw-------  1 alice alice       9012 Mar 15 10:15 private.key

# 権限の意味
# rwx rwx rwx
# │││ │││ │││
# │││ │││ └└└─ その他（others）の権限
# │││ └└└───── グループ（group）の権限
# └└└───────── 所有者（user）の権限
#
# r = 読み取り（read）    = 4
# w = 書き込み（write）   = 2
# x = 実行（execute）     = 1

初学者向けの最小例：自分のホームディレクトリで試す

mkdir -p ~/permission-test/minimum
cd ~/permission-test/minimum

printf '%s\n' 'secret memo' > memo.txt
cat > hello.sh <<'EOF'
#!/usr/bin/env bash
echo "hello"
EOF

ls -l
chmod 600 memo.txt
chmod 755 hello.sh
ls -l
./hello.sh

この最小例では、memo.txt に 600 を設定して「所有者だけが読み書きできる状態」を確認し、hello.sh に 755 を設定して「スクリプトの起動には実行権限が必要である」ことを確認します。いずれも ~/permission-test 配下で完結するため、業務ファイルを壊さずに試せます。

ディレクトリに対する権限の意味

mkdir test_dir
chmod 755 test_dir  # rwxr-xr-x

# r（読み取り）：ディレクトリの内容をリストできる
# w（書き込み）：ファイルの作成・削除ができる
# x（実行）：ディレクトリに入れる（cd可能）

# 実験：xなしのディレクトリ
chmod 644 test_dir  # rw-r--r--
cd test_dir  # Permission denied
ls test_dir  # ファイル名は見えるが詳細は見えない

上記のコマンドは、権限の違いを体感するための「実験用」の例です。実際の業務ディレクトリで同様の chmod を行うと、思わぬアクセス障害につながる可能性があります。必ず自分のホームディレクトリ配下にテスト用ディレクトリ（例：~/permission-test）を作成し、その中でのみ試してください。

特殊な権限ビット

SetUID（Set User ID）

# passwdコマンドの例
$ ls -la /usr/bin/passwd
-rwsr-xr-x 1 root root 68208 Feb  6  2024 /usr/bin/passwd
#   └─ 's'がSetUIDビット

# 一般ユーザーでもroot権限で実行される
# これによりパスワード変更（/etc/shadow編集）が可能

SetGID（Set Group ID）

# 共有ディレクトリの設定
sudo install -d -m 2775 -o root -g developers /srv/project-share

# このディレクトリ内で作成されたファイルは
# 自動的にdevelopersグループに属する

Sticky Bit

# /tmpディレクトリの例
$ ls -ld /tmp
drwxrwxrwt 15 root root 4096 Mar 15 11:26 /tmp
#         └─ 't'がSticky bit

# 誰でも書き込めるが、自分のファイルしか削除できない

6.4 実践的な権限管理

ファイル権限の変更

chmod - 権限の変更

# 数値表記
chmod 755 script.sh   # rwxr-xr-x
chmod 644 config.txt  # rw-r--r--
chmod 600 private.key # rw-------

# シンボリック表記
chmod u+x script.sh     # 所有者に実行権限を追加
chmod g-w file.txt      # グループから書き込み権限を削除
chmod o=r file.txt      # その他には読み取りのみ
chmod a+r file.txt      # 全員に読み取り権限を追加

# 再帰的な変更（検証用ディレクトリで実施）
chmod -R u=rwX,go=rX ~/permission-test/web-root

本番ディレクトリに対して再帰的な chmod を実行する前に、対象パス・現在の権限・実行中サービスへの影響を確認してください。特に /var/www や /etc への一括変更は、意図しない停止や情報露出につながります。

chown - 所有者の変更

# 所有者のみ変更
sudo chown alice file.txt

# 所有者とグループを変更
sudo chown alice:developers file.txt

# 再帰的に変更
sudo chown -R www-data:www-data /var/www

# グループのみ変更
sudo chgrp developers file.txt

umask - デフォルト権限の設定

# 現在のumaskを確認
$ umask
0022

# umaskの仕組み
# ファイル作成時：666 - umask = 実際の権限
# ディレクトリ作成時：777 - umask = 実際の権限

# umask 022の場合
# ファイル：666 - 022 = 644 (rw-r--r--)
# ディレクトリ：777 - 022 = 755 (rwxr-xr-x)

# より制限的なumask
umask 077  # 所有者のみアクセス可能

ACL（Access Control List）- より細かい権限制御

# ACLの確認
getfacl file.txt

# 特定ユーザーに権限を追加
setfacl -m u:bob:rw file.txt

# 特定グループに権限を追加
setfacl -m g:managers:rwx project/

# デフォルトACL（新規ファイルに自動適用）
setfacl -d -m g:developers:rw project/

# ACLを削除
setfacl -x u:bob file.txt

# すべてのACLを削除
setfacl -b file.txt

Ubuntu 系では setfacl / getfacl が見つからない場合、sudo apt install acl で追加します。ファイルシステム側で ACL が無効な環境もあるため、検証前に mount 出力やディストリビューションの標準設定を確認してください。

6.5 セキュリティインシデントの防止

よくある権限設定ミス

1. 過度に緩い権限

# 危険：誰でも書き込める設定ファイル
sudo chmod 777 /etc/app/config.conf  # 絶対ダメ！

# 正しい設定
sudo chmod 644 /etc/app/config.conf  # rootのみ編集可能

2. 秘密鍵の権限

# SSHが拒否する緩い権限
chmod 644 ~/.ssh/id_rsa
# Permissions 0644 for 'id_rsa' are too open.

# 正しい権限
chmod 600 ~/.ssh/id_rsa

3. SetUIDの誤用

# 危険：シェルスクリプトにSetUID
chmod u+s script.sh  # セキュリティホール！

# SetUIDは慎重に、できれば使わない

多くの Linux カーネルでは、シェルスクリプトに対する SetUID は安全性の観点から無効化されています。それでも「危険な設計である」という理解は重要です。

権限昇格攻撃の防止

sudo設定のベストプラクティス

# /etc/sudoersの編集（必ずvisudoを使用）
sudo visudo

# 良い例：特定コマンドのみ許可
alice ALL=(ALL) /usr/bin/systemctl restart nginx
bob   ALL=(ALL) /usr/bin/apt-get update, /usr/bin/apt-get upgrade

# 悪い例：無制限のsudo
alice ALL=(ALL) NOPASSWD: ALL  # 危険！

# グループベースの設定
%admin ALL=(ALL) ALL
%developers ALL=(ALL) /usr/bin/docker

本番運用では /etc/sudoers を直接追記するより、/etc/sudoers.d/ に用途別の drop-in を作り、保存前に visudo -cf /etc/sudoers.d/<filename> で構文検証する方が安全です。新しい sudo ルールは別セッションで検証してから元の root シェルを閉じ、臨時ルールは作業後に削除してください。なお docker グループ付与は実質的に root 相当の権限委譲になるため、sudo 権限と同等の審査対象として扱う必要があります。

ファイル改竄の検出

# ファイルの整合性チェック
# 1. チェックサムの記録
sudo find /etc -type f -exec sha256sum {} \; | sudo tee /root/etc_checksums.txt >/dev/null

# 2. 定期的な確認
sudo sha256sum -c /root/etc_checksums.txt | grep -v "OK$"

# より高度なツール：AIDE
sudo apt install aide
sudo aideinit
sudo aide --check

実践的なセキュリティ対策

1. 最小インストールの原則

# 不要なパッケージの削除
sudo apt autoremove
sudo apt purge package-name

# 実行中のサービスを確認
systemctl list-units --type=service --state=running

2. ファイルシステムの保護

# /etc/fstabでの設定
# /tmpをnoexecでマウント
tmpfs /tmp tmpfs defaults,noexec,nosuid 0 0

# 読み取り専用マウント
/dev/sda2 /usr ext4 defaults,ro 0 0

3. 監査ログの活用

# auditdのインストールと設定
sudo apt install auditd

# 重要ファイルの監視設定
sudo auditctl -w /etc/passwd -p wa -k passwd_changes
sudo auditctl -w /etc/shadow -p wa -k shadow_changes
sudo auditctl -w /etc/sudoers -p wa -k sudoers_changes

# 監査ログの確認
sudo ausearch -k passwd_changes
sudo aureport --summary

4. ファイアウォール設定の実践

以下は検証用 VM や手元のラボ環境で試してください。遠隔接続中のサーバーでいきなり既定ポリシーを変更すると、自分の SSH セッションまで遮断するおそれがあります。少なくとも別の root セッション、またはコンソールアクセスを確保してから実行します。

# iptablesによる基本設定
# デフォルトポリシーを拒否に設定
sudo iptables -P INPUT DROP
sudo iptables -P FORWARD DROP
sudo iptables -P OUTPUT ACCEPT

# 必要なサービスのみ許可
sudo iptables -A INPUT -i lo -j ACCEPT                    # ローカルループバック
sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT  # 確立済み接続
sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT        # SSH
sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT        # HTTP
sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT       # HTTPS

# 設定を保存
sudo iptables-save | sudo tee /etc/iptables/rules.v4 >/dev/null

# ufw（簡易ファイアウォール）の使用
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 'Nginx Full'
sudo ufw enable
sudo ufw status verbose

5. SSH強化設定

SSH 設定は、現在の接続を切断すると復旧に時間がかかります。既存セッションを開いたまま、構文チェック成功後に再読み込みし、別端末から再接続できることを確認してから作業を終えてください。

# バックアップと drop-in ディレクトリの準備
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup.$(date +%Y%m%d-%H%M%S)
sudo install -d -m 755 /etc/ssh/sshd_config.d

# セキュリティ強化設定（Ubuntu 系の例）
sudo tee /etc/ssh/sshd_config.d/10-hardening.conf >/dev/null << 'EOF'
# セキュリティ強化設定
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
KbdInteractiveAuthentication no
MaxAuthTries 3
ClientAliveInterval 300
ClientAliveCountMax 2
EOF

# 設定の検証と適用
sudo sshd -t  # 設定ファイルの構文チェック
sudo systemctl reload ssh

6. システム監視とアラート

# fail2banのインストールと設定
sudo apt install fail2ban

# /etc/fail2ban/jail.local の設定例
sudo tee /etc/fail2ban/jail.local >/dev/null << 'EOF'
[DEFAULT]
bantime = 3600
findtime = 600
maxretry = 3
ignoreip = 127.0.0.1/8 192.168.1.0/24

[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3

[nginx-http-auth]
enabled = true
filter = nginx-http-auth
port = http,https
logpath = /var/log/nginx/error.log
EOF

sudo systemctl enable fail2ban
sudo systemctl start fail2ban

# 不正アクセス試行の確認
sudo fail2ban-client status
sudo fail2ban-client status sshd

# ファイルアクセスの監視
sudo auditctl -w /etc/passwd -p wa -k passwd_changes

# ログの確認
sudo aureport -f
sudo ausearch -k passwd_changes

fail2ban が参照するログパスはディストリビューションや SSH 実装で異なります。Ubuntu 系では /var/log/auth.log が一般的ですが、journald のみを使う環境では別設定が必要です。

6.6 演習：権限設定ミスによる脆弱性を体験

演習1：基本的な権限管理

# 準備：テスト環境の作成
mkdir ~/permission_test
cd ~/permission_test

# 3人のユーザーをシミュレート（実際にはファイルで代用）
echo "Alice's secret" > alice_secret.txt
echo "Bob's data" > bob_data.txt
echo "Shared info" > shared.txt

# 権限の設定
chmod 600 alice_secret.txt  # Aliceのみ
chmod 640 bob_data.txt      # Bobと同じグループ
chmod 644 shared.txt        # 全員読める

# 権限の確認
ls -la

# 他ユーザーとしてアクセスを試みる（エラーを確認）
sudo -u nobody cat alice_secret.txt

演習2：SetUIDの仕組みを観察する

# SetUID の仕組みを観察する最小プログラム
cat > inspect_euid.c << 'EOF'
#include <stdio.h>
#include <unistd.h>

int main(void) {
    printf("Real UID: %d\n", getuid());
    printf("Effective UID: %d\n", geteuid());
    return 0;
}
EOF

# コンパイルと権限設定
gcc inspect_euid.c -o inspect_euid
ls -l inspect_euid
chmod u+s inspect_euid
ls -l inspect_euid

# 実行して real/effective UID を観察
./inspect_euid

# 後片付け（重要）
rm inspect_euid inspect_euid.c

この演習では、所有者が自分自身のバイナリに SetUID を付けても、実効 UID は基本的に自分のままであることを確認します。root 所有バイナリに SetUID を付けた危険な検証は、業務端末や共用サーバーでは実施しないでください。

演習3：共有ディレクトリの設定

# 共有プロジェクトディレクトリの作成
sudo groupadd -f project_team
sudo install -d -m 3775 -o root -g project_team /tmp/shared_project

# 自分を補助グループに追加
sudo usermod -aG project_team "$USER"

# テスト（新しいグループを明示して実行）
sudo -u "$USER" -g project_team touch /tmp/shared_project/myfile.txt
ls -la /tmp/shared_project  # グループがproject_teamになっているか確認

# 別ユーザーでのテスト（sudoを使用）
sudo -u nobody touch /tmp/shared_project/test.txt  # 失敗するはず

演習4：ACLの活用

# ACL対応の確認
mount | grep acl

# テストファイルの作成
echo "Project data" > project.txt
chmod 600 project.txt  # 所有者のみ

# 特定ユーザーに読み取り権限を付与
# (実際にはwww-dataユーザーなどを使用)
setfacl -m u:www-data:r project.txt

# ACLの確認
getfacl project.txt

# 複数ユーザーへの権限設定
setfacl -m u:user1:rw,u:user2:r,g:developers:rw project.txt

# マスクの設定（最大権限の制限）
setfacl -m m::r project.txt

演習5：セキュリティ監査

# security_audit.sh - 簡易セキュリティ監査スクリプト
cat > security_audit.sh << 'EOF'
#!/bin/bash

echo "=== Security Audit Report ==="
echo "Date: $(date)"
echo

echo "1. World-writable files:"
find / -type f -perm -002 2>/dev/null | head -20

echo
echo "2. SetUID files:"
find / -type f -perm -4000 2>/dev/null | head -20

echo
echo "3. SetGID files:"
find / -type f -perm -2000 2>/dev/null | head -20

echo
echo "4. Files without owner:"
find / \( -nouser -o -nogroup \) 2>/dev/null | head -20

echo
echo "5. Suspicious permissions on important files:"
ls -la /etc/passwd /etc/shadow /etc/sudoers 2>/dev/null

echo
echo "6. Users with UID 0 (root privileges):"
awk -F: '$3 == 0 {print $1}' /etc/passwd

echo
echo "7. Sudo configuration:"
sudo grep -Ev '^(#|$)' /etc/sudoers
EOF

chmod +x security_audit.sh
# sudo ./security_audit.sh  # 実行には注意

6.7 ベストプラクティスとガイドライン

権限設定のチェックリスト

システムファイル

# 重要なシステムファイルの権限
/etc/passwd     # 644 (rw-r--r--) root:root
/etc/shadow     # 640 (rw-r-----) root:shadow
/etc/sudoers    # 440 (r--r-----) root:root
/etc/ssh/sshd_config # 644 (rw-r--r--) root:root

Webアプリケーション

# Webサーバーのドキュメントルート
/var/www/html/          # 755 www-data:www-data
/var/www/html/*.html    # 644 www-data:www-data
/var/www/html/upload/   # 775 www-data:www-data (書き込み可能)

# 設定ファイル
/etc/nginx/nginx.conf   # 644 root:root
/etc/nginx/sites-available/* # 644 root:root

ユーザーディレクトリ

# ホームディレクトリ
/home/username/         # 750 または 700
~/.ssh/                 # 700
~/.ssh/authorized_keys  # 600
~/.ssh/id_rsa          # 600
~/.ssh/id_rsa.pub      # 644

自動化スクリプト

#!/bin/bash
# fix_permissions.sh - 権限を修正するスクリプト

# SSHディレクトリの修正
fix_ssh_permissions() {
    local user=$1
    local home=$(getent passwd "$user" | cut -d: -f6)
    
    if [ -d "$home/.ssh" ]; then
        chmod 700 "$home/.ssh"
        chmod 600 "$home/.ssh/id_"* 2>/dev/null
        chmod 644 "$home/.ssh/"*.pub 2>/dev/null
        chmod 600 "$home/.ssh/authorized_keys" 2>/dev/null
        chown -R "$user:$user" "$home/.ssh"
    fi
}

# Webディレクトリの修正
fix_web_permissions() {
    find /var/www -type d -exec chmod 755 {} \;
    find /var/www -type f -exec chmod 644 {} \;
    chown -R www-data:www-data /var/www
}

# メイン処理
echo "Fixing permissions..."
for user in $(getent passwd | awk -F: '$3 >= 1000 {print $1}'); do
    fix_ssh_permissions "$user"
done

fix_web_permissions
echo "Done."

6.8 まとめ：セキュリティは設計から始まる

権限管理の本質

本章で学んだ権限管理は、セキュリティの基礎です：

最小権限の原則：必要最小限の権限のみを付与
職務の分離：異なる役割には異なるユーザー
多層防御：一つの対策に頼らない
監査と監視：設定を定期的に確認

権限管理は継続的なプロセス

セキュリティは一度設定したら終わりではありません：

不要なユーザーアカウントの削除
過度に緩い権限の修正
SetUID/SetGID ファイルの棚卸し
ログの監視と分析

次章への準備

これまでの章で、Linuxシステムの基本的な仕組みを理解しました。次章からは、これらのシステムがネットワークを通じてどのように連携するかを学びます。

TCP/IPスタックという、インターネットの基礎技術をLinuxがどのように実装し、管理しているか。その仕組みを理解することで、現代のネットワークシステムの本質が見えてきます。

章末演習問題

問題1：基本理解の確認

以下の文章の空欄を埋めてください。

Linuxの基本的な権限は、（　　　）、（　　　）、（　　　）の3つで、それぞれ数値で（　）、（　）、（　）と表現されます。
ファイルの所有者以外でも特定の権限で実行できるようにする特殊ビットを（　　　　）ビットといい、ディレクトリ内で作成されたファイルが自動的に特定のグループに属するようにするビットを（　　　　）ビットといいます。
umaskが022の場合、新規作成されるファイルの権限は（　　　）、ディレクトリの権限は（　　　）になります。

問題2：概念の理解

次の質問に答えてください。

「最小権限の原則」とは何か、なぜ重要なのか、具体例を挙げて説明してください。
SetUIDビットの仕組みと、それがセキュリティリスクになり得る理由を説明してください。
ACL（Access Control List）が従来のUNIX権限システムより優れている点を2つ挙げてください。

問題3：実践的な課題

以下のシナリオに対して、適切な権限設定を行うコマンドを記述してください。

Webサーバーのドキュメントルート（/var/www/html）を、www-dataユーザーが読み取り可能、管理者グループ（webadmin）が読み書き可能、その他のユーザーはアクセス不可にする。
共有ディレクトリ（/shared/project）を作成し、developersグループのメンバーが自由にファイルを作成・編集でき、作成されたファイルは自動的にdevelopersグループに属するようにする。
バックアップスクリプト（/usr/local/bin/backup.sh）を、backupユーザーのみが実行できるようにし、root権限が必要な処理は sudoers で個別コマンドに限定して実行できるようにする。

問題4：セキュリティ診断

以下のls -laの出力を見て、セキュリティ上の問題点を指摘し、修正方法を提案してください。

drwxrwxrwx  5 root     root      4096 Mar 15 10:00 /etc/app-config/
-rwsr-xr-x  1 root     root     12288 Mar 15 09:00 /usr/local/bin/user-script.sh
-rw-rw-rw-  1 webapp   webapp     512 Mar 15 11:00 /var/www/database.conf
-rw-r--r--  1 user     user      1024 Mar 15 12:00 ~/.ssh/id_rsa
drwx------  2 root     root      4096 Mar 15 13:00 /home/user/

問題5：権限管理スクリプト

以下の要件を満たすスクリプトを作成してください。

#!/bin/bash
# security_audit.sh - セキュリティ監査スクリプト

# 要件：
# 1. システム全体で777権限のファイル/ディレクトリを検出
# 2. SetUID/SetGIDビットが設定されているファイルをリスト
# 3. 所有者が存在しないファイルを検出
# 4. /etc, /usr/bin, /usr/sbinで最近変更されたファイルを表示
# 5. 結果をレポートファイルに出力

# ここにコードを記述

問題6：ACLの活用

次のシナリオをACLを使って実現する方法を示してください。

プロジェクトディレクトリ /project/webapp があり：

alice: 全権限
bob: 読み書き権限（実行不可）
charlie: 読み取りのみ
developersグループ: 読み書き権限
新規作成されるファイルにも自動的に同じACLを適用

問題7：トラブルシューティング

ユーザーから「ファイルが編集できない」という報告がありました。以下の情報から原因を特定し、解決策を提示してください。

$ id alice
uid=1001(alice) gid=1001(alice) groups=1001(alice),1002(developers)

$ ls -la /shared/important.txt
-rw-r----- 1 bob managers 1024 Mar 15 10:00 /shared/important.txt

$ getfacl /shared/important.txt
# file: /shared/important.txt
# owner: bob
# group: managers
user::rw-
group::r--
other::---

問題8：発展的課題

SELinuxやAppArmorなどのMAC（Mandatory Access Control）システムが、従来のDAC（Discretionary Access Control）に加えて必要な理由を説明してください。
コンテナ環境における権限管理の課題と、rootlessコンテナが解決する問題について論じてください。