Linux进程的EUID、EGID等权限标识具体存储位置咨询

Great question—this is one of those under-the-hood Linux details that doesn’t get much airtime in basic permission tutorials, so I’m glad you dug into it! Let’s break this down clearly:

Storage Location: The Process Credentials in task_struct #

Every running process in Linux is tracked by the kernel using a task_struct structure (the core of the Process Control Block, or PCB). Inside this structure, there’s a pointer to a cred struct (struct cred *cred) that holds all the identity and permission-related IDs for the process. This is where EUID and EGID live, alongside other critical IDs:

• uid/gid: The real user/group IDs (the actual user who launched the process)
• euid/egid: The effective user/group IDs (the ones the kernel uses for permission checks)
• fsuid/fsgid: Filesystem-specific user/group IDs (usually matches EUID/EGID, used for niche filesystem operations)

These values live in kernel memory—user-space programs can’t directly access the task_struct or cred structs, but they can fetch EUID/EGID using system calls like geteuid() or getegid(), which pull the values straight from the kernel’s internal structures.

How the Kernel Uses EUID/EGID for Permission Checks #

Let’s tie this to your example of running read_file.out to read ~/file.txt:

1. Process Initialization: When you launch the binary, the kernel sets up the new process’s credentials. If read_file.out doesn’t have the SUID/SGID bit enabled, the EUID/EGID will match your real UID/GID. If it does have SUID set, the EUID switches to the binary’s owner UID (same logic applies to SGID and EGID).
2. Permission Check Trigger: When the process calls open() or read() on ~/file.txt, the kernel kicks off a permission check via the VFS (Virtual Filesystem) layer’s inode_permission() function.
3. ID Comparison: The function grabs the process’s EUID and EGID from its cred struct, then compares them against the file’s inode permissions:
   • First, if the EUID matches the file’s owner UID, it checks the owner-specific permission bits (e.g., the r bit for read access)
   • If that doesn’t match, it checks if the EGID (or any of the process’s supplementary group IDs) matches the file’s group GID, then verifies the group permission bits
   • If neither matches, it falls back to checking the "other" permission bits
4. Access Decision: If the required permission is granted via any of these checks, the kernel allows the operation; otherwise, it returns a Permission denied error.

Quick side note: The fsuid/fsgid are occasionally used instead of EUID/EGID for filesystem operations, but in most regular use cases, they’re identical to EUID/EGID unless explicitly modified by system services.

内容的提问来源于stack exchange，提问作者Topper Harley