誰でもファイルを処理するための素晴らしいソリューションを持っています/var/wwwか？Name Based Virtual Hostsを実行しており、Apache 2ユーザーはwww-dataです。
通常のユーザーとルートが2人います。だから/var/www、ではなく、でファイルをいじるとき...
chown -R www-data:www-data
...常に、これを処理する良い方法は何ですか？
補足質問：それから、どのくらいハードコアで許可を取りますか？
これは、共同開発環境では常に問題でした。
回答:
@Zoredacheの答えを拡張しようとしていますが、私はこれを自分で試しています：
新しいグループ（www-pub）を作成し、そのグループにユーザーを追加します
groupadd www-pub
usermod -a -G www-pub usera ## -aを使用して既存のグループに追加する必要があります
usermod -a -G www-pub userb
groups usera ##ユーザーのグループを表示
/ var / wwwの下にあるすべての所有権をroot：www-pubに変更します
chown -R root:www-pub /var/www ## -R再帰的
すべてのフォルダーのアクセス許可を2775に変更します
chmod 2775 /var/www ## 2 =グループIDの設定、7 =所有者（root）のrwx、7 =グループ（www-pub）のrwx、5 = rxの世界（Apache www-dataユーザーを含む）
グループID（SETGID）ビット（2）を設定すると、グループ（www-pub）がそのフォルダーに作成されたすべての新しいファイル/フォルダーにコピーされます。他のオプションは、ユーザーIDをコピーするSETUID（4）と、所有者だけがファイルを削除できると思うSTICKY（1）です。
あります-R再帰的なオプションは、それは、ファイルとフォルダを区別しませんので、あなたがする必要が見つける使用しそうのように、：
find /var/www -type d -exec chmod 2775 {} +
すべてのファイルを0664に変更します
find /var/www -type f -exec chmod 0664 {} +
ユーザーのumaskを0002に変更します
umaskは、デフォルトのファイル作成許可を制御します。0002は、ファイルが664、ディレクトリが775であることを意味します。これを設定すると（私の場合umask、一番下の行を編集して/etc/profile）chmodそれらを必要とせずにグループ化します。
これをすべてテストするには、ファイルとディレクトリを作成し、で所有者、グループ、アクセス許可を確認しls -lます。
注：グループの変更を有効にするには、ログアウト/ログインする必要があります！
findこのためにコマンドを使用することをお勧めします。あなたは、ファイル/ディレクトリの多くを持っているとあなたが見つけるGNUを使用している場合、私は与えるだろう一つの小さなパフォーマンスの先端が使用することです+の代わりに\;、コマンドがするように、複数のファイルを操作するので、可能な限り多くのファイルでコマンドを実行する方が速いです」ファイルごとに1回ではなく、一度に。これにより、毎回コマンドを起動するのにかかる時間を節約できます。」また、バックスラッシュを必要としないため、入力が簡単です。
パーミッションをどのように設定したいかは完全にはわかりませんが、これが出発点になるかもしれません。おそらくもっと良い方法があるでしょう。両方のユーザーが/ var / www /の下にあるものを変更できるようにしたいと思っています。
これは、ユーザーのいずれかによって作成された新しいファイルはusername：www-pub 0664であり、作成されるディレクトリはusername：www-pub 2775である必要があることを意味します。ディレクトリのSETGIDビットは、作成されているすべてのファイルが、フォルダを所有するグループによって強制的に所有されるようにします。グループ内の誰でもファイルを編集できるように、書き込みビットが設定されていることを確認するには、umaskの調整が必要です。
筋金入りのように、私は許可を得ています。サイト/サーバーに完全に依存します。エディターが1〜2人だけで、それらがあまりにもひどく壊れないようにする必要がある場合は、簡単に進みます。ビジネスでもっと複雑なものが必要な場合は、もっと複雑なものをセットアップします。
POSIX ACL（アクセス制御リスト）が役立つと思うかもしれません。これらは、user：group：otherモデルと比較して、よりきめの細かい許可モデルを許可します。私はより明確になり、ファイルシステムのブランチの「デフォルト」動作を設定できるため、頭の中をまっすぐに保つのが簡単であることがわかりました。
たとえば、各ユーザーの権限を明示的に指定できます。
setfacl -Rm d:u:userA:rwX,u:userA:rwX /var/www
setfacl -Rm d:u:userB:rwX,u:userB:rwX /var/www
または、いくつかの共有グループに基づいてそれを行うことができます。
setfacl -Rm d:g:groupA:rwX,u:groupA:rwX /var/www
そして、あなたはApacheユーザーを読み取り専用にしたいかもしれません
setfacl -Rm d:u:www-data:rX,u:www-data:rX /var/www
マニュアルページ：
www-dataたとえば）をサイト全体に対して読み取り専用に変更することに関するメモ（setfaclまたはchmod-またはその両方を使用）->これは明らかにすべての書き込みをブロックします（ブラウザー側からのプラグイン/モジュールのアップロード/更新たとえば、ほとんどのCMS）。人気のあるものの多くは、グループレベルではなく、ユーザーのパーマレベルでのみ書き込みアクセスをテストしていると思います。引き続き更新できますが、更新は手動で適用し、書き込みフォルダー（logs / temp / uploads / etc）のカスタム権限を適用する必要があります。サイトが動作する場合、読み取り専用は優れたセキュリティです。
この質問は再び尋ねられ、メタで説明したように、現在のベストプラクティスは、2009年にこれが尋ねられたときよりも優れたアプローチを提供します。この答えは、共同のWeb開発環境を安全に扱うためのいくつかの現在のソリューションを提供しようとします。
安全なWebサーバーと共同開発には、ファイルのアクセス許可だけではありません。
すべてのサイトに個別のユーザーがいる、つまりを使用してすべてのサイトにサービスを提供しないでくださいwww-data。現在、Apacheは静的なコンテンツファイルのみを提供することはほとんどありませんが、動的な Webサイトを実行しているため、これは重要です。PHPが最も一般的なサーバーサイト言語であるため、この答えはPHPに集中していますが、他の言語にも同じ原則が適用されます。
単一のサイトでセキュリティの問題がある場合、同じユーザーとして実行されているすべてのサイトに広がる可能性があります。攻撃者は、データベースログイン情報など、ユーザーに表示されるすべてのものを表示し、ユーザーが書き込み権限を持つすべてのサイトを変更できます。
使用するSSHファイル転送プロトコル（SFTP）を。パスワードとコンテンツの両方をプレーンテキストで送信するため、FTPの使用はセキュリティのために放棄する必要がありますが、安全な代替SFTPには、共同Web開発のための完璧なソリューションである機能もあります。
サイトとサイトごとに1人のユーザーを分離したら、Web開発者にアクセス権を与える必要があります。これらのサイトユーザーにパスワードを提供するのではなく、または最初に提案された個人ユーザーアカウントを使用してサイトファイルにアクセスするのではなく、ログインにSSHキーを使用できます。
すべての開発者はキーペアを生成し、秘密キーを秘密にできます。次に、~/.ssh/authorized_keys開発者が作業しているすべてのWebサイトユーザーアカウントのファイルに公開キーが追加されます。これには、パスワードとログインを管理するための多くの利点があります。
すべての開発者は、サイトごとのユーザー配置に関連するすべてのパスワードを覚えたり保存したりする負担なしに、任意の数のWebサイトにアクセスできます。
退職するたびにパスワードを変更および共有する必要はありません。
非常に強力なパスワードを使用するか、パスワードベースのログインを完全に無効にすることができます。
PHP-FPMを使用します。これは、ユーザーとしてPHPを実行するための現在のアプローチです。ユーザーごとに新しいプールを作成します。つまり、サイトごとに1つのプールを作成します。これは、1つのサイトが消費できるリソースの量も指定できるため、セキュリティとパフォーマンスの両方に最適です。
たとえば、NeverEndingSecurityのlinux上の別個のユーザー/ uidおよびグループでphp-fpmを実行するを参照してください。HowtoForgeのUbuntu 16.04でのApacheでのPHP-FPMの使用のようなチュートリアルがあります。これは、ユーザー分離によるセキュリティ強化のためにPHP-FPMを使用せず、サーバー全体で単一のFPMソケットを使用するようにガイドします。