Ubuntu VMで学ぶ「任意アクセス制御：DAC」
- 6月21日
- 読了時間: 5分
chmodだけで終わらせない、DACとACLの実践的な使い分け
Linux を触っていると、最初に覚えるアクセス制御はたいてい chmod と chown です。実際、それだけでもかなり多くのことはできます。ですが、少し運用らしいことを始めると、すぐに足りなくなります。
たとえば、あるディレクトリは基本的に開発者グループだけが触れるようにしたい。ただし監査担当の1人だけは読み取りだけ許可したい。こうした要件は珍しくありません。むしろ日常的です。
この種の制御を理解するうえで、最初に押さえるべきなのが任意アクセス制御（DAC: Discretionary Access Control）です。Linux の通常の所有者・グループ・その他の権限は、まさにこの DAC にあたります。さらに POSIX ACL も、この DAC を実務向けに拡張した仕組みです。
この記事では、Ubuntu VM 上で DAC を実際に触りながら、chmod の基本だけでなく、ACL を含めてどう使い分けるかまで見ていきます。
まずは検証用ユーザーを作る
最初に、動作確認用のユーザーを2人作っておきます。
sudo useradd -m alice
sudo useradd -m bob
sudo passwd alice
sudo passwd bob次に、作業用ディレクトリを1つ用意します。
sudo mkdir -p /srv/project
sudo chown alice:alice /srv/project
sudo chmod 700 /srv/projectここでの意味は単純です。所有者は alice、アクセス権は所有者だけに絞っています。
この状態で確認します。
sudo -u alice ls /srv/project
sudo -u bob ls /srv/projectalice は見えますが、bob は拒否されるはずです。これが Linux の最も基本的な DAC です。「誰の所有物か」と「その所有者が誰にどこまで許すか」で制御しています。
chmod と chown の世界は分かりやすいが、すぐに窮屈になる
このモデルはシンプルで強力です。ただし、実務で少し複雑な要件が入ると、途端に運用設計が窮屈になります。
たとえば次のようなケースです。
alice が所有者
開発グループ全体には読み書きを許可したい
ただし bob にだけ読み取りだけ許可したい
それ以外のユーザーには見せたくない
UNIX 権限だけでは、所有者・グループ・その他の3枠しかありません。つまり「特定の1人だけ例外的に許可する」という表現が苦手です。
ここで ACL を使います。
ACL を使うと“例外”を素直に書ける
Ubuntu で ACL を扱うには、まず acl パッケージを入れます。
sudo apt update
sudo apt install -y acl現在の権限を確認します。
getfacl /srv/project次に、bob にだけ読み取りと実行を付けます。
sudo setfacl -m u:bob:rx /srv/project
getfacl /srv/projectこの状態で試すと、bob はディレクトリ一覧の取得はできます。
sudo -u bob ls /srv/projectただし、書き込みはできません。
sudo -u bob touch /srv/project/test.txtここで大事なのは、所有者やグループの大枠を崩さずに、例外だけを足せることです。これが ACL の価値です。
デフォルトACLを入れると、新規作成物にも方針を反映できる
共有ディレクトリを運用していると、さらに欲しくなるのが継承です。つまり、今あるディレクトリだけでなく、今後その配下に作られるファイルやディレクトリにも一定の権限方針を持たせたい、という話です。
その場合は default ACL を使います。
sudo setfacl -m d:u:bob:rx /srv/project
getfacl /srv/projectこれで、以後 /srv/project 配下に新しく作られるオブジェクトにも、bob 向けのデフォルト権限が引き継がれます。
共有フォルダ運用では、ここを使えるかどうかで管理のしやすさがかなり変わります。
DAC の強みは“運用の軽さ”
DAC の強みは、軽くて、分かりやすくて、壊れにくいことです。所有者、グループ、その他、これだけでかなりの運用は回ります。
具体的には次のようなものです。
ローカルファイル共有
ログ閲覧権限の調整
バッチ用ディレクトリの所有整理
一時的な作業領域の分離
チーム単位のアクセス制御
この種の要件では、まず DAC やACLで十分対応可能です。大げさな制御を持ち込む前に、所有者とグループを丁寧に設計した方が安定します。
ただし、DAC だけでは止められないものもある
一方で、DAC には限界もあります。本質的には、所有者が決めるモデルだからです。
たとえば、あるアプリケーションを alice 権限で動かしているとします。そのアプリが侵害された場合、alice が読める範囲は基本的に読めてしまいます。つまり、DAC は「ユーザーに何を許すか」は整理できますが、そのユーザー権限で動くプロセスをさらに縛るのは得意ではありません。そこから先は、強制アクセス制御の領域です。
実務での位置づけ
実務では、DAC は今でも第一選択です。特に Ubuntu サーバーや小中規模の Linux 環境では、まず DAC を正しく設計することが土台になります。
ABAC や RBAC が注目される時代でも、ファイルシステム上の共有設計や基本権限の整理は DAC を避けて通れません。むしろ、DAC が雑なまま上位の制御モデルを積んでも、全体としては不安定になりやすいです。
まとめ
Ubuntu VM でアクセス制御を学ぶなら、最初にしっかり押さえるべきなのは DAC です。chmod と chown はその基本であり、ACL はその考え方を実務に耐える形へ広げた仕組みです。まず所有者、グループ、その他という UNIX 権限の土台を理解し、そのうえで ACL によって例外的な権限要件をどう表現するかを学ぶ。この流れが最も理解しやすいです。
重要なのは、ACL を特別に複雑な追加機能として構えることではありません。むしろ、標準的な UNIX 権限だけでは表現しきれない現場の要件を、無理なく記述するための延長線上の仕組みとして捉えたほうが腹落ちしやすいです。基本権限だけで運用を押し切ろうとすると、共有ディレクトリや一時的な共同作業の場面で、かえって管理が歪になります。Linux のアクセス制御で本質になるのは、派手な仕組みを次々に増やすことではなく、誰が所有し、どのグループに属し、どこに例外を置くかを整理して設計することです。
DAC は古典的な仕組みですが、だからこそ Linux の日常運用の中心にあります。まずはこの土台を正しく扱えるようになることが、MACやRBACといった他の仕組みと組み合わせた適切なアクセス制御を実現していくための出発点になります。
