当前位置：首页 > 文章列表 > 文章 > linux > Linux设置SUID和SGID权限详解

Linux设置SUID和SGID权限详解

2026-04-01 11:18:24 0浏览收藏

本文深入剖析了Linux中SUID、SGID和sticky bit三大特殊权限的真实行为与常见误区：SUID对shell脚本根本无效是内核刻意为之的安全设计，仅二进制程序在execve阶段能真正切换有效UID；SGID在目录和文件上作用截然不同——前者强制继承组归属，后者仅影响进程有效GID且极少实用；sticky bit并非阻止写入，而是精准限制非所有者删除或重命名他人文件；文章还强调用stat验证权限比ls更可靠，并指出问题根源往往不在权限设置本身，而在于混淆“位已设置”与“位被内核执行”的本质区别——理解execve、unlink等系统调用如何解析这些位，才是掌握Linux权限机制的关键。

linux怎么设置文件特殊权限_linux使用suid和sgid【详解】

为什么 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 排除链接，否则可能报错或返回错误路径