web-dev-qa-db-ja.com

非ルートを使用してgitリポジトリをWebルートにデプロイする

Gitを使用してサーバーにデプロイする本番Webサーバーのユーザーとアクセス許可を設定するための最良の方法は何ですか？

背景

Ubuntu 12.04を実行している場合、/var/wwwの下にwww-dataとしてファイルを提供するApacheがあります。また、rootusersディレクトリの下に裸のgitリポジトリがあり、受信後のフックで/var/www/example.comにチェックアウトしていました。

これは問題なく機能しましたが、本番サーバーであることを考慮して、セキュリティを強化し、rootユーザーからリポジトリを削除したいと思いました。そこで、gitユーザーを作成し、/home/gitの下にリポジトリを設定しました。しかし、あるユーザーがリポジトリを所有し、別のユーザーがWebルートを所有しているという事実について、アクセス許可の問題が発生しました。

私は多くのフォーラムやチュートリアルをオンラインで読みました。ほとんどの場合、rootユーザーを使用しているように見えますが、セキュリティの問題が悪化しているようです（リポジトリに対するwww-data読み取り権限の付与など）。これを行うには多くの方法があるので、私は実際の経験からの洞察を探しています。

注意として、受信後のフックはチェックアウト以上のことを行います。また、Composerの実行や、数分かかる可能性のあるその他のphpスクリプトの実行などのビルドプロセスも実行します。

私はいくつかの解決策を試しました：

Gitユーザーをwww-data groupに追加してから、フックの最後でWebルートをwww-dataに戻しました。これには2つの問題があります。まず、sudoersファイルを変更する必要があり、そこから得られる結果はヒットとミスです。次に、フックの実行中の数分間、チェックアウトされたファイルはwww-dataではなくgitによって所有されているため、サイトのユーザーは読み取りエラーを受け取る可能性があります。

ポストレシーブの内容を別のファイルに入れて、Sudoで実行してみました。繰り返しますが、これにはsudoersファイルを編集する必要があります。これにより、gitユーザーはパスワードなしでSudoを実行できます。

または、rootユーザーの下にリポジトリを残すことはそれほど悪いことではなく、私はこれをすべて無料で行っている可能性があります。

私が試したことのないより良い解決策はありますか？

apache-2.2ubuntupermissionsgitsudo
2
Matt R. Wilson

新しいグループを作成し、それにgitおよびwww-dataユーザーを追加します。次に、作成したグループをリポジトリファイルのgidとして常に使用するようにgitbareリポジトリを設定します。新しい裸の呼吸器では、このgit init --shared=groupのようにこれを行います。 （ Ref ）これにより、www-dataアカウントがリポジトリを読み取ることができます。

Sudoersを更新して、gitアカウントがパスワードなしでwww-dataとしてコマンドを実行できるようにします。

# file: /etc/sudoers.d/gitpush
# permissions should be 0440
# git user is allowed to basically do anything as the www-data user
git ALL=(www-data) NOPASSWD: ALL

次に、チェック/修正を実行するために必要なすべてのコマンドに対して、post-receiveスクリプトSudo -u www-dataを用意します。

5
Zoredache

このシナリオを処理するためのより良い方法があると思います。

まず、プレーンなgitから、 gitolite のようなロールベースのアクセス制御（RBAC）のようなものに切り替えます。

また、必要なワークフローと非常によく似たワークフローについて説明している this の記事を読むことをお勧めします。

要件のソリューションを実装するための手順は次のとおりです。

  1. gitoliteを使用してRSAキーを使用してRBACを付与します
  2. 上記のリンク先の記事で説明されているフックを構成して使用し、所有者、グループ、および権限に関する正確性を確保します。

私の意見では、多くの利点があります。

  1. 誰にもファイルへの直接アクセスを許可する必要はありません
  2. post-updateフックスクリプトから何でもトリガーできます
  3. 公開されたコンテンツとのすべてのやり取りはgitrepositoryを介して行われるため、監査は簡単なタスクになります（git logおよびgit blame）
  4. aCLやミキシンググループパーミッション（DAC）で遊ぶ必要はありません
  5. 強制アクセス制御（MAC）セキュリティを透過的に使用できます
0
dawud

標準のmod_phpでは、/ var/www/example.comはgitユーザーが所有でき、すべてのファイル/フォルダーはphpで書き込み可能である必要があり、www-dataが所有する必要があります（または666/777のアクセス許可が必要です）。この場合、1つの仮想ホストが他の仮想ホストファイルを書き込むことができます。

または：mod_phpを実行している場合は、たとえばmod_ruid2をApacheに追加してから、各仮想ホストを独自のuidで実行できます。この場合、どちらがgitユーザーになります。または、セットアップのようなfastcgiを好み、各仮想ホストが独自のphp-fpmプールを持っている場合は、php-fpm。このようにして、各仮想ホストは独自のファイルを書き込むことができますが、他の仮想ホストからのファイルを書き込むことはできません。

どちらの方法を好むかによります。

0
Sandor Marton