「/var/log/app/ のログを監査担当者にだけ読ませたい。でも root グループの設定は変えたくない」「同じグループなのに、Aさんには書き込みを許可して、Bさんには読み取りだけにしたい」
chmod や chown だけでは、こういった細かい運用要件に応えられないことがよくあります。グループを増やし続けると管理が煩雑になり、権限の意図が伝わりにくくなります。
この記事では、Linux の ACL(Access Control List: アクセス制御リスト)を使って、ユーザーやグループごとに個別のアクセス権限を設定する方法を解説します。setfacl・getfacl コマンドの基本操作から、グループ共有ディレクトリへの応用、デフォルト ACL による自動継承まで、現場ですぐ使えるレベルで説明します。

Linux ACL とは?なぜ重要か
ACL(Access Control List)は、標準的な Unix パーミッション(オーナー・グループ・その他の3者に権限を設定する仕組み)を拡張し、任意のユーザーやグループに個別のアクセス権を付与できる仕組みです。Linux カーネル 2.6 以降に標準搭載されており、ext4・XFS・Btrfs などの主要ファイルシステムで利用できます。
標準パーミッションでは対応できない代表的なケースを整理します。
・同じグループ内でユーザーごとに権限を変えたい: グループ全員に同じ権限しか設定できない
・既存グループを変えずに特定ユーザーだけアクセスを追加したい: グループを増やすほど管理が肥大化する
・新規作成ファイルに自動で権限を継承させたい: 毎回 chmod するのは漏れが出やすい
ACL を導入することで、これらの問題を解決でき、最小権限の原則(Principle of Least Privilege)をより細かく実現できます。
標準パーミッションの限界を理解する
例えば、次のような権限設計を標準パーミッションだけで実現しようとすると困難です。
# 要件: /opt/shared/data/ に対して # - alice はフル権限(rwx) # - bob はリードオンリー(r--) # - グループ staff は実行のみ(--x) # - その他は完全拒否 # 標準パーミッションでは alice と bob を個別に制御できない ls -ld /opt/shared/data/ # drwxr-x--- 2 alice staff 4096 Aug 30 09:00 /opt/shared/data/ # ↑ bob が staff グループに入っていれば r-x になってしまう # bob だけ r-- にする方法がない
ACL を使えば、この要件をグループ構成を変えずに実現できます。
ACL を使えるようにする準備
1. 必要なパッケージのインストール
ほとんどのディストリビューションでは `acl` パッケージが最初からインストールされています。入っていない場合は以下でインストールします。
# RHEL / AlmaLinux / Rocky Linux sudo dnf install acl # Ubuntu / Debian sudo apt install acl # インストール確認 which setfacl getfacl
2. ファイルシステムの ACL サポート確認
ext4 と XFS は ACL をデフォルトで有効にしています。古い環境では `tune2fs` で確認します。
# ext4 の ACL 設定確認(acl が含まれていれば有効) sudo tune2fs -l /dev/sda1 | grep "Default mount" # Default mount options: user_xattr acl # 現在のマウントオプションを確認 mount | grep "on / " # /dev/sda1 on / type ext4 (rw,relatime) # → defaults / relatime は acl を含む
setfacl コマンドの基本操作
1. 特定のユーザーに権限を設定する
書式: `setfacl -m u:ユーザー名:権限 対象パス`
# ユーザー alice にフル権限(rwx)を付与 sudo setfacl -m u:alice:rwx /opt/shared/data/ # ユーザー bob に読み取りのみ付与 sudo setfacl -m u:bob:r-- /opt/shared/data/ # 複数エントリをカンマ区切りでまとめて設定 sudo setfacl -m u:alice:rwx,u:bob:r-- /opt/shared/data/
2. 特定のグループに権限を設定する
書式: `setfacl -m g:グループ名:権限 対象パス`
# グループ auditors にログディレクトリへの読み取りを付与 sudo setfacl -m g:auditors:r-x /var/log/app/ # グループ developers に開発ディレクトリへのフルアクセスを付与 sudo setfacl -m g:developers:rwx /opt/project/src/
3. ACL を削除する
# 特定ユーザーの ACL エントリを削除 sudo setfacl -x u:bob /opt/shared/data/ # すべての ACL を削除して標準パーミッションに戻す sudo setfacl -b /opt/shared/data/ # デフォルト ACL のみ削除(通常の ACL は残す) sudo setfacl -k /opt/shared/data/
getfacl で ACL を確認する
設定した ACL は `getfacl` コマンドで確認します。
getfacl /opt/shared/data/
出力例:
# file: opt/shared/data/ # owner: root # group: staff user::rwx # オーナー(root)の権限 user:alice:rwx # ユーザー alice の ACL user:bob:r-- # ユーザー bob の ACL(読み取りのみ) group::r-x # グループ staff の標準権限 group:auditors:r-x # グループ auditors の ACL mask::rwx # 有効マスク(ACL の上限権限) other::--- # その他のユーザー
mask(マスク)の意味に注意してください。mask は「ACL エントリで実際に有効になる権限の上限」です。mask が `r–` になっていると、`user:alice:rwx` と設定しても実質 `r–` しか効きません。マスクを変更する場合は次のようにします。
# マスクを rwx に設定(ACL の上限を広げる) sudo setfacl -m m::rwx /opt/shared/data/
`ls -l` で ACL が設定されているパスを確認すると、パーミッション欄の末尾に `+` が表示されます。
ls -ld /opt/shared/data/ # drwxrwx---+ 2 root staff 4096 Aug 30 10:00 /opt/shared/data/ # ^ この + が ACL 設定済みを示す記号
デフォルト ACL(新規ファイルへの自動継承)
グループ共有ディレクトリでよく起きる問題が「新しいファイルを作ると権限がバラバラになる」ことです。デフォルト ACL を設定すれば、ディレクトリ内に作成されるファイルやサブディレクトリに ACL が自動で継承されます。
# -d オプションでデフォルト ACL を設定 sudo setfacl -d -m u:alice:rwx /opt/shared/data/ sudo setfacl -d -m g:auditors:r-x /opt/shared/data/ # 設定確認(default: で始まる行がデフォルト ACL) getfacl /opt/shared/data/
確認出力の例:
# ...(通常の ACL 行)... default:user::rwx default:user:alice:rwx default:group::r-x default:group:auditors:r-x default:mask::rwx default:other::---
デフォルト ACL はディレクトリにのみ設定でき、新たに作られたサブディレクトリはデフォルト ACL を自動で引き継ぎます。
中小企業でも今日からできること
シナリオ1: Web デプロイユーザーの書き込みを限定する
Web アプリケーションのデプロイを専用ユーザー `deploy` に任せ、Apache/Nginx の実行ユーザー `www-data` には読み取りのみ許可する構成です。
sudo setfacl -m u:deploy:rwx /var/www/html/ sudo setfacl -m u:www-data:r-x /var/www/html/ # 新規ファイルへも自動適用 sudo setfacl -d -m u:deploy:rwx /var/www/html/ sudo setfacl -d -m u:www-data:r-x /var/www/html/
シナリオ2: 監査グループがログを読み取れる設定
セキュリティ監査担当グループ `auditors` に、アプリログへの読み取りアクセスを付与します。root グループの設定は一切変更不要です。
# -R オプションで既存ファイルにも再帰的に適用 sudo setfacl -R -m g:auditors:r-x /var/log/app/ # 新規ファイルへも自動適用 sudo setfacl -d -m g:auditors:r-- /var/log/app/
シナリオ3: プロジェクトごとにアクセスを分離する
複数プロジェクトが同じサーバーに同居するとき、プロジェクト A のメンバーはプロジェクト B のディレクトリを見られないようにします。
# /opt/project-a/ はチーム A のみアクセス可 sudo chmod 700 /opt/project-a/ sudo setfacl -m g:team-a:rwx /opt/project-a/ sudo setfacl -d -m g:team-a:rwx /opt/project-a/ # /opt/project-b/ はチーム B のみアクセス可 sudo chmod 700 /opt/project-b/ sudo setfacl -m g:team-b:rwx /opt/project-b/ sudo setfacl -d -m g:team-b:rwx /opt/project-b/
Linux のユーザーアカウント管理の基礎(不要アカウントの削除・ログインシェル制限)については、Linuxのユーザーアカウントセキュリティ強化もあわせて確認することをおすすめします。
よくある誤解と注意点
「ACL を設定したのに書き込めない」
mask の設定を確認してください。`getfacl` の出力で `mask::r–` などになっていると、ACL で `rwx` を付与しても実際には制限されます。`setfacl -m m::rwx /対象パス` でマスクを広げてください。
「cp や rsync で ACL が引き継がれない」
バックアップやファイル移動時は、ACL を保持するオプションを明示します。
# cp で ACL を保持 cp --preserve=all -r /opt/project/ /backup/ # rsync で ACL を保持(-A オプション) rsync -aA /opt/project/ /backup/project/ # tar でバックアップ(--xattrs オプション) tar --xattrs -czf project-backup.tar.gz /opt/project/
「NFS 共有先でも ACL を使いたい」
NFSv4 は ACL をサポートしていますが、NFSv3 ではサポートが限定的です。クライアントとサーバーの両方で ACL サポートを確認し、事前に検証環境でテストしてから本番環境へ適用してください。
「ACL と SELinux は競合するか」
SELinux(Mandatory Access Control)と ACL(Discretionary Access Control)は別レイヤーのアクセス制御です。SELinux が先に評価され、許可された場合に ACL が評価されます。どちらかが拒否した操作は実行できません。ファイルシステムレベルのセキュリティ強化という観点では、Linuxマウントオプション(noexec・nosuid・nodev)と組み合わせると、より多層的な防御が実現できます。

