SVNアクセス構成

Subversionリポジトリをホストするために使用されるFedora 17サーバーを継承しました。

非常に制限されたアクセスで構成されていると思いましたが、今日のいくつかのテストでは、アクセス制御がまったくない、ユニバーサルRW、おっと。

以下はシステムからの情報です。

うなめ-a

Linux 3.9.10-100.fc17.x86_64＃1 SMP日7月14日01:31:27 UTC 2013 x86_64 x86_64 x86_64 GNU / Linux

httpd -v

サーバーバージョン：Apache / 2.2.23（Unix）サーバー構築：2013年1月29日12:37:17

HTTPD構成ファイルの一部のスニペットを次に示します

<Location /svn/proj>
    DAV                             svn
    SVNParentPath                   /data/subversion/repos/proj
    SVNAutoversioning               On
    SSLRequireSSL
    SVNIndexXSLT                    "/repostyle-proj/view/repos.xsl"
    AuthType                        Basic
    AuthName                        "Project Authorization"
    PerlAuthenHandler               Apache::AuthPOP3
    PerlSetVar                      MailHost 127.0.0.1
    AuthBasicAuthoritative          On
    AuthzSVNAccessFile              /data/subversion/conf/perms_proj
    Require valid-user
    SVNAdvertiseV2Protocol Off

</Location>

これがSVN許可ファイルのスニペットです

[groups]
admins=admin-user
dummy-proj=<list of users>

[/]
@admins=rw

[dummy-proj:/]
@dummy-proj=rw

走るとき

svn co https：// FQDN / svn / proj / dummy-proj /

「admin-user」ではないユーザー、または「list of users」のユーザーとして認証している場合でも、リポジトリへのフルアクセスを取得します。

間違って設定したものは何ですか？

詳細-17年4月18日午前11:00に追加

「AuthzSVNAccessFile」行で指定されたファイルが読み取られていないか、完全に無視されているようです。

テストするために、ファイルの名前を変更し、問題なくリポジトリにアクセスしました。また、構成ファイルからその行を削除しましたが、まだリポジトリにアクセスできました。

AuthzSVNからデバッグを取得するにはどうすればよいですか？検証対象のユーザー名を確認し、ファイルが読み取られていることを確認します。

助けてくれてありがとう

ここから、svn://プロトコルとプロトコルでSVNのアクセス許可が異なることを学びましたhttp(s)://。ラブリー。

SVN HTTPパーミッションは、おそらくApache、Lighttpd、nginxなどのWebサーバーから取得されます。こちらをご覧ください：http : //svnbook.red-bean.com/nightly/en/svn.serverconfig.httpd.html

基本的に次のことが必要です。

• SVNのhttp（s）エンドポイントをホストするために使用しているWebサーバーを見つけます
• そのWebサーバーで使用されている認証メカニズムがあれば、それを決定する
• Windows / LDAP認証、PAM認証、基本認証、ダイジェスト認証などを実装して、認証がない場合はロックダウンし、ユーザー/グループごとにWebサーバー固有のアクセス許可を設定します。
• 混乱を最大限に防ぐために、（おそらく）svn co svn://HTTPの代わりにSVNネイティブプロトコルを使用する場合、完全なR / Wアクセス権がないことを確認してください。

ところで、これはあなたの質問とは関係ありませんが、Fedora 17は約4年間セキュリティまたはバグ修正の更新をサポートしていないため、実際にサポートされているOSにアップグレードする必要があります。RHEL / CentOS 7.xはFedora 19に基づいています（ハードウェアサポートと安定性を改善するための新しいパッチとバックポートが多数あります）。そのため、Fedora 17とCentOS / RHEL 7.xは類似しているため、比較的低くなります。サーバーから構成ファイルとデータを保存し、CentOS / RHEL 7.xとしてOSを再インストールする努力。そして、何年もの間（約2023年まで）再びセキュリティ更新プログラムの安定した流れを受け取り始めるでしょう。

Fedora 17のバグや壊れた機能に似た問題に遭遇した場合、どのような能力においてもあなたを支援しようという意欲はほとんどありません。それがアップグレードのもう1つの動機付けの理由です。CentOS 7.xで壊れたものを見つけて、適切なバグレポートを作成できる場合、実際にはRed Hatまたはコミュニティの貢献者によって修正される可能性があり、安定した更新としてパッチをダウンロードできます。特にこのサーバーの正しい機能に依存している会社がある場合、サポートされているOSとサポートされていないOSの実行には大きな違いがあります。このサーバーに基づいて重要な作業を行う人々がいる場合、あなたは火で遊んでいます。