アクセス制御リスト (ACL)

アクセス制御リスト (ACL)

DokuWiki は、ほとんどの Wiki と同様に、デフォルトでは非常にオープンです。誰でもページを作成、編集、および削除することができます。しかし、時には特定の、もしくはすべてのページへのアクセスを制限したほうがよいこともあるでしょう。アクセス制御リスト (ACL: Access Control Lists) が役に立つのはこのような時です。このページでは、DokuWiki において ACL がどのように動作するのか、また、ACL をどのように設定するのかについて、概要を説明します。

:!: 警告: DokuWiki の ACL 機能はかなりの期間 DokuWiki の一部に含められており、非常に安定しているものと考えられます。しかし、もし権限の無いユーザーがあなたの Wiki 上の情報にアクセスするリスクを心配されているのであれば、そのような情報はインターネットからアクセスできる場所に置かないほうが良いでしょう。

設定と準備

ACL はインストーラー上で有効化することができ、そこで ACL の初期設定も行われます。手作業で ACL を有効化するには、設定項目: useacl を有効にした後、設定ファイルのサンプルである conf/acl.auth.php.dist と conf/users.auth.php.dist を、それぞれ conf/acl.auth.php と conf/users.auth.php としてコピーしてください。

アクセス制限

アクセス制限はページと名前空間に結びつけて設定することができます。「権限なし」、「読取」、「編集」、「作成」、「アップロード」、「削除」、そして「管理」という 7 つの権限が用意されています。権限は、一番下位が読取権限、一番上位が削除権限であり、上位の権限は下位の権限を含みます。なお、作成権限、アップロード権限、削除権限を設定できるのは名前空間だけであることに注意してください。

名前空間に設定されたルールは、ページ用の名前空間と同様にメディア用の名前空間にも適用されます。

DokuWiki がユーザーに対してどの権限を与えるかをチェックする際は、ユーザー名もしくはそのユーザーが所属するグループにマッチするすべてのルールが使用されます。ユーザーの権限を規定するルールは、以下の手順に従って選択されます。

アクセスした namespace:page (名前空間:ページ) に対してより近くでマッチするルールのほうが、より遠くでマッチするルールよりも優先して選択されます。私たちはこれを「明確なマッチング (Specific matching)」と呼んでいます。
同一のレベルで 1 つ以上のルールがマッチした場合は、その中で一番上位の権限を与えるルールが優先して選択されます。

ユーザーは、ユーザー管理画面 (もしくは認証バックエンド) で割り当てられたグループに所属しています。しかし、少し特殊な 2 つのグループがあります。

@ALL – 誰でも (たとえログインしていないユーザーでも) “ALL” グループのメンバーとなります。このグループは、(デフォルト設定として) すべてのユーザーへのアクセスを制限した後に、一部の限定されたユーザーに対して制限を緩和する用途で利用することができます。
@user – 自分で自分を登録したすべての登録ユーザーは、デフォルトで自動的に “user” というグループのメンバーとなります。このグループは、「ログイン中の」ユーザーに対して権限を与える際に使用してください。このグループの名前は、設定項目: defaultgroup で設定することができます。plain 認証バックエンドを利用している場合、”user” グループは仮想的な “ALL” グループとは異なり、ユーザーが自動的に追加される実在のグループとなります。もし異なる認証バックエンドを使用している場合は、その認証バックエンドによって提供されるグループを使用する必要があります。

グループは、内部的に、そしてアクセスコントロール管理画面上で、グループ名の前にアットマーク @ を置くことによって表現されます。

ACL の編集

新規ルールの追加もしくは既存ルールの変更を簡単に行うには、管理用メニューから利用可能なアクセスコントロール管理用プラグインを利用すべきです。このプラグインのインターフェースの詳しい説明については、プラグインのページにまとまっています。

基本的に、新規ルールを追加するには以下の 3 ステップを踏みます。

