web-dev-qa-db-ja.com

Subversionのパスベースの承認でワイルドカードを使用できますか？

Subversion情報：Collabnet Subversion Edge 3.2.2 SVNバージョン：1.8.0 Apache HTTP Server 2.4.4 mod_authz_svnを使用し、LDAPなし

私がやろうとしているのは、Subversionプロジェクトへのアクセスをチームのすべての開発者に割り当てることですが、特定の開発者だけにアクセスを許可する必要がある特定のディレクトリがあります。このように数十のエントリを作成するのではなく、次のようにします。

@superdevs = trusteddev, projman
@devs = @specdevs, user1, user2, user3

[/]
* = rw

[MyProj:/]
~@devs = 

[MyProj:/trunk/AllDevs/SuperDevsOnly]
~@superdevs = 

[MyProj:/trunk/ManyOtherDirs/SuperDevsOnly]
~@superdevs =

# the list goes on and on...

制限されたパスごとにエントリを明示的に作成する代わりに、ファイルパターンを定義するようにパスベースの認証ファイルを構成することは可能ですか？サーバーでホストされているすべてのSVN操作のパフォーマンスに影響を与えるエントリが増えることがわかっているため、認証ファイルに200以上のエントリを追加しないようにしたいと考えています。これは、最終的なソリューションを構築するために必要な機密コードを保護するための多くの作業のようにも思えます。

TL; DR;制限する必要のある明示的なファイルまたはディレクトリごとにルールを定義する代わりに、Subversionのパスベースの認証ファイルを設定するときに一般的なファイルパターンを定義できますか？

もう1つ

私は外観に精通していますが、継続的インテグレーションシステムでそれらを機能させることができず、現時点では、更新や交換に「時間を無駄」にしたくない力があります。

svnsubversion-edgemod-authz-host
3
Bender the Greatest

ワイルドカードの問題はsvnでかなり前から議論されており、未解決のバグレポートがあります。

http://Subversion.tigris.org/issues/show_bug.cgi?id=2662

最後のコメント（2013年6月から）には、次のステートメントが含まれていました。

この機能はとにかく実装する価値があると結論付けました。この機能によってサーバーのパフォーマンスが低下する場合があり、サービス拒否攻撃にも使用される可能性があるという事実をユーザーに警告できます（この問題に関する上記のコメントですでに述べたように）。

事前コミットフックsvnperms.pyでは、ワイルドカードのサポートが制限されており、読み取り専用ではなく書き込み専用です。 https://stackoverflow.com/questions/916758/set-up-svnperms-pre-commit-hook ==

4
Ursula

今後のSubversion1.10リリースでは、パスベースの認証でワイルドカードのグロブがサポートされます： https://Subversion.Apache.org/docs/release-notes/1.10.html#authzperf

3
Markus Kuhn