★ FEATURED ARTICLE 账号权限这件事很多人是在真正被卡住之后才开始认真对待的。我见过太多这样的情况平时一直用普通账号登录某天要装个服务、改个配置突然发现权限不够于是顺手sudo一下密码一敲事情办完下次继续。直到某天团队里来了新人你把账号借出去或者脚本里硬编码了 root 密码问题才开始一个个冒出来。这篇内容想聊的就是这条链路root 到底是个什么角色sudo 为什么比直接切 root 更值得推荐用户组又是怎么把一堆权限问题变得可控的。不管你是刚接触 Linux 的新手还是已经用了几年但一直靠sudo蒙混过关的老用户这里面的细节都值得重新过一遍。1. root 不是超级管理员这么简单1.1 root 的本质UID 0 与权限判定逻辑很多人对 root 的理解停留在最高权限这四个字上但真要说清楚它为什么能绕过一切限制得从 Linux 的权限判定机制讲起。Linux 里每个进程在运行时都带着一组身份标识核心是三个真实 UIDreal UID、有效 UIDeffective UID和保存的 UIDsaved UID。内核在做权限检查时看的是有效 UID而不是你登录时用的那个账号名。root 的特殊之处在于它的 UID 是 0。内核里大量的权限检查代码都长这样如果当前有效 UID 是 0直接放行否则再去比对文件属主、属组和其他权限位。也就是说root 并不是权限比别人多而是在很多检查点上被直接短路放行。这解释了为什么 root 能读一个权限为000的文件也能杀掉别的用户的进程——它压根没走那套比对流程。这里有个容易被忽略的点文件名、账号名都只是给人看的标签内核认的是数字。你把/etc/passwd里某个账号的 UID 改成 0那个账号就拥有了 root 的全部能力哪怕它叫alice。这也是为什么审计的时候不能只看谁叫 root而要看谁的 UID 是 0。我一般会顺手跑一句awk -F: $3 0 {print $1} /etc/passwd正常系统里应该只有一行root。如果多出来别的名字那就要警惕了要么是历史遗留的配置要么是有人刻意留了后门账号。1.2 为什么日常不该直接用 root 登录反正都要 sudo不如直接 root 登录省事——这个想法我理解但代价比想象中大。第一层代价是误操作不可逆。普通账号执行rm -rf /会被权限挡住大半root 执行就是真的删。第二层代价是审计信息丢失。多人共用 root 时日志里全是 root出了事根本追不到人。第三层是攻击面放大。一个以 root 身份运行的交互式 shell一旦被恶意程序注入攻击者直接拿到最高权限而普通账号被注入还得再想办法提权。我自己的习惯是root 账号只在单用户救援模式、或者极少数必须的初始化场景下用日常一律普通账号加 sudo。这不是教条是踩过坑之后的自然选择——有次在一台测试机上用 root 跑了个清理脚本路径变量写错把整个/var清空了恢复花了半天。如果当时是普通账号脚本第一步就报权限错误停下来了。1.3 root 的密码策略与锁定思路有些发行版默认允许 root 直接登录有些则把 root 密码设成一个无法匹配的占位值从而禁止密码登录。后者的做法是把/etc/shadow里 root 的密码字段设成!或*这样任何密码都验证不过。想临时启用可以passwd root设一个想再锁回去可以用passwd -l root-l是在密码哈希前加!属于锁定而非删除。这里有个细节值得说锁定 root 密码不影响 sudo。sudo 验证的是执行者自己的密码跟 root 密码没关系。所以锁了 root 密码会不会导致 sudo 用不了这个担心是多余的两者是独立的认证路径。提示锁定 root 密码前先确认至少有一个普通账号在 sudo 组里并且这个账号的密码是已知可用的。否则一旦锁上可能连提权通道都没了只能进救援模式。2. sudo 的工作机制它到底替你做了什么2.1 sudo 的认证流程拆解很多人把 sudo 当成临时变 root这个理解不算错但太粗。sudo 实际做的事是以当前用户身份启动读取/etc/sudoers判断这个用户能不能执行目标命令能的话再要求输入当前用户自己的密码注意不是 root 密码验证通过后 fork 一个子进程把子进程的有效 UID 切换成目标用户默认 root然后 exec 目标命令。这个流程里有几个关键设计。第一密码验证的是调用者本人这就保证了谁操作谁负责日志里能记到具体是谁。第二权限判定完全依赖配置文件而不是你是不是管理员这种模糊概念。第三默认有时间戳缓存验证成功后一段时间内通常是 5 分钟再执行 sudo 不用重复输密码这个缓存按终端tty隔离不同终端互不影响。时间戳缓存的位置各发行版略有差异常见在/run/sudo/ts/或/var/db/sudo/下。想立刻清掉缓存可以sudo -k这条命令在写自动化脚本时特别有用——你不想让脚本执行完后还留着一个有效的 sudo 凭证窗口。2.2 sudoers 文件的语法结构与安全编辑方式/etc/sudoers的语法看起来简单实际上手写很容易出错而且它有个语法错误就整体失效的特性一旦文件解析失败sudo 直接拒绝所有人包括原本有权限的管理员。所以永远不要直接用普通编辑器改它要用visudovisudo会在保存时做语法检查有问题直接拦下来让你改。如果习惯用别的编辑器可以EDITORvim visudo指定。生产环境里我还会额外做一件事改之前先备份一份到/etc/sudoers.bak改完用visudo -c单独校验一遍。sudoers 的一行规则大致长这样用户名 主机(目标用户:目标组) 命令列表举个具体的alice ALL(root) /usr/bin/systemctl restart nginx意思是 alice 在任何主机上可以以 root 身份执行重启 nginx 这一条命令。注意命令要写绝对路径因为 sudo 是按路径匹配的写systemctl这种相对名可能匹配不上或者被 PATH 里的同名程序钻空子。2.3 命令白名单的粒度控制与常见绕过风险给 sudo 配命令白名单粒度是个需要认真权衡的事。配得太宽等于变相给了 root配得太窄用户天天来找你加规则。我一般的做法是按最小必要来比如只允许重启特定服务、只允许查看特定日志目录。但这里有个大坑很多命令本身就能执行任意代码。你给了sudo vim用户就能在 vim 里:!bash拿到 root shell你给了sudo less用户能在 less 里!sh你给了sudo find用户能用-exec参数跑任意命令。所以白名单里绝对不能出现这类可逃逸的编辑器、分页器、解释器。如果确实需要给某个用户编辑特定配置文件的能力正确做法是用sudoedit或sudo -e它会把文件复制到临时目录让用户编辑保存时再以 root 身份写回用户全程拿不到 root shellalice ALL(root) sudoedit /etc/nginx/nginx.conf这个细节我在早期配置时完全没意识到直到有次做权限审计发现某个运维账号被给了sudo vim等于开了个后门才赶紧改掉。2.4 sudo 日志出问题后怎么追溯sudo 的日志默认走 syslog在基于 systemd 的系统上通常能在journalctl里看到也可以单独配一个日志文件。一条典型的 sudo 日志包含时间、主机名、执行者、目标用户、执行的命令、命令的完整参数、以及执行结果成功还是失败。排查权限相关问题时我习惯先看这几类记录谁在什么时间执行了 sudo、执行了什么、有没有失败记录。失败记录尤其值得关注——连续多次失败可能是有人在试探密码也可能是某个脚本配置错了在反复重试。journalctl -t sudo --since 1 hour ago如果想把 sudo 日志单独落到文件可以在 sudoers 里加一行Defaults logfile/var/log/sudo.log配合日志轮转长期留存审计线索。这里提醒一句日志文件本身的权限要收紧别让普通用户能改否则审计就失去意义了。3. 用户组把权限从个人变成角色3.1 主组与附加组一个用户能属于多个组Linux 里每个用户有一个主组primary group记在/etc/passwd的第四个字段还可以属于若干个附加组supplementary groups记在/etc/group里。新建文件时文件的属组默认取用户的主组而权限判定时用户的所有组主组加附加组都会被纳入考虑。这个设计的意义在于权限可以按角色分配而不是按个人分配。比如把几个需要管理 Docker 的人统一加进docker组就不用给每个人单独配规则。查看当前用户属于哪些组groups idid的输出更详细会列出 UID、主组 GID 和所有附加组 GID。这里有个常见困惑用户被加进新组之后为什么当前会话里groups看不到因为组成员关系是在登录时确定的已经打开的会话不会自动刷新。要么重新登录要么用newgrp切一下newgrp docker这个坑我踩过不止一次——给同事加完组对方说还是没权限一查是会话没刷新白折腾半天。3.2 关键系统组的职责划分系统里有一批预定义组各自承担特定职责理解它们能省很多事。下面这张表是我整理的高频组组名典型职责加入后的实际影响sudo / wheel允许通过 sudo 提权具体能执行什么仍由 sudoers 决定docker访问 Docker 守护进程套接字实质上等同于 root 权限需谨慎adm读取系统日志可查看 /var/log 下多数日志www-dataWeb 服务运行身份通常用于文件属组而非登录users普通用户集合影响不大主要是历史约定重点说docker组把用户加进 docker 组等于给了他通过 Docker 挂载宿主机根目录的能力进而拿到 root。所以这个组在安全审计里基本被视同 root 组加人之前要想清楚。sudo和wheel两个组名在不同发行版里用法不同Debian 系常用sudoRed Hat 系常用wheel配置时按实际发行版来。3.3 用组来批量管理权限的实操路径假设一个场景团队里有三个人需要读取应用日志目录/var/log/myapp但不该有写权限。最直接的做法是建一个组把目录属组设成它再给组读权限groupadd logreader usermod -aG logreader alice usermod -aG logreader bob usermod -aG logreader carol chgrp logreader /var/log/myapp chmod 750 /var/log/myapp这里usermod -aG的-a千万别漏。漏了-a会覆盖用户原有的附加组列表把人家之前加的所有组都清掉只留新加的这个。这个错误极其常见而且后果隐蔽——用户可能过几天才发现自己丢了某个组的权限。我现在的习惯是加组之前先id 用户名看一眼现状加完再确认一遍。目录权限设成750意味着属主可读写执行、属组可读执行、其他人无权限。如果日志文件本身也需要组可读还得确保文件创建时的默认权限配合必要时用umask或 ACL 调整。3.4 组权限的边界它解决不了的问题组机制很好用但它有明确的边界。第一一个用户能加入的附加组数量有上限受内核参数限制通常足够用但极端场景要注意。第二组权限是全有或全无的没法在组内再做细分——如果三个人里有一个只该读部分文件组机制就力不从心了这时候得上 ACL。ACL 的用法是setfacl和getfacl可以给单个用户或组针对单个文件设精细权限setfacl -m u:dave:r-- /var/log/myapp/app.log getfacl /var/log/myapp/app.log这条给 dave 单独加了读权限不影响其他人。ACL 适合处理例外情况主体权限还是用传统的属主/属组/其他三位比较清晰。混用的时候要注意ls -l看到的权限位末尾如果有说明这个文件带了 ACL得用getfacl才能看全。4. 从零搭一套可维护的权限方案4.1 账号与组的规划顺序搭权限方案最忌讳边用边加最后变成一团乱麻。我的建议是先规划再动手顺序大致是先定角色哪些人做哪些事再定组每个角色对应一个组然后建账号并归组最后配 sudo 规则。这个顺序的好处是每一步都有明确依据不会出现这个组当初为什么建的困惑。举个具体规划假设有三类人——运维、开发、只读审计。对应建三个组ops、dev、audit。运维需要重启服务和管理用户开发需要部署应用到特定目录审计只需要读日志。规划清楚之后sudoers 里就按组来写规则而不是按人写这样人员变动时只改组成员不动配置文件。4.2 用组驱动 sudoers 的写法按组写 sudo 规则核心是把规则里的用户字段换成%组名%ops ALL(root) /usr/bin/systemctl restart *, /usr/sbin/useradd %dev ALL(root) /usr/bin/systemctl restart myapp %audit ALL(root) /usr/bin/journalctl注意systemctl restart *这种通配要谨慎星号能匹配任意服务名等于放开了所有服务的重启权限。如果只想放开特定几个就逐个列出来。%前缀是 sudoers 里表示组的语法别写成或别的符号。写完之后用visudo -c校验再用一个测试账号实际跑一遍确认生效。我一般会准备一个专门的测试账号加进目标组验证该能执行的能执行、不该能执行的被拒确认无误再正式推广。4.3 验证与回归改完权限必须做的检查权限配置改完最怕的是以为生效了其实没有。验证要覆盖三个层面配置语法对不对、规则匹配是否符合预期、实际执行结果是否符合预期。语法层面靠visudo -c。规则匹配层面可以用sudo -l -U 用户名列出某个用户被允许执行的命令这个命令不需要真的切换用户很适合批量核对sudo -l -U alice实际执行层面就得真跑一遍了用一个测试账号执行一条允许的命令和一条不允许的命令看结果是否符合预期。这一步别省我见过配置文件写对了但组没生效、或者缓存导致旧规则还在起作用的情况只有真跑才能发现。4.4 人员变动时的清理动作人员离职或转岗权限清理要跟上。清理顺序建议是先从所有附加组里移除再删账号或锁定账号最后检查有没有遗留的 sudo 规则、cron 任务、SSH 密钥。移除组的命令gpasswd -d alice logreader或者用usermod配合完整的组列表覆盖。删账号用userdel加-r会连带删除家目录但删之前要确认里面没有需要保留的东西。锁定而不删除是更稳妥的做法usermod -L alice-L会在密码哈希前加!账号无法登录但数据保留。等确认没有遗留依赖之后再彻底删除。这套流程看着繁琐但真出过离职人员账号还能登录的事故之后就会觉得每一步都值得。5. 几个真实踩过的坑与排查思路5.1 sudo 突然全部失效的排查链路有次改完 sudoers保存时手滑第二天所有人 sudo 都报语法错误。排查链路是这样的先看报错信息sudo 会明确提示哪一行有问题然后用visudo -c单独校验它会指出具体行号确认问题行之后用备份文件对比定位改动。修复方式是从备份恢复或者手工改回正确语法。这个坑的教训是改 sudoers 前必须备份改完必须校验。另外保留一个后门通道也很重要——比如确保 root 密码是可用的或者有一个不依赖 sudo 的带外管理方式否则配置一坏就彻底进不去。我现在改这类关键配置都是先开两个终端一个改一个留着备用。5.2 加了组却不生效的三种原因我明明加组了为什么还是没权限——这个问题我遇到过三种原因。第一种是会话没刷新前面说过重新登录或newgrp解决。第二种是加组时漏了-a把原有组覆盖了用id一查就能发现。第三种是权限判定看的不是组而是别的因素比如 SELinux 或 AppArmor 的策略限制这种情况下ls -l看到的权限是对的但实际访问还是被拒得去看安全模块的日志。排查顺序建议是先id确认组关系对不对再确认会话是否刷新最后才怀疑安全模块。大部分情况在前两步就能解决。5.3 命令白名单被绕过的实际案例前面提过sudo vim的风险这里说个更隐蔽的有人给白名单配了sudo tar本意是让用户打包备份文件。但 tar 有--checkpoint-action参数可以在打包过程中执行任意命令等于绕过了白名单。类似的还有sudo rsync的-e参数、sudo git的某些子命令。这类看起来无害实则能执行代码的命令配白名单时要格外小心。判断一个命令能不能安全地放进白名单我的经验是看它有没有执行外部程序或写任意文件的能力。有的话要么不给要么用sudoedit这类受限方式替代。这个判断没有捷径得对命令本身足够熟悉。5.4 时间戳缓存带来的误判sudo 的时间戳缓存有时会造成误判刚验证过密码紧接着执行另一条 sudo 命令没再要密码有人以为权限配置错了怎么不要密码。其实这是正常的缓存行为。反过来如果明明刚验证过却又要密码可能是缓存目录权限有问题或者不同终端之间缓存不共享。排查缓存问题先sudo -k清掉再试能复现就是要密码的正常流程。如果清了之后行为还是异常去看缓存目录的权限和属主确保只有 root 能写。这个细节平时不太会遇到但一旦遇到很容易懵。6. 把权限管理变成习惯6.1 日常操作的自检清单用久了之后我给自己总结了一份轻量自检清单每次涉及权限改动时过一遍改 sudoers 前备份了吗、用 visudo 了吗、改完visudo -c了吗、加组带-a了吗、加完id确认了吗、测试账号验证过了吗、日志里能看到这次改动吗。这几条看着琐碎但每一条背后都对应一次真实的翻车。清单不用长关键是形成肌肉记忆。我现在改任何权限相关配置手会先自动去敲备份命令这已经成了条件反射。6.2 权限最小化的落地心态最小权限这四个字谁都懂落地时却总被先给了再说省得来回改的心态打败。我的体会是权限给宽了再收比一开始给窄了再加要难得多——因为一旦有人依赖了宽权限收的时候就会有阻力。所以宁可一开始抠得紧一点遇到实际需求再逐条加加的时候顺手记一笔为什么加方便日后审计。这套心态配合组驱动的配置方式能把权限管理从救火变成维护。组是稳定的人是流动的把规则绑在组上人员怎么变配置都不用大动。6.3 后续可以深入的方向这套基础打牢之后往下还有几个值得深入的方向PAM 认证模块的定制、基于角色的访问控制方案、集中式账号管理比如把多台机器的账号统一到目录服务里、以及审计日志的集中采集与分析。这些内容各自都能展开一大篇但前提是先把 root、sudo、用户组这三块的地基打稳。地基不稳往上堆什么都是空中楼阁。我自己是从被 sudo 报错折磨开始认真学这块的回头看最有价值的不是记住了多少命令而是理解了权限判定那条链路——知道内核在哪个环节看什么排查问题时就有了方向而不是瞎试。
阅读完成 · 觉得有帮助？
