同一のUIDを持つ複数の* NIXアカウント
Linux/Unixで同じUIDを持つ複数のアカウントを作成するときに、標準の予想される動作があるかどうか、またそれが悪い習慣と見なされているかどうかに興味があります。これを使ってRHEL5でいくつかのテストを行ったところ、期待どおりに動作しましたが、このトリックを使用して運命を誘惑しているかどうかはわかりません。
例として、同じIDの2つのアカウントがあるとします。
a1:$1$4zIl1:5000:5000::/home/a1:/bin/bash
a2:$1$bmh92:5000:5000::/home/a2:/bin/bash
これが意味することは：
- 独自のパスワードを使用して各アカウントにログインできます。
- 私が作成するファイルは同じUIDになります。
- 「ls -l」などのツールは、ファイル（この場合はa1）の最初のエントリーとしてUIDをリストします。
- 2つのアカウントは実際には同じユーザーであるため、2つのアカウント間の権限や所有権の問題は回避します。
- アカウントごとにログイン監査が行われるので、システムで何が起こっているかを追跡する際の粒度が向上します。
だから私の質問は：
- この能力は設計されているのですか、それともそれが機能するための方法なのですか？
- これは* nixのバリアント全体で一貫していますか？
- これは受け入れられている習慣ですか？
- この実践に意図しない結果はありますか？
ここでの考え方は、これを通常のユーザーアカウントではなくシステムアカウントに使用することです。
私の意見：
この機能は設計されたものですか、それとも単なる動作方法ですか？
それは設計されています。 * NIXを使い始めてから、ユーザーを共通のグループに配置することができました。 UIDを問題なく同じにする機能は、意図した結果にすぎず、すべての場合と同様に、誤って管理すると問題が発生する可能性があります。
これは* nixバリアント全体で一貫していますか？
私はそう信じています。
これは受け入れられている慣行ですか？
はい、一般的に使用されている方法で受け入れられます。
このプラクティスに意図しない結果がありますか？
ログイン監査以外には何もありません。あなたが正確にそれを望んでいない限り、まず始めに。
すべてのUnixで動作しますか？はい。
使用するのに良いテクニックですか？いいえ。他にも優れた手法があります。たとえば、UNIXグループの適切な使用と厳密に制御された「Sudo」構成は、同じことを実現できます。
これが問題なく使用された場所を1つだけ確認しました。 FreeBSDでは、デフォルトのシェルとして/ bin/shを持つ「toor」（ルートのスペルが逆）と呼ばれる2番目のrootアカウントを作成するのが伝統的です。このようにして、ルートのシェルがめちゃくちゃになっても、ログインできます。
私はあなたの質問に標準的な答えを提供することはできませんが、私の会社はrootユーザーと何年もの間これを行っており、問題は一度もありません。 「kroot」ユーザー（UID 0）を作成します。その存在の唯一の理由は、/ bin/shまたはbin/bashの代わりに/ bin/kshをシェルとして持つことです。私たちのOracle DBAは、インストールごとに3つまたは4つのユーザー名を持ち、すべて同じユーザーIDを持つユーザーと同様のことをしています（これは、ユーザーごとに個別のホームディレクトリを作成するために行われたと思います。これは少なくともSolarisとLinuxでは10年ですが、設計どおりに機能していると思います。
通常のユーザーアカウントではこれを行いません。お気づきのように、最初のログイン後はすべてログファイルの名に戻るため、あるユーザーのアクションが別のユーザーのアクションになりすまされる可能性があると思います。システムアカウントの場合は問題なく機能します。
このプラクティスに意図しない結果がありますか？
私が知っている問題が1つあります。 Cronは、このUIDエイリアシングではうまく機能しません。 Pythonスクリプトから "crontab -i"を実行してcronエントリを更新します。次に、シェルで "crontab -e"を実行して同じものを変更します。
今度はcron（vixie、と思います）がa1とa2（/ var/spool/cron/a1と/ var/spool/cron/a2の両方）の同じエントリを更新したことに注意してください。
この機能は設計されたものですか、それとも単なる動作方法ですか？
そのように設計されています。
これは* nixバリアント全体で一貫していますか？
はい、そうです。
これは受け入れられている慣行ですか？
あなたが何を意味するかによる。このタイプのものは、非常に具体的な問題に答えます（root/toorアカウントを参照）。他のどこでも、あなたは将来、愚かな問題を求めています。これが正しい解決策かどうかわからない場合は、おそらくそうではありません。
このプラクティスに意図しない結果がありますか？
ユーザー名とUIDを交換可能として扱うことは一般的な習慣です。他の数人が指摘したように、ログイン/アクティビティ監査は不正確になります。また、関連するユーザー関連のスクリプト/プログラム（ディストリビューションのuseradd、usermod、userdelスクリプト、定期メンテナンススクリプトなど）の動作も確認する必要があります。
これらの2人のユーザーを新しいグループに追加し、そのグループに必要なアクセス許可を付与することで達成できない、これで何を達成しようとしていますか？
これは私が見たすべてのディストリビューションで予想される動作であり、ルートアクセスでアカウントを非表示にするために「敵」が使用する一般的なトリックです。
これは確かに標準的ではありません（これはどこでも見たことはありません）が、自分の環境でこれが適切だと思えば、これを使用できない理由はないはずです。
現在頭に浮かぶ唯一の落とし穴は、これが監査を困難にするかもしれないということです。同じuid/gidを持つ2人のユーザーがいる場合、ログを分析しているときにどちらが何をしたかを理解するのは難しいと思います。
プライマリグループIDの共有は一般的であるため、問題は実際には[〜＃〜] uid [〜＃〜]を中心に展開します。
私は以前、誰かにrootアクセスを与えるためにこれを行いました。rootパスワードを明かす必要はありません-これはうまくいきました。 （須藤の方がいい選択だったと思いますが）
私が注意する主なことは、ユーザーの1人を削除するようなものです-プログラムmay混乱して両方のユーザー、または両方に属するファイル、または同様のものを削除します。
実際、プログラマはおそらく1：1の関係を想定とユーザーとUIDの間で考えているため、他のプログラムでは、userdelで説明したのと同様の予期しない結果が発生する可能性があります。
ところで、この質問/回答は、今日のOS向けに更新されました。
redhat：一意のUIDとGID番号の割り当ての管理 から引用すると、UIDとGIDの使用法とその管理、およびジェネレーター（IDサーバー）
ランダムなUIDおよびGID値を生成すると同時に、レプリカが同じUIDまたはGID値を生成しないようにする必要があります。単一の組織に複数の異なるドメインがある場合、一意のUIDおよびGID番号の必要性がIdMドメインにまたがることがあります。
同様に、システムへのアクセスを許可するユーティリティは、予期しない動作をする可能性があります（同じ参照）。
2つのエントリに同じID番号が割り当てられている場合、その番号の検索では最初のエントリのみが返されます。
問題は、「最初の」の概念が明確に定義されていない場合に発生します。インストールされているサービスに応じて、ユーザー名は可変サイズのハッシュに保持され、一貫性のない要因に基づいて異なるユーザー名を返します。 （私はこれが本当であることを知っています.1つのIDで2つのユーザー名を使用しようとしたことがあります.1つはローカルユーザー名で、もう1つはUIDにマップしたいdomain.usernameです（最終的にはまったく別の方法）、しかし、「usera」でログインし、「who」または「id」を実行して、「userb」OR「usera」-ランダムに表示されます。
グループからUIDの複数の値を取得するためのインターフェースがあります（単一のGIDを持つグループは複数のUIDに関連付けられるように設計されています）が、1つのUIDの名前のリストを返すポータブルインターフェースがないため、またはシステム間、または同じシステム上のアプリケーションでさえ同様の動作は、不幸にも驚くかもしれません。
Sun（現在のOracle）のyp（yellowpages）またはNIS（NetworkInformationServices）では、一意性の要件について多くの参照があります。 uniqueIDを複数のサーバーとドメインに割り当てるように特別な機能とサーバーが設定されます（例は id_allocd、gid_allocd-UIDおよびGIDアロケーターデーモンです）マンページ
チェックする可能性のある3番目のソースは、NFSアカウントマッピングに関するMicrosoftのサーバードキュメントです。 NFSはUNIXファイル共有プロトコルであり、ファイルのアクセス許可とアクセスがIDによってどのように維持されるかを記述します。そこで、彼らは書きます：
UID。これは、UNIXオペレーティングシステムがユーザーを識別するために使用する符号なし整数であり、passwdファイル内で一意である必要があります。
GID。これは、UNIXカーネルがグループを識別するために使用する符号なし整数であり、グループファイル内で一意である必要があります。 MS-NFS管理ページ
一部のOSは複数の名前/ UIDを許可している可能性がありますが（BSD派生、たぶん？）、ほとんどのOSはこれが一意であることに依存しており、一意でない場合に予測できない動作をする可能性があります。
注-このページを追加しているのは、この日付のエントリを現代のユーティリティが非一意のUID/GIDに対応するためのサポートとして参照したためです...ほとんどの場合、そうではありません。
それが良いアイデアかどうかもわかりませんが、上記の動作をいくつかの場所で使用しています。ほとんどの場合、ftp/sftpサーバーへのアクセスとWebサイトのコンテンツの更新に使用されるアカウント用です。それは何も壊すようには見えず、複数のアカウントを使用する場合よりもアクセス許可の処理が簡単になるようです。
同じUIDを持つ複数のアカウントの使用に起因する（かなりあいまいな）問題に遭遇し、これが良い習慣ではない理由の例として共有したいと思いました。
私の場合、ベンダーはRHEL 7にInformixデータベースサーバーとWebアプリケーションサーバーをセットアップしました。セットアップ中に、UID 0の複数の「ルート」アカウントが作成されました（理由は聞かないでください）。つまり、「root」、「user1」、「user2」のすべてがUID 0を持っています。
RHEL 7サーバーは、後にwinbindを使用してActive Directoryドメインに参加しました。この時点で、Informix DBサーバーは起動できなくなりました。 oninitの実行に失敗し、"Must be a DBSA to run this program"の1つを示すエラーメッセージが表示されました。
トラブルシューティング中に見つかったものは次のとおりです。
Active Directoryに参加しているシステムで
id rootまたはgetent passwd 0（UID 0をユーザー名に解決する）を実行すると、「root」ではなく「user1」または「user2」がランダムに返されます。Informixは、文字列の比較に依存して、それを開始したユーザーのテキストユーザー名が「root」であり、それ以外の場合は失敗するかどうかを確認していたようです。
Winbindがないと、
id rootとgetent passwd 0はユーザー名として常に「root」を返します。
修正は、/etc/nscd.confのキャッシュと永続性を無効にすることでした：
enable-cache passwd no
persistent passwd no
この変更後、UID 0は再び一貫して「ルート」に解決され、Informixが起動する可能性があります。
これが誰かに役立つことを願っています。