グループと権限：ネストされたUNIXグループ
私たちは（さまざまなクライアントから）ますます多くの外部開発者を獲得しており、サーバーにアドホックに追加して会社グループ（/ var/www /にすべてを所有している-私たちのワークスペース）を追加するよりも優れた戦略を必要とし始めています
そして、最適な解決策は、グループをネストできるようにすることです。したがって、@ ourcompanyができれば、すべてのメンバーがグループ@ourcompanyになります。
ourcompany：xxx：john、joe、bob guestcompany：xxx：guest1、guest2、@ ourcompany
しかし、それは不可能です。私はテンプレートシステムを持っているという考えをいじっています。そこでは、いくつかの簡単なsedを実行して、代わりに新しい/ etc/groupを作成します
（guestcompany：xxx：guest1、guest2、john、joe、bobが必要ない理由は、会社に人を追加または削除した場合、誰かが通過してすべてが更新されていることを確認する必要があるためです。オフエッジ）
次の論理的なステップはACLだと思いますが、私の過去の経験から、ACLは扱いがやや面倒なので、他に機能するソリューションを知っている人がいるかどうかを確認したかっただけです。
この方法をお勧めしているわけではありませんが、Active Directoryを使用して集中認証を管理し、同様にOpenを実装してLinuxマシンを認証することで、この問題を回避しました。 LWOは、ハッシュに基づいているため、すべてのマシンで一貫したUIDとGIDを提供します。これにより、NFSやrsyncなどの処理が非常に簡単になります。また、ネストされたグループをうまく解決します。
NISやLDAPなどの集中認証を使用していますか？
私は彼らにあなたのワークスペースへのアクセスを全く与えません。 gitまたはSubversionリポジトリにアクセスできるようにセットアップしてから、変更をシステムにプルしてデプロイします。テストサーバーをスクリプト化してリポジトリから定期的に更新することで、開発者の介入なしに変更をテストできます。
ACLが面倒になる可能性があることは知っています。明示的に要求しないときはいつでも、それらを避けます。しかし、あなたの状況では、彼らは最良の選択肢のようです。
もしあなたがすでにWindowsADを持っていて、この方法でアクセス許可を必要とする多くの潜在的なマシンを持っているなら、私はLWOをします。
LDAPのような集中型システムを使用する時が来たのではないでしょうか。私はFreeIPAを推測します：非常に柔軟で、素晴らしいUI、たくさんの機能。そしてそれはうまくいきます。
Linuxトラスティを使用することをお勧めします。それは昔からのNovellの管財人に触発されており、私が見た他の何よりも（私見）優れています。
あまり詳しく説明しなくても、維持する構成ファイルは1つです。 ACLなどを使用しようとすると、ファイルを個別にクエリする必要があるため、可視性はそれほど高くありません。
Linuxトラスティを使用すると、UnixパーミッションでANDを選択するか、それらをすべて一緒に無視することもできます。
唯一の欠点は、それがカーネルモジュールであるということです（それ自体は悪いことではありません）が、おそらく適切なサポート（トラスティドキュメントによる）でカーネルを再コンパイルする必要があります。これも問題ではありませんが、たとえばRed Hatからのサポートがある場合は、カーネルを再コンパイル/変更することはできません。