LinuxカーネルはUIDとGIDをどのように処理しますか？
システムにユーザーを追加しようとすると、カーネルはそのユーザーに「登録」（システムコール？）の種類を要求しますか？カーネルは/etc/passwdでどのユーザーが利用できるか気にしますか、それともファイルの内容に関係なく値だけを知って処理しますか？
答え1
カーネルでは、ユーザーまたはグループは、プロセスがファイル（UID / GIDと許可ビットを持つファイル）を読み取ることができる（実際に開く（2））、それを確認するためにプロセスに添付された番号（UIDとGID）のみです。この目的）および他のタスク（例えば、プロセスが同じUIDに属するプロセスを操作することができる）。呼び出しプロセスのUID / GIDを変更するシステム呼び出しがあります（setuid（2）/setgid（2）など）。明らかに誰が利用できるかについて厳格な制限があります。
システムはこの番号を使用して、/etc/passwd、/etc/group、または他のいくつかのメカニズム（LDAP、NISなど）から名前を検索できますが、これは厳密に人が使用するものです。
ログインしてユーザー名を指定すると、プログラム（rootとして実行されるため、通常のユーザーが実行できない多くの操作を実行できます）がユーザー名を取得し、UIDを照会します（そのユーザーが最初に）パスワード（または他の認証）入力して確認してください。すべてが順調に進むと、プログラムは対応するUID / GIDに変わり、ユーザーシェルはexec（2）になります（やはり一般的なプログラムにすぎず、起動する特定のプログラムはユーザーアカウントの説明の一部です）。
答え2
カーネルは関係ありません/etc/passwd。すべての認証が/etc/passwdファイルを使用して行われるわけではありません。たとえば、ユーザー情報はNISまたはLDAPから取得できます。
答え3
あなたが探している小切手はacl_permission_check()次の場所にあります。fs/namei.c。単にファイル内の値とシステムコールを行っているユーザーの元のユーザーとグループIDの値を確認してください。インデックスノード。
一般的なPOSIXファイルシステムの場合、フルコールパスは次のとおりです。
open(2)→sys_open()→do_sys_open()→do_filp_open()→finish_open()→may_open()→inode_permission()→generic_permission()→acl_permission_check()
他のファイルシステムタイプ（FATなど）の場合、inodeが見つからない、許可ビットなどが原因で呼び出しチェーンが異なる場合があります。
カーネルは、ユーザーIDとグループIDがどこから来たのか、実際の値が何であるのか気にしません。