chmod 4755 对 shell 脚本不生效，因 Linux 内核默认忽略脚本的 SUID 位，仅二进制文件在 execve 阶段切换有效 UID；sgid 对目录控制新建文件组归属，对文件仅影响进程有效 GID；sticky bit 限制非所有者删除他人文件，不限制写入。
为什么 chmod 4755 不生效？SUID 位被忽略的真相
Linux 对 SUID 的执行有硬性限制：仅对可执行文件（且是二进制或脚本）有效，对 shell 脚本默认不执行 SUID —— 这不是 bug，是内核级安全策略。大多数发行版（包括 Ubuntu、CentOS）在加载脚本时直接丢弃 setuid 位，哪怕 ls -l 显示 rwsr-xr-x，实际运行仍以当前用户身份执行。
- 真正生效的只有编译后的二进制（如
/usr/bin/passwd），它由内核在 execve 阶段切换有效 UID - 想让脚本“模拟” SUID 行为，必须用 C 写一个 wrapper（调用
seteuid(getpwnam("target")->pw_uid)），再编译后设chmod 4755 - 检查是否生效：运行
geteuid()或id -u，对比getuid()；若两者不同，说明SUID生效
sgid 对目录和文件的行为差异极大
SGID 在目录和普通文件上完全不是一回事：对目录，它控制新创建文件的组归属；对文件，它只影响进程的有效 GID（类似 SUID 的 UID 切换逻辑，但极少使用）。
- 给目录设
chmod 2775 /shared后，所有用户在此目录下新建的文件/子目录，其所属组自动继承/shared的组（而非创建者主组） - 给普通文件设
SGID（如chmod 2755 ./runner）仅在执行时把进程有效 GID 设为该文件属组 —— 但除非程序内部显式调用setegid()或依赖组权限做文件操作，否则几乎无感 - 注意：
umask仍起作用，比如umask 002下新建文件才是rw-rw-r--；若 umask 是022，即使 SGID 目录，新文件也是rw-r--r--
sticky bit 不是“防删”，是“防删别人建的”
Sticky bit（chmod 1777 /tmp）常被误读为“禁止删除”，实际规则非常具体：仅当文件所有者、目录所有者或 root 才能删除或重命名该目录下的文件。
- 普通用户 A 在
/tmp创建file_a，用户 B 即使对该目录有写权限，也无法rm /tmp/file_a—— 报错Operation not permitted - 但 B 可以成功
echo "x" > /tmp/file_a（覆盖内容），只要文件本身有写权限；sticky bit管的是 unlink/rename 系统调用，不干涉 open/write - 常见误配：给非共享目录加
sticky bit（如chmod 1755 ~/mydir），纯属冗余，还可能干扰某些工具（如 rsync 的权限同步逻辑）
用 stat 命令验证特殊权限比 ls 更可靠
ls -l 显示的 s 或 t 容易误判：小写 s 表示对应权限位（user/group）同时置位且可执行；大写 S 表示权限位已设但不可执行（比如 chmod 4644 file），此时 SUID 实际无效。
- 用
stat /path/to/file查看Access: (4755/-rwsr-xr-x)中括号内数字更直观：首位4= SUID，2= SGID，1= sticky - 脚本文件即使显示
-rwsr-xr-x，stat输出的Uid:/Gid:字段中Effective和Real仍相同，就是没生效 - 避免用
find / -perm -4000扫描 SUID 文件时漏掉符号链接——加-xtype f排除链接，否则可能报错或返回错误路径
真正难的不是设权限，而是理解内核在 execve、open、unlink 等关键系统调用中如何读取并应用这些位；多数问题出在混淆了“权限位存在”和“权限位生效”。
