1. 先搞清几个ID的关系1.1 从一次我能改密码却读不了密码文件的困惑说起刚接触Linux那会儿我碰到过一个特别拧巴的现象用普通账号执行passwd改自己的登录密码一路顺畅系统把新密码写进了/etc/shadow可同一时刻我cat /etc/shadow却被一句Permission denied挡在门外。当时第一反应是系统是不是搞错了——既然我的账号能写这个文件凭什么连读都不让读后来才明白这背后是 UID、GID、EUID、EGID 这几个身份标识在分工再加上 SUID、SGID 这两位临时授权开关在背后做手脚。这件事几乎把Linux权限体系里最容易混淆的一整套概念串了起来真实身份是谁、当前生效身份是谁、程序执行时借用了谁的身份、目录里新建的文件归谁所有。这套东西听着抽象实际每天都在影响你为什么同一台机器上两个同事往同一个目录里丢文件过两天谁的都改不动为什么下载来的一个二进制程序一执行就是Permission denied为什么自己写的脚本加了chmod us却一点效果都没有。把这些ID搞明白这些问题基本都能在三分钟内定位。这篇内容适合三类人刚学Linux命令、被权限报错反复折磨的新手需要部署服务、给程序配权限的运维和开发以及想系统补一遍权限模型底层的进阶读者。我会从概念一点点推到实操验证给出可直接复现的命令和程序顺手把踩过的坑都摊开讲。1.2 四个ID的角色分工真实身份与临时身份先把最容易被混为一谈的四位请出来。UIDUser ID是用户的数字身份GIDGroup ID是用户所属主组的数字身份这两个是你是谁的档案记录存在/etc/passwd和/etc/group里id命令一敲就能看到。EUIDEffective UID和 EGIDEffective GID则是你此刻说话算不算数的凭据——内核在判断一个进程能不能读某个文件时看的是有效身份不是真实身份。打个生活化的比方UID 是你的身份证EUID 是你当天戴的工牌。平时两者是同一张脸你去食堂打饭刷工牌就行但某些特殊岗位上公司会临时发你一张代理工牌让你在这一个任务里拥有那个岗位的权限任务结束工牌收回你还是你。SUID 干的就是发代理工牌这件事。为什么非得搞两套身份因为记录我是谁和判断我能干什么是两回事。真实身份需要稳定、可审计、不能被程序随意篡改有效身份需要灵活允许在受控范围内临时切换。把两者分开才能既保证追溯性日志里记的永远是真实UID又保证功能可实现临时提权完成特定动作。还有两个常被忽略的成员保存的设置用户IDsaved set-user-ID和文件系统用户IDfsuid。前者是给seteuid预留的后悔药允许进程在提权和降权之间来回横跳后者主要在网络文件系统场景下参与访问判定日常排查碰到的概率不高但读/proc/self/status时会看到它别被吓到。1.3 一条命令看清进程身上的全部身份不用猜内核把每个进程的身份都摊在/proc里了。执行下面这条命令Uid那一行会有四个数字从左到右分别是真实UID、有效UID、保存UID、文件系统UIDGid行同理grep -E ^(Uid|Gid): /proc/self/status普通用户下典型输出是这样Uid: 1000 1000 1000 1000 Gid: 1000 1000 1000 1000四个数字完全一样说明当前 shell 没有任何提权动作。等你执行一个带 SUID 位的程序那个进程的四个数字就会开始分家。这个观察方法比看任何文档都直观我在排查权限问题时基本第一步就是抓这四列数字。再多说一句id命令的用法它能一次性把身份信息铺开id # 当前有效身份 id -r # 只看真实身份 id -u; id -g; id -G # 分别取UID、主GID、全部附加组GIDid -G那串数字很多人不当回事其实它直接决定了你能否访问属组为某个附加组的文件。用户除了主组还能被塞进十几个附加组这些组的GID全都参与权限判定后面讲权限比对顺序时会再提。2. 从进程视角看权限判定2.1 内核到底比对了什么理解权限判定最省事的办法是把自己当成内核手里拿着两样东西进程的有效身份EUID EGID 附加组列表以及目标文件的元数据所有者UID、属组GID、权限位rwxrwxrwx。剩下的事就是三次比对。第一次比所有者进程的 EUID 是否等于文件的 UID相等就用文件权限位的第1组属主三位来决定放行还是拒绝而且不管结果如何比对到此结束不会再去试组权限。这一点非常关键很多人以为属主不行再试试属组实际不是属主匹配是排他的。第二次比属组EUID 对不上就看进程的 EGID 和附加组列表里有没有任何一个等于文件的 GID。匹配上就用第2组属组三位判定同样排他不再往下走。第三次兜底前面都不匹配才用第3组其他人三位。如果这组权限也不够内核返回EACCES也就是你看到的那句Permission denied。这个顺序解释了为什么会出现文件所有者权限是---但属组权限是rwx所有者本人反而读不了的怪现象。不是bug是设计如此。我在给共享目录配权限时就栽过这个跟头为了收紧权限把属主位设成---结果文件创建者自己进不去。2.2 root 为什么也受这套规则约束有个流传很广的说法叫root 无敌严格讲不准确。root 的 EUID 是 0内核在权限检查里对 0 做了特殊放行只要 EUID 为 0读、写、进入目录基本都允许但仍然有几处例外。第一个例外是执行权限。一个文件如果没有对任何人开放x位root 也执行不了它会得到Permission denied。想执行必须至少有一个x位存在。第二个例外是写一个设置了不可变属性的文件或者写只读挂载的文件系统root 也拦不住内核的拒绝。第三个例外是root 想读一个属主不是自己、且所有r位都被去掉的普通文件在部分内核配置下依然能读但这不是可以依赖的行为别拿它当权限设计依据。真正的结论是root 的强权来自 EUID 为 0 这个特殊判断而不是跳过所有检查。理解这一点之后你再看 SUID 程序的行为会顺很多——SUID 的本质就是把进程的 EUID 改成文件所有者的UID如果文件所有者恰好是 root那么这个进程就获得了和 root 同等的判定待遇。2.3 真实身份为什么必须保留既然内核只看 EUID那真实UID留着干嘛主要有三个用途每一个都很实在。其一是审计。系统日志、进程记账、ps输出里记录的用户身份都以真实UID为准。一个普通用户执行了带 SUID 的程序进程里 EUID 变成了 0但真实UID还是 1000日志里仍然能追溯到这个操作是 1000 号用户发起的。要是只有一套身份提权操作就彻底没法追责了。其二是回退。带 SUID 的程序执行完敏感动作之后必须立刻把 EUID 降回真实UID否则后续代码一旦出漏洞攻击者就白捡一个高权限进程。这就是最小权限原则在进程内部的具体落地也是sudo、su、passwd这类程序源码里反复出现seteuid(getuid())的原因。其三是身份校验。有些程序会在关键操作前核对getuid()和geteuid()是否一致不一致就说明自己正跑在提权状态可以据此拒绝某些危险请求。这种自我检查写法在老牌的邮件、打印类程序里很常见。3. SUID临时借用程序主人的身份3.1 passwd 为什么必须带 SUID回到开头那个困惑。/etc/shadow的权限一般是---------- 1 root shadow普通用户连读都读不了。可passwd命令由普通用户执行却能把新密码哈希写进去唯一合理的解释是passwd这个二进制文件身上带着 SUID 位属主是 root。执行ls -l $(which passwd)会看到类似这样的输出-rwsr-xr-x. 1 root root 32688 ... /usr/bin/passwd注意属主那三位里的s它顶替了原本x的位置表示这个文件可执行且执行时把进程的 EUID 设为文件所有者。进程起来之后 EUID 变成 0瞬间具备写/etc/shadow的能力写完密码程序内部把 EUID 降回调用者的真实UID继续以普通身份跑完剩下的流程。这套设计的关键在于提权窗口被压缩到极小的一段代码里而且这段代码是精心写过的只做校验旧密码 写新哈希这一件事不接受外部传入的任意文件路径。假如passwd允许用户指定要写的文件名那 SUID 就成了一个巨大的提权后门。用数字方式设置 SUID 位是在常规三位权限前面加一位4chmod 4755 ./mytool # 等价于 chmod us ./mytool ls -l ./mytool # 输出 -rwsr-xr-x如果文件本身没有执行权限chmod us之后的显示会是大写的S-rwSr--r-- 1 user user ... mytool大写S表示SUID位设了但没有执行权限这种情况下 SUID 完全不生效因为不执行就不会有进程没有进程就无从谈起进程身份。我见过不少人排查半天最后发现是忘了chmod x。3.2 SUID 生效的三个硬性条件SUID 不是设了就一定管用至少三个条件得同时满足缺一个都会静默失效而且不会有任何报错特别容易误判。第一个条件文件系统不能以nosuid挂载。很多发行版出于安全考虑会对/tmp、/home、/run/user等目录所在的分区加上nosuid选项。挂载信息看findmnt或mount输出里的选项列看到nosuid就说明这个分区上的 SUID 位形同虚设。我最初在家目录里做实验chmod us后程序照样以普通身份运行折腾了半小时才发现是/home的挂载选项在作怪。把实验挪到/opt或/usr/local下就正常了。第二个条件文件的所有者必须是目标身份。SUID 借的是文件所有者的身份如果所有者是你自己那 EUID 从 1000 变成 1000什么也没发生。只有所有者是 root或其他需要借用的账号且你有权限执行时才有意义。当然普通用户也没法随便把文件所有者改成 root这本身又是一层保护。第三个条件执行链路得是真正的execve调用。内核只在execve加载可执行文件的那一刻处理 SUID 位。任何绕过execve的方式比如让解释器读取脚本内容再逐行执行都不会触发 SUID 逻辑。这一点是下一小节的重点。提示nosuid是排查 SUID 失效的第一怀疑对象其次是文件是否真带执行位。第三顺位才去怀疑程序自身逻辑。3.3 为什么给脚本加 SUID 没用这是被问得最多的问题之一写了个 bash 脚本chmod us执行后发现id -u还是自己的UID。答案很干脆——Linux 内核故意不支持脚本上的 SUID。原因在于脚本的执行方式。你敲./script.sh时内核看到文件头是#!/bin/bash于是它去加载/bin/bash这个二进制把脚本路径作为参数传给它。真正被execve加载的可执行文件是bash而不是脚本内核处理 SUID 时看的是bash的权限位——而bash当然没有 SUID 位。脚本本身的s位在这个过程中完全被忽略。有人会想到直接bash script.sh或者source script.sh这两种方式连execve都可能不走更不可能触发 SUID。还有人想到把脚本编译成二进制这倒是可行但把 shell 逻辑塞进C程序里通常得不偿失。真需要脚本以别的身份跑正路只有两条一是用sudo配置精细到命令和参数的授权规则让特定用户能免密执行某个脚本这是最常见也最可控的做法二是把脚本核心逻辑改写成C程序自己处理好seteuid的升降明确在什么时机提权、什么时机降回。第二种做法成本高只在有强需求时考虑。顺带说个相关坑有些系统上你想让脚本带上 SGID 来继承属组同样无效原因一模一样。目录上的 SGID 是另一码事那个是真有效后面单独讲。3.4 SUID 的安全隐患与排查思路SUID 本质上是把一个以高权限运行的入口交给了普通用户风险等级自然高。历史上大量本地提权问题都出在这类程序上。常见的风险模式有三类值得每个管机器的人心里有数。第一类是参数注入。程序接受用户输入并拼接成命令或路径一旦没做严格校验就能被诱导去执行不该执行的东西。第二类是环境变量污染。老程序如果没清理LD_PRELOAD、PATH这类变量攻击者可以借机加载自己的库。现代发行版对 SUID 程序做了环境变量清洗但老程序不一定享受到。第三类是功能过宽。一个 SUID 程序如果顺带提供了读取任意文件的调试选项那它基本等于把 root 读权限公开了。排查思路是从清单开始而不是从怀疑开始。先把系统上所有带 SUID 和 SGID 的文件列出来心里有数之后再逐个评估find / -xdev \( -perm -4000 -o -perm -2000 \) -type f -printf %m %u %g %p\n 2/dev/null | sort-xdev的作用是不跨文件系统避免扫到网络挂载和移动设备上耗时太久。加上2/dev/null屏蔽掉那些没权限进入的目录报出的错误输出会清爽很多。把这份清单存下来定期对比出现新增文件就该警觉。-perm -4000里的减号很关键意思是至少包含这一位而不是精确等于。如果写成-perm 4000那就只能匹配权限位恰好是4000的文件实际一个都找不到。4. SGID比 SUID 低调但用处更广4.1 文件上的 SGID借用属组身份文件上的 SGID 和 SUID 是一个套路只是换成了组执行时把进程的 EGID 设为文件属组。设置方式是数字前加2chmod 2755 ./mytool # 或 chmod gs ./mytool ls -l ./mytool # 输出 -rwxr-sr-x有个容易混淆的地方文件带 SGID 但属主位没有x时显示为大写S属组位没有执行权限同样显示大写S。判断是否真正生效先看有没有执行位再看挂载选项。实际场景里文件级 SGID 用得比 SUID 少得多但也确实有它的位置。比如某个程序需要读取只有特定组才能访问的数据文件你可以让这个程序属于那个组并带上 SGID这样任何能执行它的人都能临时获得组的读取能力而不用把每个人塞进那个组。这也是一种最小授权只不过粒度从用户变成了组。同样的nosuid限制适用同样的脚本无效规则适用。这三个坑在 SUID 上踩过一次SGID 上就不会再踩第二次。4.2 目录上的 SGID团队共享目录的标准解法这个用法才是 SGID 真正发光的地方也是我日常配置里用得最多的一个特性。把它设在目录上含义完全变了在这个目录里新建的文件和子目录属组会自动继承目录的属组而不是创建者的主组。同时新建的子目录会自动继承 SGID 位。场景很好理解三个人协作都加入了devteam组共同维护/srv/project目录。如果什么都不做A 创建的文件属组是 A 的主组B 创建的是 B 的主组两个人互相都改不了对方的文件共享目录形同虚设。给目录加上 SGID 之后不管谁创建文件的属组统一是devteam配合组的读写权限协作就顺了。设置命令和验证sudo mkdir -p /srv/project sudo chgrp devteam /srv/project sudo chmod 2775 /srv/project ls -ld /srv/project # drwxrwsr-x 2 root devteam 4096 ... /srv/project属组三位出现s就说明 SGID 生效了。之后任何成员在其中创建文件ls -l看到的属组都会是devteam。这一步很多人只做了一半——目录权限设了但umask没管结果新文件默认权限是644同组人只有读没有写一样改不动。4.3 实操把多人协作目录配到位完整流程我按顺序列一遍每一步都有它的道理别跳。第一步建组加人。组名按项目起成员用usermod -aG追加sudo groupadd devteam sudo usermod -aG devteam alice sudo usermod -aG devteam bob注意-a不能省省了就会把人从其他附加组里踢出去只剩这一个组。这个坑我踩过把某个账号从docker组里挤掉事后查了半天。第二步设目录属组和权限位sudo chgrp devteam /srv/project sudo chmod 2775 /srv/project2775拆开看2是 SGID775是属主和属组读写执行、其他人读执行。如果目录里还需要别人能进入但不能列目录可以把最后一位改成0变成2770。第三步处理umask。默认umask 022会让新文件权限是644、新目录是755组内成员对文件没有写权限。要在该目录下协作成员需要把umask设成002这样新文件是664、新目录是775。设置方式可以是个人~/.bashrc里加一行umask 002也可以在共享 shell 配置里针对组内成员统一处理。第四步验证。用两个不同账号各建一个文件看属组touch /srv/project/a.txt ls -l /srv/project/a.txt如果属组显示devteam说明 SGID 起作用了如果显示创建者主组回头检查目录权限位上的s有没有真的出现以及目录所在分区有没有nosuid挂载。注意SGID 目录只影响新建的对象历史文件的属组不会自动修正。迁移旧数据时得用chgrp -R手动刷一遍。4.4 顺带说说粘滞位别和 SGID 搞混/tmp目录的权限是drwxrwxrwt最后那个t是粘滞位sticky bit数字表示是1组合起来就是1777。它的作用是目录里所有人可写但只有文件所有者、目录所有者或 root 才能删除或重命名别人的文件。这个特性常被和 SGID 一起提因为三个特殊位挤在同一个位置显示。s出现在属主位是 SUID出现在属组位是 SGIDt出现在其他人位是粘滞位。三者可以叠加一个目录权限写成3775就是 SGID 加粘滞位。粘滞位解决的是共享目录互相删文件的问题SGID 解决的是共享目录属组不统一的问题两者经常搭配使用。比如团队共享目录可以设成3775新建文件属组统一继承同时谁也不能删别人的东西只在确有必要时由管理员介入。5. 完整实操亲手验证每个ID的变化5.1 准备一个干净的实验环境理论说再多不如跑一遍。准备一个不在nosuid分区下的目录/opt/lab就挺合适sudo mkdir -p /opt/lab sudo chown $(id -u):$(id -g) /opt/lab cd /opt/lab findmnt -no OPTIONS -T /opt/lab最后一条命令输出该目录所在挂载点的选项确认里面没有nosuid。这一步别省我见过太多实验失败其实是环境问题。顺手准备一个打印身份的C程序后面所有验证都靠它/* idtest.c */ #include stdio.h #include unistd.h int main(void) { printf(real uid%d gid%d\n, getuid(), getgid()); printf(effective uid%d gid%d\n, geteuid(), getegid()); FILE *fp fopen(/proc/self/status, r); if (fp) { char line[256]; while (fgets(line, sizeof line, fp)) if (line[0] U || line[0] G) if (line[1] i || line[1] d) fputs(line, stdout); fclose(fp); } return 0; }编译并跑一次基线gcc -o idtest idtest.c ./idtest输出里四列数字应该完全一致全是你的UID和GID。5.2 给程序加上 SUID 观察变化sudo chown root:root idtest sudo chmod 4755 idtest ls -l idtest ./idtest第二行命令把所有者改成 root只有 root 才有权限改所以得用sudo。ls -l应该看到-rwsr-xr-x。执行之后real uid还是你的号码effective uid变成 0/proc/self/status里的四列会呈现1000 0 0 0这样的组合不同内核版本保存位可能有差异但前两列的分裂是确定的。这个输出就是全部秘密的具象化真实身份没变有效身份被临时借走了。程序内部如果调用seteuid(getuid())effective uid会立刻回到 1000后面的代码就以普通身份运行。5.3 验证 SGID 在目录上的继承效果mkdir -p /opt/lab/shared chmod 2775 /opt/lab/shared touch /opt/lab/shared/test.txt ls -ld /opt/lab/shared ls -l /opt/lab/shared/test.txt先看目录权限位上的s在不在再看test.txt的属组是不是和目录一致。如果你自己就是目录所有者属组大概率本来就一致看不出差异这时候换一个账号或者先chgrp到别的组再测效果才明显。再往下挖一层验证子目录继承mkdir /opt/lab/shared/sub ls -ld /opt/lab/shared/sub子目录的权限位里也应该带s这是 SGID 目录的递归特性。这个特性在搭建多层级项目目录时特别省事不用一层层手动设。5.4 用脚本做一次全盘权限审计机器上的特殊权限文件最怕的是不知道什么时候多出来一个。定期跑一遍清单输出到文件里对比成本很低#!/bin/bash # perms-audit.sh OUT/var/log/perms-$(date %F).log find / -xdev \( -perm -4000 -o -perm -2000 -o -perm -1000 \) -type f \ -printf %m %u %g %p\n 2/dev/null | sort $OUT diff /var/log/perms-last.log $OUT 2/dev/null cp -f $OUT /var/log/perms-last.log三个-perm条件分别覆盖 SUID、SGID、粘滞位。-printf输出权限数字、所有者、属组、路径四列比ls -l更适合做文本对比。diff那行会直接告诉你和上次相比新增或消失了哪些条目空输出就代表没变化。把这个脚本挂进定时任务每天跑一次出现异常条目时邮件告警。这套机制的价值不在发现已知问题而在及时发现未知变化——某个被利用的账号悄悄给一个可执行文件加了 SUID靠人肉检查基本发现不了靠对比清单就是一目了然。6. 常见问题与排查清单6.1 问题速查表把日常碰到的现象、原因、处理方式整理成一张表遇到问题先对号入座能省掉大半时间现象最可能的原因处理方向加了 SUID 但 EUID 没变文件在nosuid分区用findmnt查挂载选项换目录加了 SUID 但 EUID 没变脚本不是二进制改写成C程序或用精细授权方案显示-rwSr--r--大写S缺执行权限chmod x补齐SUID 程序执行报 Permission denied所有x位都被去掉至少开一个执行位共享目录新建文件属组不对目录没设 SGIDchmod gs并核对显示属组对了但还是改不了umask让组无写权限协作成员统一umask 002属主自己反而进不了目录属主位权限被收紧属组不参与判定恢复属主位的xfind -perm 4000什么都找不到用成了精确匹配改成-perm -4000这张表里前两行是最高频的基本占了我在群里被问到的八成。第三、四行属于配置了一半也很常见。第五到第七行集中在共享目录场景是团队协作问题的常客。6.2 几个只有踩过才知道的细节说几个文档里不太写、但实际会撞上的点。第一个chmod us和chmod 4755效果一样但心理感受不同。用符号方式描述意图更清晰用数字方式更精确、更适合写进自动化脚本。我现在的习惯是手工调试用符号脚本里一律用数字避免符号写法在不同权限组合下产生意外。第二个cp复制一个带 SUID 的文件目标文件的 SUID 位通常不会被保留。这既安全又反直觉很多人备份完发现权限没了就是这个原因。要保留特殊位得显式加参数或者事后再chmod。反过来tar打包解包是保留这些位的所以拿别人的备份包解压时得多留个心眼。第三个修改 SUID 文件的内容会自动清掉 SUID 位。这是内核的保护机制——既然内容变了就不能再信任它借用身份的能力。编辑完发现权限没了不用怀疑人生重新chmod即可。这也解释了为什么升级系统包之后某些特殊权限需要包管理器重新设置。第四个newgrp能切换当前 shell 的有效GID但它是开一个子 shell不是改当前进程。切完之后id -g变了exit退出又回来了。临时需要以某个组身份操作时挺好用别指望它永久生效。第五个附加组信息的读取是有时效的。往组里加人之后对方已经登录的会话不会立刻感知需要重新登录或者用newgrp刷新。给同事配完权限对方说还是不行八成是这个原因让对方重登一次就好。6.3 我的配置原则折腾这些年权限这块我给自己定了三条规矩简单但管用。能不用 SUID 就不用。确实需要提升权限执行某个动作时优先考虑把动作拆出来做成一个服务用固定的低权限账号运行再通过受控接口调用其次是精细化的授权规则限定到具体命令和参数实在绕不开才在二进制上加 SUID。每一次能用 SUID 就用了的选择都是在给未来的自己埋一个需要审计的坑。SGID 目录优先于手动chgrp。只要是多人在同一目录里写东西第一反应就是把目录的 SGID 设上而不是事后定期跑脚本去刷属组。前者一劳永逸后者永远在补漏而且总有忘记跑的几天。权限清单常备。系统里有哪些特殊的权限文件我心里得有个数。这个数不是靠记忆是靠每天自动生成的那份清单。有了基线任何新增都是信号没有基线所有异常都是背景噪音。这套东西学起来一开始会绕但一旦把真实身份负责追溯、有效身份负责判定、特殊位负责临时借用这三句话捋顺后面所有现象都能自己推出来。我在实际配置中最深的体会是几乎所有的权限事故都不是因为规则太复杂而是因为少设了一个位、少确认了一次挂载选项或者少问了对方一句你重新登录了吗。
1. 先搞清几个ID的关系1.1 从一次我能改密码却读不了密码文件的困惑说起刚接触Linux那会儿我碰到过一个特别拧巴的现象用普通账号执行passwd改自己的登录密码一路顺畅系统把新密码写进了/etc/shadow可同一时刻我cat /etc/shadow却被一句Permission denied挡在门外。当时第一反应是系统是不是搞错了——既然我的账号能写这个文件凭什么连读都不让读后来才明白这背后是 UID、GID、EUID、EGID 这几个身份标识在分工再加上 SUID、SGID 这两位临时授权开关在背后做手脚。这件事几乎把Linux权限体系里最容易混淆的一整套概念串了起来真实身份是谁、当前生效身份是谁、程序执行时借用了谁的身份、目录里新建的文件归谁所有。这套东西听着抽象实际每天都在影响你为什么同一台机器上两个同事往同一个目录里丢文件过两天谁的都改不动为什么下载来的一个二进制程序一执行就是Permission denied为什么自己写的脚本加了chmod us却一点效果都没有。把这些ID搞明白这些问题基本都能在三分钟内定位。这篇内容适合三类人刚学Linux命令、被权限报错反复折磨的新手需要部署服务、给程序配权限的运维和开发以及想系统补一遍权限模型底层的进阶读者。我会从概念一点点推到实操验证给出可直接复现的命令和程序顺手把踩过的坑都摊开讲。1.2 四个ID的角色分工真实身份与临时身份先把最容易被混为一谈的四位请出来。UIDUser ID是用户的数字身份GIDGroup ID是用户所属主组的数字身份这两个是你是谁的档案记录存在/etc/passwd和/etc/group里id命令一敲就能看到。EUIDEffective UID和 EGIDEffective GID则是你此刻说话算不算数的凭据——内核在判断一个进程能不能读某个文件时看的是有效身份不是真实身份。打个生活化的比方UID 是你的身份证EUID 是你当天戴的工牌。平时两者是同一张脸你去食堂打饭刷工牌就行但某些特殊岗位上公司会临时发你一张代理工牌让你在这一个任务里拥有那个岗位的权限任务结束工牌收回你还是你。SUID 干的就是发代理工牌这件事。为什么非得搞两套身份因为记录我是谁和判断我能干什么是两回事。真实身份需要稳定、可审计、不能被程序随意篡改有效身份需要灵活允许在受控范围内临时切换。把两者分开才能既保证追溯性日志里记的永远是真实UID又保证功能可实现临时提权完成特定动作。还有两个常被忽略的成员保存的设置用户IDsaved set-user-ID和文件系统用户IDfsuid。前者是给seteuid预留的后悔药允许进程在提权和降权之间来回横跳后者主要在网络文件系统场景下参与访问判定日常排查碰到的概率不高但读/proc/self/status时会看到它别被吓到。1.3 一条命令看清进程身上的全部身份不用猜内核把每个进程的身份都摊在/proc里了。执行下面这条命令Uid那一行会有四个数字从左到右分别是真实UID、有效UID、保存UID、文件系统UIDGid行同理grep -E ^(Uid|Gid): /proc/self/status普通用户下典型输出是这样Uid: 1000 1000 1000 1000 Gid: 1000 1000 1000 1000四个数字完全一样说明当前 shell 没有任何提权动作。等你执行一个带 SUID 位的程序那个进程的四个数字就会开始分家。这个观察方法比看任何文档都直观我在排查权限问题时基本第一步就是抓这四列数字。再多说一句id命令的用法它能一次性把身份信息铺开id # 当前有效身份 id -r # 只看真实身份 id -u; id -g; id -G # 分别取UID、主GID、全部附加组GIDid -G那串数字很多人不当回事其实它直接决定了你能否访问属组为某个附加组的文件。用户除了主组还能被塞进十几个附加组这些组的GID全都参与权限判定后面讲权限比对顺序时会再提。2. 从进程视角看权限判定2.1 内核到底比对了什么理解权限判定最省事的办法是把自己当成内核手里拿着两样东西进程的有效身份EUID EGID 附加组列表以及目标文件的元数据所有者UID、属组GID、权限位rwxrwxrwx。剩下的事就是三次比对。第一次比所有者进程的 EUID 是否等于文件的 UID相等就用文件权限位的第1组属主三位来决定放行还是拒绝而且不管结果如何比对到此结束不会再去试组权限。这一点非常关键很多人以为属主不行再试试属组实际不是属主匹配是排他的。第二次比属组EUID 对不上就看进程的 EGID 和附加组列表里有没有任何一个等于文件的 GID。匹配上就用第2组属组三位判定同样排他不再往下走。第三次兜底前面都不匹配才用第3组其他人三位。如果这组权限也不够内核返回EACCES也就是你看到的那句Permission denied。这个顺序解释了为什么会出现文件所有者权限是---但属组权限是rwx所有者本人反而读不了的怪现象。不是bug是设计如此。我在给共享目录配权限时就栽过这个跟头为了收紧权限把属主位设成---结果文件创建者自己进不去。2.2 root 为什么也受这套规则约束有个流传很广的说法叫root 无敌严格讲不准确。root 的 EUID 是 0内核在权限检查里对 0 做了特殊放行只要 EUID 为 0读、写、进入目录基本都允许但仍然有几处例外。第一个例外是执行权限。一个文件如果没有对任何人开放x位root 也执行不了它会得到Permission denied。想执行必须至少有一个x位存在。第二个例外是写一个设置了不可变属性的文件或者写只读挂载的文件系统root 也拦不住内核的拒绝。第三个例外是root 想读一个属主不是自己、且所有r位都被去掉的普通文件在部分内核配置下依然能读但这不是可以依赖的行为别拿它当权限设计依据。真正的结论是root 的强权来自 EUID 为 0 这个特殊判断而不是跳过所有检查。理解这一点之后你再看 SUID 程序的行为会顺很多——SUID 的本质就是把进程的 EUID 改成文件所有者的UID如果文件所有者恰好是 root那么这个进程就获得了和 root 同等的判定待遇。2.3 真实身份为什么必须保留既然内核只看 EUID那真实UID留着干嘛主要有三个用途每一个都很实在。其一是审计。系统日志、进程记账、ps输出里记录的用户身份都以真实UID为准。一个普通用户执行了带 SUID 的程序进程里 EUID 变成了 0但真实UID还是 1000日志里仍然能追溯到这个操作是 1000 号用户发起的。要是只有一套身份提权操作就彻底没法追责了。其二是回退。带 SUID 的程序执行完敏感动作之后必须立刻把 EUID 降回真实UID否则后续代码一旦出漏洞攻击者就白捡一个高权限进程。这就是最小权限原则在进程内部的具体落地也是sudo、su、passwd这类程序源码里反复出现seteuid(getuid())的原因。其三是身份校验。有些程序会在关键操作前核对getuid()和geteuid()是否一致不一致就说明自己正跑在提权状态可以据此拒绝某些危险请求。这种自我检查写法在老牌的邮件、打印类程序里很常见。3. SUID临时借用程序主人的身份3.1 passwd 为什么必须带 SUID回到开头那个困惑。/etc/shadow的权限一般是---------- 1 root shadow普通用户连读都读不了。可passwd命令由普通用户执行却能把新密码哈希写进去唯一合理的解释是passwd这个二进制文件身上带着 SUID 位属主是 root。执行ls -l $(which passwd)会看到类似这样的输出-rwsr-xr-x. 1 root root 32688 ... /usr/bin/passwd注意属主那三位里的s它顶替了原本x的位置表示这个文件可执行且执行时把进程的 EUID 设为文件所有者。进程起来之后 EUID 变成 0瞬间具备写/etc/shadow的能力写完密码程序内部把 EUID 降回调用者的真实UID继续以普通身份跑完剩下的流程。这套设计的关键在于提权窗口被压缩到极小的一段代码里而且这段代码是精心写过的只做校验旧密码 写新哈希这一件事不接受外部传入的任意文件路径。假如passwd允许用户指定要写的文件名那 SUID 就成了一个巨大的提权后门。用数字方式设置 SUID 位是在常规三位权限前面加一位4chmod 4755 ./mytool # 等价于 chmod us ./mytool ls -l ./mytool # 输出 -rwsr-xr-x如果文件本身没有执行权限chmod us之后的显示会是大写的S-rwSr--r-- 1 user user ... mytool大写S表示SUID位设了但没有执行权限这种情况下 SUID 完全不生效因为不执行就不会有进程没有进程就无从谈起进程身份。我见过不少人排查半天最后发现是忘了chmod x。3.2 SUID 生效的三个硬性条件SUID 不是设了就一定管用至少三个条件得同时满足缺一个都会静默失效而且不会有任何报错特别容易误判。第一个条件文件系统不能以nosuid挂载。很多发行版出于安全考虑会对/tmp、/home、/run/user等目录所在的分区加上nosuid选项。挂载信息看findmnt或mount输出里的选项列看到nosuid就说明这个分区上的 SUID 位形同虚设。我最初在家目录里做实验chmod us后程序照样以普通身份运行折腾了半小时才发现是/home的挂载选项在作怪。把实验挪到/opt或/usr/local下就正常了。第二个条件文件的所有者必须是目标身份。SUID 借的是文件所有者的身份如果所有者是你自己那 EUID 从 1000 变成 1000什么也没发生。只有所有者是 root或其他需要借用的账号且你有权限执行时才有意义。当然普通用户也没法随便把文件所有者改成 root这本身又是一层保护。第三个条件执行链路得是真正的execve调用。内核只在execve加载可执行文件的那一刻处理 SUID 位。任何绕过execve的方式比如让解释器读取脚本内容再逐行执行都不会触发 SUID 逻辑。这一点是下一小节的重点。提示nosuid是排查 SUID 失效的第一怀疑对象其次是文件是否真带执行位。第三顺位才去怀疑程序自身逻辑。3.3 为什么给脚本加 SUID 没用这是被问得最多的问题之一写了个 bash 脚本chmod us执行后发现id -u还是自己的UID。答案很干脆——Linux 内核故意不支持脚本上的 SUID。原因在于脚本的执行方式。你敲./script.sh时内核看到文件头是#!/bin/bash于是它去加载/bin/bash这个二进制把脚本路径作为参数传给它。真正被execve加载的可执行文件是bash而不是脚本内核处理 SUID 时看的是bash的权限位——而bash当然没有 SUID 位。脚本本身的s位在这个过程中完全被忽略。有人会想到直接bash script.sh或者source script.sh这两种方式连execve都可能不走更不可能触发 SUID。还有人想到把脚本编译成二进制这倒是可行但把 shell 逻辑塞进C程序里通常得不偿失。真需要脚本以别的身份跑正路只有两条一是用sudo配置精细到命令和参数的授权规则让特定用户能免密执行某个脚本这是最常见也最可控的做法二是把脚本核心逻辑改写成C程序自己处理好seteuid的升降明确在什么时机提权、什么时机降回。第二种做法成本高只在有强需求时考虑。顺带说个相关坑有些系统上你想让脚本带上 SGID 来继承属组同样无效原因一模一样。目录上的 SGID 是另一码事那个是真有效后面单独讲。3.4 SUID 的安全隐患与排查思路SUID 本质上是把一个以高权限运行的入口交给了普通用户风险等级自然高。历史上大量本地提权问题都出在这类程序上。常见的风险模式有三类值得每个管机器的人心里有数。第一类是参数注入。程序接受用户输入并拼接成命令或路径一旦没做严格校验就能被诱导去执行不该执行的东西。第二类是环境变量污染。老程序如果没清理LD_PRELOAD、PATH这类变量攻击者可以借机加载自己的库。现代发行版对 SUID 程序做了环境变量清洗但老程序不一定享受到。第三类是功能过宽。一个 SUID 程序如果顺带提供了读取任意文件的调试选项那它基本等于把 root 读权限公开了。排查思路是从清单开始而不是从怀疑开始。先把系统上所有带 SUID 和 SGID 的文件列出来心里有数之后再逐个评估find / -xdev \( -perm -4000 -o -perm -2000 \) -type f -printf %m %u %g %p\n 2/dev/null | sort-xdev的作用是不跨文件系统避免扫到网络挂载和移动设备上耗时太久。加上2/dev/null屏蔽掉那些没权限进入的目录报出的错误输出会清爽很多。把这份清单存下来定期对比出现新增文件就该警觉。-perm -4000里的减号很关键意思是至少包含这一位而不是精确等于。如果写成-perm 4000那就只能匹配权限位恰好是4000的文件实际一个都找不到。4. SGID比 SUID 低调但用处更广4.1 文件上的 SGID借用属组身份文件上的 SGID 和 SUID 是一个套路只是换成了组执行时把进程的 EGID 设为文件属组。设置方式是数字前加2chmod 2755 ./mytool # 或 chmod gs ./mytool ls -l ./mytool # 输出 -rwxr-sr-x有个容易混淆的地方文件带 SGID 但属主位没有x时显示为大写S属组位没有执行权限同样显示大写S。判断是否真正生效先看有没有执行位再看挂载选项。实际场景里文件级 SGID 用得比 SUID 少得多但也确实有它的位置。比如某个程序需要读取只有特定组才能访问的数据文件你可以让这个程序属于那个组并带上 SGID这样任何能执行它的人都能临时获得组的读取能力而不用把每个人塞进那个组。这也是一种最小授权只不过粒度从用户变成了组。同样的nosuid限制适用同样的脚本无效规则适用。这三个坑在 SUID 上踩过一次SGID 上就不会再踩第二次。4.2 目录上的 SGID团队共享目录的标准解法这个用法才是 SGID 真正发光的地方也是我日常配置里用得最多的一个特性。把它设在目录上含义完全变了在这个目录里新建的文件和子目录属组会自动继承目录的属组而不是创建者的主组。同时新建的子目录会自动继承 SGID 位。场景很好理解三个人协作都加入了devteam组共同维护/srv/project目录。如果什么都不做A 创建的文件属组是 A 的主组B 创建的是 B 的主组两个人互相都改不了对方的文件共享目录形同虚设。给目录加上 SGID 之后不管谁创建文件的属组统一是devteam配合组的读写权限协作就顺了。设置命令和验证sudo mkdir -p /srv/project sudo chgrp devteam /srv/project sudo chmod 2775 /srv/project ls -ld /srv/project # drwxrwsr-x 2 root devteam 4096 ... /srv/project属组三位出现s就说明 SGID 生效了。之后任何成员在其中创建文件ls -l看到的属组都会是devteam。这一步很多人只做了一半——目录权限设了但umask没管结果新文件默认权限是644同组人只有读没有写一样改不动。4.3 实操把多人协作目录配到位完整流程我按顺序列一遍每一步都有它的道理别跳。第一步建组加人。组名按项目起成员用usermod -aG追加sudo groupadd devteam sudo usermod -aG devteam alice sudo usermod -aG devteam bob注意-a不能省省了就会把人从其他附加组里踢出去只剩这一个组。这个坑我踩过把某个账号从docker组里挤掉事后查了半天。第二步设目录属组和权限位sudo chgrp devteam /srv/project sudo chmod 2775 /srv/project2775拆开看2是 SGID775是属主和属组读写执行、其他人读执行。如果目录里还需要别人能进入但不能列目录可以把最后一位改成0变成2770。第三步处理umask。默认umask 022会让新文件权限是644、新目录是755组内成员对文件没有写权限。要在该目录下协作成员需要把umask设成002这样新文件是664、新目录是775。设置方式可以是个人~/.bashrc里加一行umask 002也可以在共享 shell 配置里针对组内成员统一处理。第四步验证。用两个不同账号各建一个文件看属组touch /srv/project/a.txt ls -l /srv/project/a.txt如果属组显示devteam说明 SGID 起作用了如果显示创建者主组回头检查目录权限位上的s有没有真的出现以及目录所在分区有没有nosuid挂载。注意SGID 目录只影响新建的对象历史文件的属组不会自动修正。迁移旧数据时得用chgrp -R手动刷一遍。4.4 顺带说说粘滞位别和 SGID 搞混/tmp目录的权限是drwxrwxrwt最后那个t是粘滞位sticky bit数字表示是1组合起来就是1777。它的作用是目录里所有人可写但只有文件所有者、目录所有者或 root 才能删除或重命名别人的文件。这个特性常被和 SGID 一起提因为三个特殊位挤在同一个位置显示。s出现在属主位是 SUID出现在属组位是 SGIDt出现在其他人位是粘滞位。三者可以叠加一个目录权限写成3775就是 SGID 加粘滞位。粘滞位解决的是共享目录互相删文件的问题SGID 解决的是共享目录属组不统一的问题两者经常搭配使用。比如团队共享目录可以设成3775新建文件属组统一继承同时谁也不能删别人的东西只在确有必要时由管理员介入。5. 完整实操亲手验证每个ID的变化5.1 准备一个干净的实验环境理论说再多不如跑一遍。准备一个不在nosuid分区下的目录/opt/lab就挺合适sudo mkdir -p /opt/lab sudo chown $(id -u):$(id -g) /opt/lab cd /opt/lab findmnt -no OPTIONS -T /opt/lab最后一条命令输出该目录所在挂载点的选项确认里面没有nosuid。这一步别省我见过太多实验失败其实是环境问题。顺手准备一个打印身份的C程序后面所有验证都靠它/* idtest.c */ #include stdio.h #include unistd.h int main(void) { printf(real uid%d gid%d\n, getuid(), getgid()); printf(effective uid%d gid%d\n, geteuid(), getegid()); FILE *fp fopen(/proc/self/status, r); if (fp) { char line[256]; while (fgets(line, sizeof line, fp)) if (line[0] U || line[0] G) if (line[1] i || line[1] d) fputs(line, stdout); fclose(fp); } return 0; }编译并跑一次基线gcc -o idtest idtest.c ./idtest输出里四列数字应该完全一致全是你的UID和GID。5.2 给程序加上 SUID 观察变化sudo chown root:root idtest sudo chmod 4755 idtest ls -l idtest ./idtest第二行命令把所有者改成 root只有 root 才有权限改所以得用sudo。ls -l应该看到-rwsr-xr-x。执行之后real uid还是你的号码effective uid变成 0/proc/self/status里的四列会呈现1000 0 0 0这样的组合不同内核版本保存位可能有差异但前两列的分裂是确定的。这个输出就是全部秘密的具象化真实身份没变有效身份被临时借走了。程序内部如果调用seteuid(getuid())effective uid会立刻回到 1000后面的代码就以普通身份运行。5.3 验证 SGID 在目录上的继承效果mkdir -p /opt/lab/shared chmod 2775 /opt/lab/shared touch /opt/lab/shared/test.txt ls -ld /opt/lab/shared ls -l /opt/lab/shared/test.txt先看目录权限位上的s在不在再看test.txt的属组是不是和目录一致。如果你自己就是目录所有者属组大概率本来就一致看不出差异这时候换一个账号或者先chgrp到别的组再测效果才明显。再往下挖一层验证子目录继承mkdir /opt/lab/shared/sub ls -ld /opt/lab/shared/sub子目录的权限位里也应该带s这是 SGID 目录的递归特性。这个特性在搭建多层级项目目录时特别省事不用一层层手动设。5.4 用脚本做一次全盘权限审计机器上的特殊权限文件最怕的是不知道什么时候多出来一个。定期跑一遍清单输出到文件里对比成本很低#!/bin/bash # perms-audit.sh OUT/var/log/perms-$(date %F).log find / -xdev \( -perm -4000 -o -perm -2000 -o -perm -1000 \) -type f \ -printf %m %u %g %p\n 2/dev/null | sort $OUT diff /var/log/perms-last.log $OUT 2/dev/null cp -f $OUT /var/log/perms-last.log三个-perm条件分别覆盖 SUID、SGID、粘滞位。-printf输出权限数字、所有者、属组、路径四列比ls -l更适合做文本对比。diff那行会直接告诉你和上次相比新增或消失了哪些条目空输出就代表没变化。把这个脚本挂进定时任务每天跑一次出现异常条目时邮件告警。这套机制的价值不在发现已知问题而在及时发现未知变化——某个被利用的账号悄悄给一个可执行文件加了 SUID靠人肉检查基本发现不了靠对比清单就是一目了然。6. 常见问题与排查清单6.1 问题速查表把日常碰到的现象、原因、处理方式整理成一张表遇到问题先对号入座能省掉大半时间现象最可能的原因处理方向加了 SUID 但 EUID 没变文件在nosuid分区用findmnt查挂载选项换目录加了 SUID 但 EUID 没变脚本不是二进制改写成C程序或用精细授权方案显示-rwSr--r--大写S缺执行权限chmod x补齐SUID 程序执行报 Permission denied所有x位都被去掉至少开一个执行位共享目录新建文件属组不对目录没设 SGIDchmod gs并核对显示属组对了但还是改不了umask让组无写权限协作成员统一umask 002属主自己反而进不了目录属主位权限被收紧属组不参与判定恢复属主位的xfind -perm 4000什么都找不到用成了精确匹配改成-perm -4000这张表里前两行是最高频的基本占了我在群里被问到的八成。第三、四行属于配置了一半也很常见。第五到第七行集中在共享目录场景是团队协作问题的常客。6.2 几个只有踩过才知道的细节说几个文档里不太写、但实际会撞上的点。第一个chmod us和chmod 4755效果一样但心理感受不同。用符号方式描述意图更清晰用数字方式更精确、更适合写进自动化脚本。我现在的习惯是手工调试用符号脚本里一律用数字避免符号写法在不同权限组合下产生意外。第二个cp复制一个带 SUID 的文件目标文件的 SUID 位通常不会被保留。这既安全又反直觉很多人备份完发现权限没了就是这个原因。要保留特殊位得显式加参数或者事后再chmod。反过来tar打包解包是保留这些位的所以拿别人的备份包解压时得多留个心眼。第三个修改 SUID 文件的内容会自动清掉 SUID 位。这是内核的保护机制——既然内容变了就不能再信任它借用身份的能力。编辑完发现权限没了不用怀疑人生重新chmod即可。这也解释了为什么升级系统包之后某些特殊权限需要包管理器重新设置。第四个newgrp能切换当前 shell 的有效GID但它是开一个子 shell不是改当前进程。切完之后id -g变了exit退出又回来了。临时需要以某个组身份操作时挺好用别指望它永久生效。第五个附加组信息的读取是有时效的。往组里加人之后对方已经登录的会话不会立刻感知需要重新登录或者用newgrp刷新。给同事配完权限对方说还是不行八成是这个原因让对方重登一次就好。6.3 我的配置原则折腾这些年权限这块我给自己定了三条规矩简单但管用。能不用 SUID 就不用。确实需要提升权限执行某个动作时优先考虑把动作拆出来做成一个服务用固定的低权限账号运行再通过受控接口调用其次是精细化的授权规则限定到具体命令和参数实在绕不开才在二进制上加 SUID。每一次能用 SUID 就用了的选择都是在给未来的自己埋一个需要审计的坑。SGID 目录优先于手动chgrp。只要是多人在同一目录里写东西第一反应就是把目录的 SGID 设上而不是事后定期跑脚本去刷属组。前者一劳永逸后者永远在补漏而且总有忘记跑的几天。权限清单常备。系统里有哪些特殊的权限文件我心里得有个数。这个数不是靠记忆是靠每天自动生成的那份清单。有了基线任何新增都是信号没有基线所有异常都是背景噪音。这套东西学起来一开始会绕但一旦把真实身份负责追溯、有效身份负责判定、特殊位负责临时借用这三句话捋顺后面所有现象都能自己推出来。我在实际配置中最深的体会是几乎所有的权限事故都不是因为规则太复杂而是因为少设了一个位、少确认了一次挂载选项或者少问了对方一句你重新登录了吗。
