解決策 1:
さらに調査した結果、www フォルダをそのようにセットアップすることが、これに答える別の (おそらくより良い方法) ように思えます。
<オール>sudo usermod -a -G developer user1 (各ユーザーを開発者グループに追加)sudo chgrp -R developer /var/www/site.com/ 開発者がそこで作業できるようにsudo chmod -R 2774 /var/www/site.com/ 開発者のみがファイルを作成/編集できるようにする (他の/世界が読み取ることができる)sudo chgrp -R www-data /var/www/site.com/uploads www-data (apache/nginx) がアップロードを作成できるようにします。
git以降 どんなユーザーが呼び出しても実行され、ユーザーが「開発者」グループに属している限り、フォルダーの作成、PHP ファイルの編集、git リポジトリの管理を行うことができます。
注:ステップ (3) で:2774 の「2」は、ディレクトリの「グループ ID を設定する」ことを意味します。これにより、その中に作成された新しいファイルとサブディレクトリは、(ユーザーのプライマリ グループではなく) 親ディレクトリのグループ ID を継承します。
解決策 2:
それが「正しい」かどうかはわかりませんが、サーバーで行っていることは次のとおりです。
- /var/www には、各 Web サイトのフォルダーが含まれています。
- 各ウェブサイトには所有者が指定されており、この所有者がウェブサイトのディレクトリ内のすべてのファイルとフォルダの所有者として設定されています。
- ウェブサイトを管理するすべてのユーザーは、ウェブサイトのグループに入れられます。
- このグループは、ディレクトリ内のすべてのファイルとフォルダーのグループ所有者として設定されます。
- ウェブサーバー (つまり、PHP) によって書き込まれる必要があるファイルまたはフォルダーの所有者は、apache を実行するユーザーである www-data に変更されます。
内容を一覧表示できるように、ディレクトリで実行ビットを有効にする必要があることに注意してください。
解決策 3:
さらに調査を行った結果、git/svn TOOLS のようです ユーザーが使用しているものとして実行されるため、問題はありません。 (ただし、git/svn デーモンは別の問題です!) git で作成/クローンしたものはすべて自分の権限を持ち、git ツールは /usr/bin にリストされていました
Git パーミッションが解決されました。
ユーザー権限は、www ディレクトリへのアクセスが必要なすべてのユーザーを www-data に追加することで解決できるようです Apache (および nginx) が実行されるグループ。
つまり、答えは 1 つのようです この質問は次のようになります:
デフォルトでは /var/www root:root が所有しています そして誰もいない そこにファイルを追加または変更できます。
1) グループ所有者の変更
最初に、www ディレクトリ グループを「root」グループではなく「www-data」が所有するように変更する必要があります
sudo chgrp -R www-data /var/www
2) www-data にユーザーを追加
次に、現在のユーザー (およびその他のユーザー) を www-data グループに追加する必要があります
sudo usermod -a -G www-data demousername
3) CHMOD www ディレクトリ
パーミッションを変更して、所有者 (root) とグループ "www-data" 内のすべてのユーザーのみがファイルとディレクトリを rwx (読み取り/書き込み/実行) できるようにします (他の誰もアクセスできない ).
sudo chmod -R 2770 /var/www
これで、アクセス権を持つユーザー (つまり、「www-data」グループ内) によって作成されたすべてのファイルとディレクトリは、apache と php によって読み取り/書き込み可能になります。
これは正しいです？ PHP/Ruby が作成するファイルについてはどうですか? www-data ユーザーはそれらにアクセスできますか?
解決策 4:
固定性は権限の継承ではありません。ディレクトリの固定性とは、ファイルの所有者またはディレクトリの所有者のみが、ディレクトリ内のそのファイルの名前を変更したり削除したりできることを意味します。したがって、/tmp/ では 1777 です。
古典的な Unix では、現在のプロセスの umask のみに基づいて、ファイル システムに基づく権限の継承はありません。 *BSD、またはディレクトリに setgid がある Linux では、新しく作成されたファイルのグループ フィールドは、親ディレクトリのグループ フィールドと同じに設定されます。それ以上のことについては、アクセス許可を継承できるディレクトリの「デフォルト」ACL を使用して、ACL を調べる必要があります。
以下を定義することから始める必要があります:* どのユーザーがシステムにアクセスできるか* 脅威モデルは何か
たとえば、複数の顧客と Web ホスティングを行っていて、お互いのファイルを見たくない場合は、それらすべてのユーザーに共通のグループ「webcusts」とディレクトリ モード 0705 を使用できます。ウェブサーバー プロセス (ではない "webcusts" では) その他のパーマが表示され、許可されます。顧客はお互いのファイルを見ることができず、ユーザーは自分のファイルをいじることができます。ただし、これは、CGI または PHP を許可した時点で、持っている プロセスが特定のユーザーとして実行されることを確認します (説明責任のために、1 つのホストで複数のユーザーがいる場合はとにかく良い方法です)。そうしないと、顧客が CGI を使用して互いのファイルをいじることができます。
ただし、Web サイトの実行時ユーザーが Web サイトの所有者と同じである場合、スクリプトにセキュリティ ホールが存在する場合に、悪用者からコンテンツを保護できないという問題があります。静的コンテンツの所有者とは別のランタイム ユーザーを持つことができ、他のユーザーとのやり取りについてあまり心配する必要がないように、専用ホストが勝つ場所です。
解決策 5:
これを行う最善の方法は、Posix ACL を使用することだと確信しています。それらは快適に作業でき、必要なすべての機能を提供します。
http://en.wikipedia.org/wiki/Access_control_list#Filesystem_ACL