同一の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ユーザーで行ってきましたが、これまでに何の問題もありませんでした。存在の唯一の理由は、/ bin / shまたはbin / bashの代わりにシェルとして/ bin / kshを持つことである「kroot」ユーザー（UID 0）を作成します。私たちのOracle DBAは、インストールごとに3つまたは4つのユーザー名を持ち、すべて同じユーザーIDでユーザーと同様のことをしていることを知っています（これは各ユーザーに別々のホームディレクトリを持つために行われたと思います。 10年、SolarisとLinuxで、設計どおりに動作していると思います。

通常のユーザーアカウントではこれを行いません。既に述べたように、最初のログイン後、すべてがログファイルの最初の名前に戻るため、あるユーザーのアクションがログの別のユーザーのアクションになりすます可能性があると思います。システムアカウントの場合、それはうまく機能します。

この機能は設計されていますか、それとも機能するのですか？

そのように設計されました。

これは、* nixバリアント全体で一貫していますか？

はい、そうです。

これは受け入れられている慣習ですか？

意味に依存します。このタイプのことは、非常に特定の問題に答えます（ルート/ Toorアカウントを参照）。他のどこでも、あなたは将来愚かな問題を求めています。これが正しいソリューションであるかどうかわからない場合は、おそらくそうではありません。

この慣行に意図しない結果はありますか？

ユーザー名とUIDを交換可能として扱うのは一般的な習慣です。他の数人が指摘したように、ログイン/アクティビティの監査は不正確です。関連するユーザー関連のスクリプト/プログラム（ディストリビューションのuseradd、usermod、userdelスクリプト、定期的なメンテナンススクリプトなど）の動作も確認する必要があります。

これら2人のユーザーを新しいグループに追加し、そのグループに必要な権限を付与することでは達成できない、これで何を達成しようとしていますか？

この慣行に意図しない結果はありますか？

私が知っている問題が1つあります。Cronは、このUIDエイリアシングではうまく機能しません。Pythonスクリプトから「crontab -i」を実行して、cronエントリを更新してください。次に、シェルで「crontab -e」を実行して同じものを変更します。

cron（vixie、私は思う）がa1とa2（/ var / spool / cron / a1と/ var / spool / cron / a2の両方）の同じエントリを更新したことに注意してください。

これは私が見たすべてのディストリビューションで予想される動作であり、「敵」がルートアクセスのアカウントを隠すために使用する一般的なトリックです。

それは確かに標準ではありません（私はこれをどこでも見たことはありません）が、適切だと思えば、自分の環境でこれを使用できない理由はないはずです。

今頭に浮かぶ唯一の落とし穴は、これが監査を難しくするかもしれないということです。同じuid / gidを持つ2人のユーザーがいる場合、ログを分析しているときにどちらが何をしたかを把握するのに苦労すると思います。

プライマリグループIDの共有は一般的であるため、質問は本当にUIDを中心に展開します。

ルートパスワードを漏らすことなく、誰かにルートアクセスを与えるためにこれを以前にやったことがあります-これはうまくいきました。（sudoがより良い選択だっただろうが、私は思う）

私が注意する主なことは、ユーザーの1人を削除することなどです。プログラムが混乱し、両方のユーザー、または両方に属するファイル、または同様のものを削除する場合があります。

実際、プログラマーはおそらくユーザーとUIDが1対1の関係にあると想定しているため、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」または「usera」をランダムに見ることができます。

グループからUIDの複数の値を取得するためのインターフェースがあります（単一のGIDを持つグループは複数のUIDに関連付けられるように設計されています）が、1つのUIDの名前のリストを返す移植可能なインターフェースがないため、システム間、または同じシステム上のアプリケーション間での同様の動作は、不幸なことに驚くかもしれません。

Sun（現在のoracle）yp（yellowpages）またはNIS（NetworkInformationServices）には、一意性の要件への多くの参照もあります。一意の IDを複数のサーバーとドメインに割り当てるための特別な機能とサーバーがセットアップされています（例：uid_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. 実行中id rootまたはgetent passwd 0Active Directoryの上（ユーザー名にUID 0を解決するには）、システムがランダムに代わりに「根」の「USER1」または「USER2」のいずれかを返します参加しました。

2. Informixは、文字列比較を使用して、起動したユーザーのテキストユーザー名が「root」であるかどうかを確認し、そうでない場合は失敗するようです。

3. winbindのがなければ、id rootとgetent passwd 0一貫してユーザー名として「root」を返します。

修正は、キャッシュと永続性を無効にすることでした/etc/nscd.conf：

enable-cache    passwd      no
persistent      passwd      no

この変更後、UID 0は再び一貫して「ルート」に解決され、Informixが起動できるようになりました。

これが誰かに役立つことを願っています。