Unix 系オペレーティングシステムでは、ユーザー識別子(多くの場合、ユーザー IDまたはUIDと略されます) は、ユーザーを識別するために使用される値です。UID は、グループ識別子(GID) やその他のアクセス制御基準とともに、ユーザーがアクセスできるシステム リソースを決定するために使用されます。パスワード ファイルは、テキスト形式のユーザー名を UID にマッピングします。UID は、Unixファイルシステムのinode、実行中のプロセス、tarアーカイブ、および現在廃止されているNetwork Information Serviceに格納されます。POSIX 準拠環境では、シェルコマンドによって、現在のユーザーの UID に加えて、ユーザー名、プライマリおよび補助グループ識別子(GID)、グループ名などの詳細情報が提供されます。id
POSIX規格では、特権プロセスが動的に異なる役割を担えるようにするため、プロセス記述子テーブルに3つの異なるUIDフィールドが導入されました。
euidプロセスの実効ユーザーID(UID )は、ほとんどのアクセスチェックに使用されます。また、そのプロセスによって作成されたファイルの所有者としても使用されます。
fsuidLinuxには、ファイルシステムへのアクセス制御に明示的に使用されるファイルシステムユーザーID()もあります。これは、明示的に設定されていない限り、と一致します。 、、、またはがrootである場合に限り、 rootのユーザーIDeuidになります。が変更されると、その変更はに反映されます。ruidsuideuideuidfsuid
の意図はfsuid、プログラム(NFSサーバーなど)が、特定のファイルシステムの権限に制限されることを可能にすることですuidが、その権限に対してシグナルを送信する許可を与える必要はありません。カーネル2.0以降、Linuxはシグナル送信に関してSUSv3uidルールに準拠しているため、の存在はfsuidもはや必要ありませんが、互換性のために残っています。[ 1 ]fsuid
実際の UID ( ruid) と実際の GID ( rgid) は、プロセスの実際の所有者を識別し、シグナルの送信権限に影響します。スーパーユーザー権限を持たないプロセスは、送信者のruidまたはがeuid受信者のruidまたは と一致する場合にのみ、他のプロセスにシグナルを送ることができます。子プロセスはsuid親プロセスから認証情報を継承するため、子プロセスと親プロセスは互いにシグナルを送ることができます。
保存されたユーザー ID は、特権昇格で実行されているプログラムが一時的に特権のない作業を行う必要がある場合に使用されます。euid特権値 (通常は0) から特権のない値 (特権値以外の値) に変更すると、特権値が に保存されますsuid。その後、プログラムのeuidを に保存されている値に戻すことで、特権昇格を復元できます。特権のないプロセスは、 を の値、 の値、 の値のいずれか 3 つの値にsuid設定できます。euidruidsuideuid
POSIXでは、UIDは整数型である必要があります。ほとんどのUnix系オペレーティングシステムは、UIDを符号なし整数として表現します。UID値のサイズはシステムによって異なり、一部のUNIX OSは15ビット値を使用して最大32767までの値を許可していましたが、Linux(バージョン2.4以前)などの他のシステムは16ビットUIDをサポートし、65536個の一意のIDが可能でした。現代のUnix系システムの大部分(1990年のSolaris 2.0、2001年のLinux 2.4など)は32ビットUIDに切り替え、4,294,967,296(2³²)個の一意のIDを許可しています。
Linux Standard Base Core Specificationでは、UID値が0から99の範囲ではシステムによって静的に割り当てられ、アプリケーションによって作成されてはならないと規定されています。一方、UIDが100から499の範囲では、システム管理者やインストール後のスクリプトによる動的割り当てのために予約されるべきです。[ 2 ]
Debian Linux は、動的に割り当てられるシステム ユーザーとグループのために 100〜999 の範囲を予約するだけでなく、60000〜64999 の範囲でユーザーとグループを中央で静的に割り当て、さらに 65000〜65533 の範囲を予約します。[ 3 ]
Systemd は、 [ 4 ]を含むいくつかの特別な UID 範囲を定義しています。
FreeBSDでは、パッケージに UID が必要なポーターは、50 から 999 の範囲から空いているものを選び、静的割り当てを登録することができます。[ 5 ] [ 6 ]
POSIX システムの中には、新規ユーザーに 500 から始まる UID を割り当てるもの ( macOS、Red Hat Enterprise Linuxバージョン 6 まで) と、1000 から始まるもの (Red Hat Enterprise Linux バージョン 7 以降、[ 7 ] openSUSE、Debian [ 3 ]/etc/login.defs ) があります。多くの Linux システムでは、これらの範囲は、および同様のツールで指定されていますuseradd。
企業ネットワークにおける中央集中型のUID割り当て(LDAPやNFSサーバー経由など)では、クライアントコンピュータにローカルで割り当てられたUIDとの潜在的な競合を避けるため、1000を大きく超えるUID番号のみを使用し、60000~65535の範囲外に限定する場合があります。ローカルで新規ユーザーが作成される場合、ローカルシステムはNSSに既に存在するUIDとの競合をチェックし、回避するはずです。[注1 ]
OSレベルの仮想化では、 Linuxの名前空間などを使用してユーザー識別子を再マッピングできるため、再マッピングされたUIDとGIDがマッピングされる範囲を割り当てる必要があります。
systemd の開発者は、OS レベルの仮想化システムではコンテナごとに 65536 (2 16 ) 個の UIDを割り当て、2 16の整数倍を加算してマッピングすることを推奨しています。[ 4 ]
(uid_t) -1、省略された引数を識別するために POSIX によって予約されています。[ 9 ]-2 」にはいくつかのオペレーティングシステムでUID が割り当てられていましたが、 OpenBSDなどでは 2 15 −1 = 32,767 などの他の値も使用されています。[ 10 ] 16 ビットと 32 ビットの UID の互換性のために、多くの Linux ディストリビューションでは現在、2 16 −2 = 65,534 に設定されています。Linux カーネルは、32 ビットの UID が 16 ビットのシステムコールの戻り値に収まらない場合に、デフォルトでこの値を返します。[ 11 ] Fedora Linux は、システム使用用に静的に割り当てられた範囲 (0~99) の最後の UID を nobody: 99 に割り当て、代わりに 65534 を呼び出します。nfsnobodyNFSv4 は、プロトコル パケットでユーザー (およびグループ) を整数ではなくテキスト形式の「user@domain」名で識別することで、数値識別子の衝突を回避することを目的としていました。しかし、オペレーティングシステム カーネルとローカル ファイルシステムが整数のユーザー識別子を使用し続ける限り、これは追加の変換手順 (idmap デーモン プロセスを使用) を伴い、ローカル UID マッピング メカニズムまたはデータベースが誤って構成されたり、失われたり、同期が取れなくなったりすると、追加の障害点が発生する可能性があります。ユーザー名の「@domain」部分は、たとえば、特定の名前をどの機関が割り当てたかを示すために使用できます。
しかし実際には、既存の多くの実装ではNFSv4ドメインを固定値に設定することしかできず、結果として役に立たなくなっている。