web-dev-qa-db-ja.com

Subversionとmod_dav_svn:なぜwww-dataをrootではなくファイルの所有者にするのですか?

Ubuntu 9.10サーバー上にApacheとmod_dav_svnを使用して専用のSubversionサーバーをセットアップしましたが、この時点ですべてが正常に機能しています。ただし、リポジトリディレクトリに適切なファイル権限を割り当てる場合、ほとんどのチュートリアルでは、次のようなことを行うように指示されていることに気付きました。

Sudo chown -R www-data:www-data /svn/myrepo # make www-data the owner of the repo so Apache
                                            # can write to it
Sudo chmod -R g+ws /svn/myrepo  # Give the www-data group write access as well, and enable
                                # setgid so that new directories have that group

今、私はそれを少し違ったやり方でしました。新しいSubversionグループを作成し、それをリポジトリの所有者にした後、自分自身とwww-dataをそのグループに追加しました。これは、この方法で/svn/myrepo/confの構成ファイルと/svn/myrepo/hooksのフックスクリプトを編集できるためです。 、また、ApacheとSubversionをもう少し分離します。他のチュートリアルでも同様のことを推奨しているのを見てきましたが、次のように指示します。

Sudo chwown -R www-data:Subversion /svn/myrepo
Sudo chmod -R g+ws /svn/myrepo

これらの同じチュートリアルは、SubversionとApacheを互いにほとんど分離するために、特にSubversionグループを作成していることを意味します。それでは、なぜそれらが向きを変えてwww-dataをファイルの所有者にするのでしょうか。 www-dataをリ​​ポジトリファイルの所有者にする正当な理由はありますか? rootを所有者にしないのはなぜですか?リポジトリの所有者がSubversionをApacheに「多すぎる」と不必要に結び付けているため、www-dataを維持しているようです。グループがまだrootである限り、所有者をSubversionではなくwww-dataにする正当な理由はありますか?

4
Mike Spross

通常、rootをリポジトリの所有者にすることは望ましくありません。これは、svnリポジトリにアクセスするためにApache(httpd)をrootとして実行する必要があることを意味します。これは、通常、セキュリティリスクと見なされます。

私の経験では、あなたは主にApacheを介してSubversionと対話します。そのため、Apache(www-data)をSubversionリポジトリの所有者にする方が簡単で自然なようです。 Webサイトとは別のディレクトリ構造にSubversionリポジトリを作成した場合、どのファイルが何に使用されるかについて混乱することはありません。たとえば、Webサイトには/ data/wwwがあり、svnリポジトリには/ data/svnがあります。

次に、リポジトリの構成ファイルとフックスクリプトを変更できるようにするには、自分をwww-dataグループのメンバーにして、次の手順を実行します。

Sudo chmod -R g+ws /svn/myrepo

あなたが上で述べたように、あなたは行ってもいいです。

Svnリポジトリの所有者をApacheユーザーから分離するメリットはありませんが、本当にそうすることを主張した場合は、Subversionグループに加えてSubversionユーザーを作成し、/ svn/myrepoの所有者をSubversionにすることができます。 :subversion。次に、自分自身とApacheをSubversionグループのメンバーにして、上記のようにディレクトリのアクセス許可を変更します。

4
Lloyd Meinholz

IIRC、Apacheは、「dav」、「db」、および「locks」ディレクトリへの書き込みアクセスのみを必要とします。ユーザーまたはグループの所有権によるものかどうかは関係ありません。ほとんどの場合、Apacheが「conf」および「hooks」への書き込みアクセス権を持つ理由はありません。

2
Gerald Combs