私の研究室では、1人のグループがワークステーションで作業し、NFSを介して複数のドライブを共有しています。 NFSドライブの1つにある共有ソフトウェアを実行し、データがあるNFSドライブでソフトウェアを実行します。
現在の設定には同じユーザーアカウントを使用するすべてのエントリがあるので、oneすべてのホストで呼び出してみましょう。ラボメンバーはjoe@myhost独自のカスタム設定を持つデスクトップを持ってログインしますが、one科学データの実際の作業がグループに属するにはログインするusers必要がありますone。
環境の一部のユーザー固有のカスタマイズは、oneアカウントをホストごとに定義し、ホームディレクトリをローカルに設定することによって達成されますone@myhost:/home/one（歴史的理由の両方はUID 502とGID 100です）。したがって、各ユーザーのアカウントは、one共有プログラムへのパブリックポインタの横に特定の環境変数を設定できます。PATH
現在、研究室で議論が進行中であり、Unixのより良いアプローチは、さまざまなユーザーに対して別々のアカウントを持ち、グループを使用して個々のユーザーの現在の機能を複製することを示唆しています。
単一アカウントの次の欠点をリストしました。
- 複数のソフトウェアバージョンを管理することが困難です。
- ほとんど無意味な監査/ロギング、
- 誰でも他人のファイルやプログラムを削除できます。
- メンバーが研究室を離れるときにパスワードを変更することをお勧めします。
今、このネットワークはファイアウォールの背後にあり、科学的なデータにすぎず、侵入者にとっては意味がなく、経済的価値もありません。さらに、急速に進んでいる科学研究室では、安全を含むすべてが生産性よりも優先されます。データは頻繁にバックアップされるため、データやプログラムを削除する機能も大きな問題にはなりません。
アカウント方式は非常に便利で、数年前（2001年？）に確立されたため、one誰でもユーザーごとに1つのアカウントを使用するように説得するのが困難になりました。たぶん私は間違った主張を使っているかもしれませんが、上記のシナリオはアプローチが実用的であり、one私の推論が柔軟ではないということです。
どちらの場合も、私が間違っていることを見つけるのを手伝ってくれてありがとう。または私が正しい場合は、私の主張を議論する方法を提案してください。
ベストアンサー1
まあ、私は別のアカウントのアイデアに反対する2つの主張を考えることができます。
まず、クラシックUNIXグループは、一般的な共有ファイルツリーに比べて大きな欠陥があります。つまり、各ユーザーとそれらが実行するすべてのスクリプトには、ファイルとディレクトリグループを書き込み可能にするためにumaskが必要であり、すべてのディレクトリにグループ固定ビットを適用する必要があります。 。実際には、多くのスクリプトが制限的なumaskを指定し、rsync -a自分が所有するディレクトリにcp -aファイルをパブリックツリーに入れると、tar -xグループ固定ビットを追加してグループを共有するように変更するのを忘れやすいので、難しいです。結局、Joeが所有するファイルのサブツリーが作成され、Joeは休暇中またはランチに行きます。誰かがそのファイルを変更し、システム管理者に行って修正する必要があります。 IMHO、Unixの権限はシンプルで効率的に設計されていますが、現実の世界ではそれほど実用的ではありません。
次に、このパブリックファイルツリーにバイナリが含まれていて、誰もがそのパスを$ PATHに追加した場合、セキュリティはまったくありません。誰でもグループ全体をハイジャックできるので、実際にお互いを信頼することをお勧めします。また、NFSを使用しているため、ユーザーが自分のワークステーションへのrootアクセス権を取得できる場合は、他のユーザーと同じように中央ファイルにアクセスできます。
ユーザーアカウントをキャンセルするアイデアは、パスワードが保存されているローカルワークステーションからそのアカウントを削除するだけですone。これは、NFSを使用すると、ファイルサーバーがユーザーがどのパスワードを入力したかを知らないためです。そして、彼らのワークステーションカーネルが「こんにちは、私のUIDは502です。私の代わりにこれをやってください」と言っているだけです。
したがって、組織がこの問題を推進する前に、必要なことを実際に達成できるかどうかを検討する必要があります。
プログラムのバージョンの混乱を軽減したい場合は、管理者が所有するバージョンをインストールするようユーザーに依頼することもできます。管理者が$ PATHのすべてを制御すると、セキュリティが向上します。
誰がファイルを変更しているかを確認するために別のアカウントが必要な場合は、INotify（Perlで書くことをお勧めします）を使用して共有ツリーを監視するデーモンを作成し、各g+rwx「開く」後にこれらのビットイベントを強制する必要がありますかもしれません。各「書き込み」イベント以降のUID。
助けてください...