解決策 1:
私の意見:
この能力は設計されたものですか、それともたまたま機能しているだけですか?
設計されています。 *NIX を使い始めてから、ユーザーを共通のグループに配置できるようになりました。 UID を問題なく同じにする機能は、意図された結果に過ぎず、すべての場合と同様に、管理を誤ると問題が発生する可能性があります。
これは *nix バリアント間で一貫していますか?
私はそう信じています。
これは慣行として認められていますか?
はい、何らかの形で一般的に使用されているものとして受け入れられます。
この慣習に意図しない結果はありますか?
ログイン監査以外には何もありません。あなたがまさにそれを望んでいない限り、まず始めに.
解決策 2:
すべての Unix で動作しますか?はい。
上手に使える技でしょうか？いいえ、他にも優れたテクニックがあります。たとえば、UNIX グループと厳密に制御された「sudo」構成を適切に使用することで、同じことを実現できます。
これが問題なく使用された場所を 1 か所だけ見たことがあります。 FreeBSD では、デフォルトのシェルとして /bin/sh を持つ "toor" (root の逆スペル) と呼ばれる 2 番目の root アカウントを作成するのが伝統的です。このようにして、ルートのシェルがめちゃくちゃになってもログインできます。
解決策 3:
あなたの質問に対して標準的な回答を提供することはできませんが、逸話的に言えば、私の会社は root ユーザーで何年もこれを行っており、問題が発生したことはありません。 /bin/sh または bin/bash の代わりに /bin/ksh をシェルとして使用することだけが存在する「kroot」ユーザー (UID 0) を作成します。私たちの Oracle DBA は、インストールごとに 3 つまたは 4 つのユーザー名を持ち、すべて同じユーザー ID を使用して、ユーザーに対して同様のことを行っていることを知っています (これは、各ユーザーに個別のホーム ディレクトリを用意するために行われたと思います。少なくともこれを行ってきました)。 Solaris と Linux で 10 年間、設計どおりに機能していると思います。
通常のユーザー アカウントではこれを行いません。ご指摘のとおり、最初のログイン後、すべてがログ ファイルの最初の名前に戻るため、あるユーザーのアクションがログで別のユーザーのアクションになりすます可能性があると思います。システムアカウントの場合、うまく機能します。
解決策 4:
この慣習に意図しない結果はありますか?
私が認識している問題が1つあります。 Cron は、この UID エイリアシングをうまく処理できません。 Python スクリプトから「crontab -i」を実行して、cron エントリを更新してみてください。次に、シェルで「crontab -e」を実行して、同じものを変更します。
ここで、cron (ビクシーだと思います) が a1 と a2 の両方に対して同じエントリを更新することに注意してください (/var/spool/cron/a1 と /var/spool/cron/a2 内)。
解決策 5:
この能力は設計されたものですか、それともたまたま機能しているだけですか?
そのように設計されています。
これは *nix バリアント間で一貫していますか?
そうすべきです。
これは慣行として認められていますか?
あなたが何を意味するかによります。このタイプのものは、非常に具体的な問題に答えます (root/toor アカウントを参照)。他のどこでも、あなたは将来的に愚かな問題を求めています.これが正しい解決策かどうかわからない場合は、おそらくそうではありません。
この慣習に意図しない結果はありますか?
ユーザー名と UID を交換可能なものとして扱うのが一般的な習慣です。他の何人かが指摘したように、ログイン/アクティビティの監査は不正確になります。関連するユーザー関連のスクリプト/プログラム (ディストリビューションの useradd、usermod、userdel スクリプト、定期的なメンテナンス スクリプトなど) の動作も確認する必要があります。
この 2 人のユーザーを新しいグループに追加し、そのグループに必要な権限を付与することによって達成できないことは何ですか?