SUID仅对可执行文件生效，不能用于目录；防目录内随意删除需SGID（确保组继承）与Sticky Bit（限制仅所有者可删）组合，如chmod 3775。
SUID 不能用于目录，只对可执行文件生效；防止目录中数据被随意删除，真正起作用的是 SGID + Sticky Bit（粘滞位） 的组合，而非 SUID。
目录里设 SGID 是为了组继承，不是防删
SGID 应用在目录上时，核心作用是：
- 新建的文件和子目录自动继承该目录的所属组（而不是创建者的主组）
- 这便于多用户协作，确保同组成员能互相编辑、删除（配合写权限）
设置方法：
chmod g+s /shared/project # 或数字模式（如需同时开放组读写执行） chmod 2775 /shared/project
✅ 验证是否生效：ls -ld /shared/project → 显示 drwxr-sr-x（属组执行位为小写 s）
⚠️ 若显示 drwxr-Sr-x（大写 S），说明属组无执行权限，SGID 实际无效。
真正防“随意删除”的是 Sticky Bit（粘滞位）
Sticky Bit（常称粘滞位）才是控制“谁可以删谁的文件”的关键机制：
- 启用后，只有文件所有者、目录所有者、root 才能删除或重命名该目录下的文件
- 其他人即使有目录写权限，也无法删除别人创建的文件
典型场景： /tmp 就是 1777（即 rwxrwxrwt）
设置方法：
chmod +t /shared/project # 或数字模式（推荐 2775 + 1 = 2775 → 实际要加 1，即 3775？不对！注意：三位是ugo，前缀是独立的） # 正确数字写法： chmod 2775 /shared/project # SGID chmod 1775 /shared/project # Sticky Bit（仅粘滞位） chmod 3775 /shared/project # SGID + Sticky Bit（2+1=3）
✅ 权限显示应为：drwxrwsr-t（最后一位 t）或 drwxrwsr-T（若其他用户无执行权，则为大写 T，此时粘滞位无效）
组合使用建议（协作目录防误删）
假设你要建一个多人共用的 /var/www/html/uploads，目标是：
- 所有用户上传的文件自动归属
www-data组 - 用户只能删自己上传的文件，不能删别人的
操作步骤：
-
创建并设置属组：
sudo mkdir -p /var/www/html/uploads sudo chgrp www-data /var/www/html/uploads sudo chmod 2775 /var/www/html/uploads # SGID + rwxrwxr-x sudo chmod +t /var/www/html/uploads # 加粘滞位 → 最终等价于 3775
-
确保用户属于
www-data组：sudo usermod -aG www-data alice
-
检查最终权限：
ls -ld /var/www/html/uploads # 应显示：drwxrwsr-t 1 root www-data 4096 Sep 16 04:45 /var/www/html/uploads
⚠️ 注意：umask 影响新建文件权限。若希望新文件默认可被组写（如
rw-rw-r--），需确保用户 umask 为002（而非默认022）。
常见误区澄清
- ❌
chmod 4755 目录：SUID 对目录无效，系统忽略，且ls可能显示drwsr-xr-x—— 这个s是误导性的，实际不触发任何提权行为 - ❌ 单独 SGID 不能防删：它只管组归属，不管删除权限；没 sticky bit，组内有写权限的用户仍可删别人文件
- ❌
chmod 1777不等于安全：它放开所有人的读写执行，仅靠t限制删除，但可能带来其他风险（如覆盖、执行恶意脚本），应按需收紧（如3775更合理）
不复杂但容易忽略
