Linux文件特殊权限包括SetUID、SetGID和Sticky位：SetUID使执行者临时获得文件所有者权限（如passwd）；SetGID对目录使新建文件继承目录属组；Sticky位限制目录中用户仅可删除自己文件（如/tmp）。
Linux文件特殊权限（SetUID、SetGID、Sticky位）是普通权限之外的三类关键控制机制，直接影响程序执行时的权限提升、目录协作行为和文件删除规则。它们不改变文件本身的读写执行权限，而是调整“谁在什么条件下能以什么身份做某事”。理解它们，才能真正掌握Linux权限模型的深层逻辑。
SetUID：让普通用户临时获得文件所有者的权限
当一个可执行文件设置了SetUID位（u+s），任何用户运行它时，进程将**以该文件所有者身份运行**，而非执行者自身身份。这是提权的关键机制，但也是安全风险高发区。
常见例子：
– /usr/bin/passwd 就是典型SetUID程序。普通用户执行它时，能以root身份修改/etc/shadow（仅root可写），从而更新密码。
– 若给一个shell脚本设置SetUID，大多数现代Linux系统会忽略该位（出于安全限制），只对编译后的二进制有效。
设置与查看方法：
– 设置：sudo chmod u+s /path/to/executable 或 sudo chmod 4755 /path/to/executable（4代表SetUID）
– 查看：ls -l 输出中，属主执行位若为s（如 -rwsr-xr-x），表示SetUID已启用；若为大写S，说明文件无执行权限但SetUID位被设（无效）
SetGID：影响执行身份与目录内新建文件的组归属
SetGID（g+s）有两种作用场景，取决于它设置在文件还是目录上：
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 对可执行文件：运行时进程以该文件所属组身份运行（类似SetUID对组的映射），实际使用较少
- 对目录：最常用。在此目录中创建的新文件或子目录，**自动继承该目录的所属组**，而非创建者默认组。这对团队协作目录（如共享工作区）至关重要
示例：
– 目录 /project 设置了SetGID（drwxr-sr-x），用户alice（属组dev）和bob（属组ops）都加入dev组并有写权限。他们在/project下新建文件，无论自己默认组是什么，新文件属组都是dev，确保彼此可访问。
设置与查看：
– 设置：chmod g+s /path/to/dir 或 chmod 2775 /path/to/dir（2代表SetGID）
– 查看：ls -l 中属组执行位为s（如 drwxr-sr-x）表示生效；大写S表示无执行权限但位已设
Sticky位：保护目录内他人文件不被误删
Sticky位（+t）**只对目录有意义**。启用后，在该目录中有写权限的用户，只能删除自己创建的文件或子目录，无法删除同目录下其他用户创建的内容——即使对方文件权限是777也不行。
最典型应用：
– /tmp 目录几乎总是带Sticky位（drwxrwxrwt）。所有用户都能在里面建文件，但不能随意删别人的东西。
设置与查看：
– 设置：chmod +t /path/to/dir 或 chmod 1777 /path/to/dir（1代表Sticky）
– 查看：ls -l 中其他用户执行位显示为t（如 drwxrwxrwt），大写T表示无执行权限但位已设
安全提醒与常见误区
这三类特殊权限不是“功能开关”，而是权限放大器，用错极易引发越权或数据泄露：
- 不要随意给脚本或未知程序加SetUID/SetGID——攻击者可能利用其中漏洞获取高权限
- SetUID对shell脚本通常无效（内核主动忽略），别指望靠它提权
- Sticky位对文件无意义，对目录才起作用；误设不会报错，但也没效果
- 权限数字表示法中，三位八进制前缀（4/2/1）分别对应SetUID/SetGID/Sticky，可叠加（如4+2+1=7 → 7755 表示三者全开）
掌握它们，不只是为了记住命令，更是为了读懂系统设计者的权限意图——谁该做什么、在什么约束下做、以及为什么必须这样限制。
