setuid使普通用户执行文件时临时获得属主权限，setgid对文件令进程获属组权限、对目录则使新文件继承其属组；二者均通过chmod u+s/g+s或4/2前缀设置，ls -l中s/s标识生效与否，需谨慎使用以防提权风险。
Linux 中的 setuid 和 setgid 是两个关键的特殊权限位，它们不改变文件的常规读写执行权限，而是影响程序运行时的**身份上下文**——即谁的权限被临时“借用”。理解它们，是掌握 Linux 权限模型和系统安全设计的基础。
setuid：让普通用户临时拥有文件所有者的权限
当一个可执行文件设置了 setuid（u+s），任何用户执行它时，进程的有效用户 ID（EUID）会临时变成该文件的属主 ID，而不是执行者自己的 UID。这使得普通用户能完成本需 root 权限的操作。
- 典型例子：
/usr/bin/passwd属主是 root，权限为-rwsr-xr-x。普通用户执行它时，就能以 root 身份修改/etc/shadow（该文件仅 root 可写） - 只对二进制可执行文件有效；对脚本（如 bash、python 文件）无效（内核会忽略，出于安全考虑）
- 若文件原本没有执行权限（x），设置 setuid 后，权限位显示为大写 S（如
-rwSr--r--），表示该位已设但不生效 - 设置方式：
chmod u+s /path/to/executable或chmod 4755 /path/to/executable（4 代表 setuid）
setgid：分两种场景，作用不同
setgid（g+s）的行为取决于目标对象是**可执行文件**还是**目录**，这是它与 setuid 的重要区别。
- 对可执行文件：类似 setuid，执行时进程的有效组 ID（EGID）变为文件属组 ID。较少见，多用于需要特定组权限的工具
- 对目录：这才是更常用的功能——该目录下新创建的文件或子目录，其属组自动继承该目录的属组，而非创建者默认的主组。这对协作共享目录非常关键
- 例如：目录
/shared属组为devteam，设置了drwxrwsr-x（s 在组执行位）。无论谁在其中新建文件，该文件属组都是devteam，方便组内成员统一读写 - 设置方式：
chmod g+s /path/to/dir或chmod 2775 /path/to/dir（2 代表 setgid）
如何识别和验证这两个权限
使用 ls -l 查看时，关注权限字符串第 4 位（setuid）和第 7 位（setgid）：
- 小写 s 表示权限位已设且对应位置有执行权（x），功能生效
- 大写 S 表示权限位已设，但对应位置无执行权（x），功能不生效
- 常见组合示例：
-rwsr-xr-x（setuid 生效）、-rwxr-sr-x（setgid 目录或文件生效）、drwxrwsr-x（带 setgid 的目录）
安全注意事项
这两个权限强大，也意味着风险。滥用可能成为提权入口：
- 避免给不可信的程序设置 setuid/setgid，尤其来源不明的二进制文件
- 定期检查系统中带 s 位的文件：
find / -perm -4000 -type f 2>/dev/null（setuid）或find / -perm -2000 -type f,d 2>/dev/null（setgid 文件和目录） - 注意：root 用户执行 setuid 程序时，EUID 不变（仍是 0），所以效果不明显；真正体现价值的是普通用户调用