左上のツリー状のナビゲーションから、制限する名前空間もしくはページを選択します。
その ACL ルールを誰に適用するのかを選択します。
- ドロップダウンメニューから既知のユーザーもしくはグループを選択することによって
- または、「ユーザー:」もしくは「グループ:」を選択してから入力欄にユーザー名もしくはグループ名を入力することによって
適切な権限を設定します。

既存のルールは、アクセスコントロール管理画面の下のほうにある表の中で編集または削除することができます。

ACL の例

このセクションではアクセスコントロール管理画面で以下のように見える架空の構成例を使用して、アクセスルールがどのように動作するのかを説明します。

それでは、それぞれの行について見ていきましょう。

この行では、ルート名前空間において、誰に対してもページの編集と作成を許可する権限を設定します。ただし、アップロードは許可されません。
ユーザー bigboss に対してすべての権限が与えられます。
名前空間 devel へのアクセスが制限されます。誰も何もできない状態となります。
いや、実際には「誰も」ではないのです。– devel グループのメンバーに対しては、ここでアップロード権限を与えます。
そしてもちろんユーザー bigboss も許可します。さらに、彼はアップロードされたファイルを削除できる唯一のユーザーとなります。
そして marketing グループのメンバーは名前空間 devel 内のすべてを閲覧することができます。ただし閲覧のみです。
しかし devel グループのメンバーは彼らのボスにページ funstuff を見て欲しくありません。– ページ名に完全一致したルールは名前空間にマッチしたルールよりも優先されることを思い出してください。
そして最後に marketing グループのメンバーは、ページ devel:marketing の編集が許可されます。
それから名前空間 marketing に対する権限が設定されます。 marketing グループのすべてのメンバーはこの名前空間へのアップロードが許可されます。その他のユーザーは 1 行目のルールにマッチするため、なおページの作成と編集が可能です。ユーザー bigboss は 2 行目で設定された権限が継承されるため、ファイルのアップロードおよび削除が可能です。
最後の行では、スタートページを誰に対しても閲覧のみに制限しています。スーパーユーザーだけがいつでもこのページを編集できます。

「明確なマッチング (Specific matching)」への理解を深めるため、2 つ目の例も見てみましょう。

今回は、ページ private:bobspage へのアクセスを試みる場合に、異なるユーザーに対してどのルールがマッチするのかを見ていきます。

abby – 通常のユーザー
- 3 つのルール #1、#2、#4 がマッチします。
- ルール #4 が最も近い名前空間レベルでマッチするため、3 つのうちで一番高い優先順位となります。
- ユーザー abby の権限レベルは 0 となります。
bob – 通常のユーザー
- 4 つのルール #1、#2、#4、#6 がマッチします。
- ルール #6 が完全一致であるため、このルールが最優先されます。
- ユーザー bob の権限レベルは 16 となります。
ログインするのを忘れた bob が彼のページにアクセスを試みる場合
- 2 つのルール #1 と #4 がマッチします。
- ルール #4 がより近くでマッチするため、このルールが優先されます。
- ログインしていない状態の bob の権限レベルは 0 となります。
charlie – staff グループのメンバー
- 5 つのルール #1 ～ #5 がマッチします。
- 2 つのルール #4 と #5 が同じ名前空間レベルでマッチします。ルール #5 のほうが charlie に対してより上位の権限を与えるため、このルールが優先されます。
- charlie の権限レベルは 16 となります。

なお、ルール #5 はルール #3 と重複しているように見えますが、ルール #5 が無いと staff グループのメンバーはルール #4 により名前空間 private にアクセスできなくなってしまいますので注意してください。

参考情報

アクセス制限設定は、conf/acl.auth.php というファイルに保存されます。もし上記で説明したアクセスコントロール管理画面を利用したい場合は、このファイルが Web サーバソフトウェアから書き込み可能である必要があります。なお、このファイルを直接編集することは推奨されません。代わりに管理画面を使用するようにしてください。

