linux权限控制模型以uid/gid数字标识为核心，按owner→group→others顺序匹配文件inode中的三组rwx权限位；目录无x权限则无法访问其下任何文件；配置文件须用useradd等专用命令修改，禁用手动编辑。
Linux 权限控制模型不是一套“功能”，而是一套贯穿内核与用户空间的访问决策机制——它不靠名字判断谁是谁，而是靠数字ID（UID/GID）匹配文件元数据中的三组权限位，再按固定顺序决定放行或拒绝。
权限判定只看三件事：UID、GID 和权限位
系统内部从不认“root”或“admin”这种字符串，只认数字。root 固定为 UID 0；普通用户一般从 1000 开始；每个用户有且仅有一个主组（GID 记在 /etc/passwd 第4字段），还可加入最多31个附加组（记录在 /etc/group）。执行 id 命令能看到当前会话实际生效的所有 GID。
- 文件 inode 中存着三个关键数字：所有者 UID、所属组 GID、以及三组 rwx 权限位（Owner/Group/Others）
- 当进程访问文件时，内核严格按顺序检查：先比 UID 是否匹配所有者 → 再看该 UID 是否属于文件所属组（主组或任一附加组）→ 最后 fallback 到 Others
- 命中任意一层即停止匹配，按对应权限位放行或拒绝，不会继续往下查
目录的 x 权限是访问门槛，不是可有可无的装饰
对目录来说，r 和 x 是两回事：r（read）只允许 ls 列出文件名；x（execute）才真正决定能否进入该目录、能否访问其下文件的属性（比如读取内容、修改权限）。没有 x，即使 r 权限开着，也无法 cat 目录里的任何文件——因为内核连目标文件的 inode 都拿不到。
- ls /var/log 成功 ≠ 能读其中日志；若 /var/log 缺少 x 权限，cat /var/log/syslog 会报 Permission denied
- 常见误操作：给共享目录设了 775 却忘了加 x，导致组内成员能看见文件却打不开
- 安全建议：新建目录默认应含 x（如 755 或 775），除非明确禁止进入
用户与组管理必须走专用命令，不能直接改配置文件
/etc/passwd、/etc/shadow、/etc/group 是权限系统的“数据库”，格式极其敏感。手动编辑极易破坏字段分隔或加密字段结构，轻则用户无法登录，重则系统认证瘫痪。
- 增删用户用 useradd/userdel，改组用 usermod -aG（-a 表示追加，不覆盖原有组）
- 建组用 groupadd，删组用 groupdel（注意：组内仍有用户时 groupdel 会失败）
- 密码策略用 chage，查看凭证用 id 或 getent passwd username
特殊权限位解决典型协作与提权场景
SUID、SGID、Sticky Bit 不是“高级技巧”，而是为特定问题设计的最小化解决方案：
- SUID（chmod u+s 或 4xxx）：让普通用户执行时临时获得文件所有者的权限，典型如 /usr/bin/passwd 修改 /etc/shadow
- SGID（chmod g+s 或 2xxx）：对目录启用后，其下新建文件自动继承该目录所属组，避免协作目录中文件属组混乱
- Sticky Bit（chmod +t 或 1xxx）：只允许文件所有者或 root 删除 /tmp 下的文件，防止用户互相覆盖
这些位一旦滥用风险很高——SUID 程序若存在漏洞，可能被用于提权；SGID 目录若属组权限过宽，易造成越权写入。启用前需确认必要性，并定期审计。
