Linuxマシン間でUID / GIDを同期することの利点は何ですか?


24

さまざまなLinuxマシン間でUID / GIDを同期する方法の詳細について説明する前に、実際にどのようなメリットがあるのか​​を知りたいのですが。

これにより、ファイルの同期が比較的簡単になります(所有権が「自然に」保持されるため)。ただし、これは、送信サービスに応じて別の方法で実現することもできます。

一貫性のあるUID / GIDの恩恵を受けるものは他にありますか?


4
uid / gidを変更するときは、アーカイブ(tarファイルなど)を更新し、uidname / groupnamesの代わりに数値idを使用するconfファイルも更新することを忘れないでください。
オリビエデュラック14年

回答:


31

技術的負債

以下の理由により、この問題を早期に解決して、技術的負債の蓄積を回避するはるかに簡単です。すでにこのような状況に陥っている場合でも、ビルドを継続させるよりも、近い将来に対処する方がおそらく良いでしょう。

ネットワーク化されたファイルシステム

この質問は、ローカルファイルシステムを持つマシン間でファイルを転送する狭い範囲に焦点を当てているようです。これにより、マシン固有の所有権状態が可能になります。

ネットワーク化されたファイルシステムの考慮事項は、UID / GIDマッピングの同期を維持しようとする場合の最大のケースになります。確かに、あなたはこれらのホスト間で共有するネットワークファイルシステムがない可能性があり、今の ...しかし、どのような未来は?現在のホスト間、または将来作成されるホスト間でネットワーク化されたファイルシステムが導入されることは決してないということを正直に言えますか?そうでないと仮定することはあまり前向きな考えではありません。

それは仮定/homeの間で共有ネットワークファイルシステムであり、host1そしてhost2以下の実施例において。

  • 同意しない許可/home/user1各システムの異なるユーザーが所有しています。これにより、ユーザーがシステム間で一貫してホームディレクトリにアクセスしたり、ホームディレクトリを変更したりすることができなくなります。
  • chown wars:ユーザーが特定のシステムでホームディレクトリのアクセス許可を修正することを要求するチケットを送信することは非常に一般的です。でこの問題を修正するとhost2、の権限が壊れhost1ます。誰かが後退し、綱引きが行われていることに気付く前に、これらのチケットのいくつかが処理されることがあります。唯一の解決策は、一致しないIDマッピングを修正することです。につながる...
  • UID / GIDリバランス地獄:IDの修正の複雑さは、複数のマシンで単一のユーザーを修正するために必要なマッピングの数によって指数関数的に増加します。(user1IDはuser2であるuser2が、IDはuser17...であり、これはクラスター内の最初のシステムです)問題の修正を待つ時間が長くなるほど、これらのチェーンは複雑になり、複数のサーバー上のアプリケーションのダウンタイムが必要になることがよくあります物事を適切に同期させるために。
  • セキュリティの問題user2host2と同じUIDを持っているuser1host1、それらが書き込みできるように、/home/user1host2の知識がなくてuser1。これらの変更はhost1、の権限で評価されuser1ます。何が間違っている可能性がありますか?(あればuser1アプリのユーザーで、devに誰かがします、それは書き込み可能です発見します変更を行います。これは時間の実績のある事実です。)

他のシナリオもありますが、これらは最も一般的なシナリオの例にすぎません。

名前は常にオプションではありません

数値IDに対して記述されたスクリプトまたは構成ファイルは、環境内で本質的に移植不可能になります。ほとんどの人は絶対に必要でない限りこれらをハードコードしないので、一般に問題ではありません...しかし、時々あなたが働いているツールはあなたに問題の選択肢を与えないことがあります。これらのシナリオでは、n個の異なるバージョンのスクリプトまたは構成ファイルを維持する必要があります。

例:pam_succeed_ifあなたはのフィールドを使用することができますuseruidと、gid「グループ」オプションが著しく欠けています...。あなたが複数のシステムをグループベースのアクセス制限のいくつかのフォームを実装すると予想された位置に置かれた場合は、必要があると思いn個のPAMコンフィグの異なるバリエーションを。(または、衝突を回避する必要がある少なくとも1つのGID)

集中管理

natxoの答えはこれをかなりよくカバーしています。


ネットワーク化されたファイルシステムを使用すると、異なるuidの問題を解決できないと言うのは確かではありません。uidマップをサポートする少なくとも1つのファイルシステムを知っているので、異なるマシンでどのグループとユーザーが一致するかを指定できます。
バリティ14年

@Valityそれが一般的に利用可能なソリューションであったとしても、私はそれをスケーラブルなものと呼ぶことをstillします。
アンドリューB 14年

私は同意します、私はOPに不可能だと思わせたくありませんでした。最良の解決策はそれらを同期させることであるというあなたの提案に大いに同意します。
バリティ14年

ありがとう!残念ながら、「早い段階で」はなくなっています。一部のldap / kerberos構成は、ここで作業する場所に含めたいと思っていますが、今はそうではありません。他のいくつかの理由で、相互運用システムでのUID / GIDの使用に特に興味がありました。私が言ったように、ファイル転送は1つの問題であり(現在は「機能している」ステータスです)、それがUIDの影響を受ける他の要素(あなたが言ったように)があるかどうかを知りたい理由です。これらの「他のシナリオ」のキーワードをいくつか追加していただけますか?これは素晴らしい答えになります!
アレックス14年

@alexまあ、私はネットワーク化されたファイルシステムの問題に関して「他のシナリオ」を意味しました。どんなにゲームが遅れても、問題は未解決のままであるため、悪化し続けるだけです。提供した理由が適切でない場合、それらの「その他の理由」を提供することで質問をもう少し進めた方がおそらく役立つでしょう。これまでに提供された答えは、私の意見ではかなり良いものです。経営者を説得しようとしているなら、彼らに正しいことをさせる責任は私たちにありません。
アンドリューB 14年

18

特定のサイズに達すると(そして、常に思ったよりも早くなります)、すべてのホストでパスワードの変更またはアカウントの無効化がPITAであることに気付くでしょう。だからこそ、人々はopenldapや最近の優れたfreeipaのようなLDAPデータベース(またはNISですが、最近は安全ではない)を備えたシステムを使用しています。

すべてのアカウント/グループ情報を中央データベースで管理し、すべてのホストがその情報を共有します。そこからさらに多くのことを行うことができます:もちろん、ファイルのアクセス許可にユーザー情報を使用しますが、そこにもユーザーを作成する代わりに、LDAPバインディングを持つすべてのアプリケーションの仮想ユーザーを作成します(多くのWebアプリケーションが使用できますユーザーデータベースのldap)、中央のsudoルールデータベースの維持、autofs環境の配布、dnsゾーンの維持、...

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.