空行とシェル形式のコメントは無視されます。それぞれの行は、空白文字で分離された以下の 3 つの部分で構成されます。

制限対象のリソース。ここにはページ名もしくは名前空間のどちらかが入ります。名前空間はアスタリスク * の付加によってマーク付けされます (下記の例を参照してください)。
ユーザー名もしくはグループ名。グループ名はアットマーク @ を前に置くことによってマーク付けされます。
権限レベル (下記を参照してください)。

整数値によって表される 7 つの権限レベルがあります。上位のレベルは下位のレベルを含みます。もしあなたが「編集」できるなら、「読取」もできるということです。しかしながら、255 の「管理」権限は conf/acl.auth.php ファイル内では使用できません。この権限は、設定項目: superuser とのマッチングにより、内部的にのみ使用されます。

名前	レベル	適用先	権限	DokuWiki の定数
権限なし	0	ページ、名前空間	権限無し – 完全に締め出します	AUTH_NONE
読取	1	ページ、名前空間	閲覧が可能	AUTH_READ
編集	2	ページ、名前空間	既存ページの編集が可能	AUTH_EDIT
作成	4	名前空間	新規ページの作成が可能	AUTH_CREATE
アップロード	8	名前空間	メディアファイルのアップロードが可能	AUTH_UPLOAD
削除	16	名前空間	メディアファイルの上書きと削除が可能	AUTH_DELETE
管理	255	管理用プラグイン	スーパーユーザー¹⁾は管理設定の変更が可能	AUTH_ADMIN

以下に、上述の最初の例に対応する設定例を示します。

*                  @ALL           4
*                  bigboss       16
devel:*            @ALL           0
devel:*            @devel         8
devel:*            bigboss       16
devel:*            @marketing     1
devel:funstuff     bigboss        0
devel:marketing    @marketing     2
marketing:*        @marketing     8
start              @ALL           1

なお、このファイル内でのルールの記述順序は全く重要でないことに注意してください。このファイルはまず全体が丸ごと解析され、その後、現在のページとユーザーの組み合わせによるルールの完全一致が探索されます。マッチするルールが見つかった場合、その後のマッチングは中止されます。もしマッチするルールが見つからない場合は、現在のページに対するグループの権限がチェックされます。それでも見つからない場合は、1 つ上、また 1 つ上と名前空間に対する権限が順番にチェックされます。

注意: 特殊な文字 (空白文字など) を使用したユーザー名もしくはグループ名を設定するには、それらを URL エスケープする必要があります。これは ASCII の最初の 128 文字の範囲 (0x00 ～ 0x7F) に含まれる特殊文字だけに適用されます。ACL ファイルでは UTF-8 エンコーディングを使用するため、マルチバイト文字であればそのまま記入することができます。

注意: 削除権限は、メディアファイルだけに影響を及ぼします。ページについては、少なくとも編集権限を持つユーザーであれば誰でも削除 (および復元) を行うことができます。アップロード権限を持つものの削除権限を持たないユーザーが、既存のメディアファイルを上書きすることはできません。

ユーザーワイルドカード

ACL の中でユーザーワイルドカードを使用することができます。これは多数の登録ユーザーを持つ Wiki において、各ユーザーに対してそのユーザーだけが編集権限を持つ個人的な名前空間を割り当てたいものの、各ユーザーごとに ACL を編集するのは避けたい場合に役立ちます。これを実現するため、%USER% がログイン中のユーザーの名前に置換されるようになっています。以下に示す例では、ログイン中のユーザーに対しては、ページ people:<ユーザー名> および名前空間 people:<ユーザー名> に対する削除権限が与えられます。

people:%USER%      %USER%    16
people:%USER%:*    %USER%    16

:!: 注意: 最近になって、ワイルドカードが @ から % に変更されました。古いバージョンの DokuWiki からアップグレードする場合は ACL の設定を適宜調整する必要があります。

¹⁾ 設定項目: superuser を参照してください。