本記事のまとめ
| 操作 | コマンド例 | 用途 |
|---|---|---|
| ユーザーへの ACL 設定 | setfacl -m u:alice:rwx /dir/ | 個別ユーザーへの権限付与 |
| グループへの ACL 設定 | setfacl -m g:auditors:r /dir/ | グループへの個別権限付与 |
| デフォルト ACL 設定 | setfacl -d -m u:alice:rwx /dir/ | 新規ファイルへの自動継承 |
| ACL の確認 | getfacl /dir/ | 設定内容の可視化・確認 |
| ACL の全削除 | setfacl -b /dir/ | 標準パーミッションに戻す |
| 再帰的に ACL 設定 | setfacl -R -m g:team:rwx /dir/ | 既存ファイル全体に一括適用 |
Linux ACL は、「chmod・chown では対応できない」という現場の課題を低コストで解決できる実用的なツールです。グループを際限なく増やすことなく、ユーザーやグループごとの細かい権限設計が可能になります。
デフォルト ACL を活用すれば、新規作成ファイルへの権限設定漏れも防止でき、運用の手間を大幅に削減できます。まずは検証環境で試し、設計を固めてから本番環境へ段階的に適用してください。
Linux サーバー全体のセキュリティ強化については、姉妹サイトLinuxMaster.JPでも詳しく解説しています。
PR
ファイルパーミッション・ACL・SELinux・ネットワークセキュリティまで、Linuxサーバー防御の全領域を体系的に解説した一冊。現場のエンジニアが「なぜこの設定が必要か」から学べる実践的な内容です。
