Subversion を初めて設定する多くの管理者は、考えずにパスベースのアクセス制御を使用することを簡単に選択します。通常、管理者は チーム メンバー が どのプロジェクト で勤務 しているかを知っているので、 容易に どのチーム が どのディレクトリ にアクセスできるのか、どの ディレクトリにアクセスで きないのかを指示できます 。 これは自然なように思われ、 バージョン リポジトリへのアクセスを厳密に制御したいという管理者の要望を満たします。

この機能には通常、目に見えない（ および 目に見える） 代価 がかかることに注意してください。 目に見える場合、もっと多い 作業 で ユーザーがパスの読み取りおよび書き込み権限を持っていることを 確信 する必要 があります。 場合によって は 、非常に大きなパフォーマンス損失になる可能性があります。 目に見えない場合、あなたが創建した文化を考慮し、 ほとんどの場合、特定のユーザーは特定のディレクトリで 修正 を 提出 できないため、テクノロジーによって社会契約を強化する必要はありません。チームは時々自然にお互いに協力することができます。一部の人々は、 他人に 正常に 仕事できない ディレクトリ の内容を提出することにより、 他人を助け 、 あなたは コミュニケーションを期待しない障害 を設定 しました 。 あなたは プロジェクト開発、新 人 参加など 活動の一連ルールを設定する必要があり、 また、 他にいっぱい追加仕事がまだ多いです。

これはバージョン 制御 システムであり、 たとえ、誰か間違って提出すべきではない内容を コミットした場合でも、簡単にロールバック して変更 できます。 もし ユーザーが意図的に間違った場所にコミットする場合、これは社会的な問題であり、Subversion の外部で対処 すべきです。

そのため、ユーザーアクセスの制限を開始する前に、本当 に確実に ニーズがあるのか、それとも単に管理者に とって「 良い」のかを自問する必要があります。 サーバーの スピード に影響を 及ぼす 価値があるかどうかを判断 して 、わずかなリスクしかないこと 、 社会的な問題を解決するために技術的な手段に頼ることはよく ないこと を覚えておく必要があり ます。 [44]

思考の例として、Subversionプロジェクト自体には、ユーザーがそのディレクトリで 送信 できる設定がありますが、それ は社交方式 のみで 規定する と考えてください。 これは、特にオープンソースプロジェクトにとって、コミュニティの信頼の良いモデルです。もちろん、オーソドックスなパスベースのアクセス制御が必要になることもあります;たとえば、会社では、データの一部のみが機密情報であり、グループ の人 だけがアクセスできます。

あなたの サーバーがルールファイルを探 そうとするとき、 ルールを定義 しなければいけないです 。

ファイル にアクセス 構文は、svnserve.confおよび実行コンフィギュレーションファイルに非常に似ています。（＃）で始まる行は無視されます。単純な形式では、各セクションはリポジトリと内部のパスに名前を付け、ユーザー認証名 は 各セクションのオプション名です。各オプションの値は、リポジトリへのユーザーのアクセスレベルを示します：r（読み取り専用）またはrw（読み取り/書き込み） 、 ユーザーが言及しない場合、アクセスは許可されません。

具体的 のポイント ：このセクションの名前は[repos-name：path]または[path]の形式です 。もしSVNParentPathディレクティブを使用する場合、リポジトリの名前を指定することが重要です。 もしSVNPathディレクティブを使用する場合、 これらを漏れたら、[/some/dir] 部分は/some/dir のすべての リポジトリに マッチング します 。 したがって、セクションにパスを定義するだけでよいのです。 しょせん、 リポジトリは1つだけです。

[calc:/branches/calc/bug-142]

harry = rw

sally = r

最初の例では、ユーザーharryにはcalcリポジトリーの/ branch / calc / bug-142に対する完全な読み取りおよび書き込み権限がありますが、ユーザーsallyには読み取り権限のみがあり、他のユーザーはこのディレクトリにアクセスできません。

もちろん、アクセス制御は親ディレクトリから子ディレクトリに渡されます。つまり、Sally の子ディレクトリに対して異なるアクセスポリシーを指定できます ：

[calc:/branches/calc/bug-142]

harry = rw

sally = r

# give sally write access only to the 'testing' subdir

[calc:/branches/calc/bug-142/testing]

sally = rw

現在、Sallyはブランチのtestingサブディレクトリを読み取ることができますが、他の部分 は読む権利だけがあります。 同時に、Harryはまだブランチ全体に対する完全な読み取りおよび書き込み権限を持っています。

継承ルールを介して誰かのアクセスを 明確 に拒否することもできます。ユーザー名パラメー ターをnull に設定するだけで できます：

[calc:/branches/calc/bug-142]

harry = rw

sally = r

[calc:/branches/calc/bug-142/secret]

harry =

この例では、Harryはbug-142ディレクトリツリーに対する完全な読み取りおよび書き込み権限がありますが、secretサブディレクトリへのアクセス権は 一切 ありません。

一番 詳細なパスが マッチングされる することを覚えておく必要があります。サーバーは、最初に自分自身に マッチング するディレクトリを検索し、次に親ディレクトリ、次に親ディレクトリの親ディレクトリなどを検索します。この方法を続けると、より具体的なパス制御が継承されたすべてのアクセス制御をカバーします。

デフォルトでは、誰もリポジトリへのアクセス権を持っていないため、 もしあなたが 空のファイルで開始した ら 、すべてのユーザーにリポジトリルートへの読み取りアクセス権を付与する ことを希望することを意味します 。 「すべてのユーザー」を表すには：アスタリスク（*）を使用 して実現できます：

[/]

* = r

これは通常の設定です; バージョン リポジトリ名がセクション名に記載されていないことに注意してください。これにより、すべてのリポジトリがすべてのユーザーに読み され やすくなります。すべてのユーザーがリポジトリに対する読み取り権限を持っている場合、特定のユーザーに特定のサブディレクトリへのrw 権限 を付与できます。

ここで 詳しく アスタリスク（*）パラメーターを強調する必要があり：これは匿名ユーザーに マッチング する唯一のモードです。 もし 匿名ユーザーと認証ユーザーの混合アクセスを許可するようにLocationブロックを設定している場合、すべてのユーザーはApache匿名ユーザーとして アクセスを開始します 。 mod_authz_svn は *値 を アクセスパスの定義で検索されます;見つからない場合、Apacheは 真実 のクライアント認証を要求します。

アクセスファイルでは、Unixの/ etc / groupファイルのように、ユーザーのグループを定義することもできます ：

[groups]

calc-developers = harry, sally, joe

paint-developers = frank, sally, jane

everyone = harry, sally, joe, frank, sally, jane

グループには、ユーザーと同じアクセス権を付与 されます、 「at」（@）プレフィックスで区別され ます：

[calc:/projects/calc]

@calc-developers = rw

[paint:/projects/paint]

@paint-developers = rw

jane = r

グループ も 他のグループを含めること にも定義 できます。

[groups]

calc-developers = harry, sally, joe

paint-developers = frank, sally, jane

everyone = @calc-developers, @paint-developers

記事転載：

http://i18n-zh.googlecode.com/svn/www/svnbook-1.4/svn.serverconfig.pathbasedauthz.html