Linux用户与权限管理实战：sudoers、SUID/SGID与最小权限

发布时间：2026-09-10 04:47 更新时间：2026-09-10 04:47 阅读量：0

维护Linux服务器时，用户与权限管理是绕不开的基础功。很多站长在配置多用户协作时，要么直接给所有人root权限，要么因为权限不足频繁找管理员切密码，既不安全也影响效率。与此同时，系统里一些特殊权限位如果被错误设置，还会成为被攻击者利用的入口。这篇文章会把sudoers配置、SUID/SGID权限位和最小权限原则串起来讲清楚，并给出可以直接落地的命令示例。

sudoers配置：让授权更精细

sudo是Linux下最常用的提权工具，但直接用visudo编辑默认文件的人往往忽略了它的结构化配置能力。正确做法是，在/etc/sudoers.d目录下创建独立配置文件，避免直接修改主文件时出现语法错误导致sudo不可用。例如要给web组授予所有命令的执行权限，可以执行：

sudo visudo -f /etc/sudoers.d/webops

在打开的文件中写入：

%webops ALL=(ALL:ALL) ALL

这行表示web组内的用户可以在任何主机上以任何用户身份执行任何命令。对于实际生产环境，更推荐限制到具体命令，比如只允许某个用户管理Nginx服务：

deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart nginx, /usr/bin/systemctl reload nginx

这里加的NOPASSWD可以免去每次输入密码，适合自动化脚本。但需要注意，把可写目录下的脚本加入sudo授权存在风险，因为用户可能替换脚本内容来提权。稳妥的做法是指定绝对路径，并用sudo -l命令验证当前用户能执行哪些命令，确保配置生效且没有多余权限。

在修改sudoers之前，最好先执行sudo visudo -c做一次语法检查。如果手误写坏了配置，可以请有root权限的同事用pkexec visudo修复，或者重启进入单用户模式处理。总之，sudoers文件必须遵循“先测试后生效”的原则。

SUID与SGID：权限位的双刃剑

Linux文件权限中，除了读(r)、写(w)、执行(x)之外，还有两个特殊位：SUID(Set User ID)和SGID(Set Group ID)。普通用户执行带有SUID位的可执行文件时，会临时获得文件属主的身份。例如/usr/bin/passwd就有SUID位，所以普通用户能修改自己的密码而需要写入/etc/shadow。这种机制如果使用不当，会让低权限用户获得root能力，是非常典型的权限滥用风险。

恶意攻击者或误操作的管理员，可能给某个脚本或二进制程序加上SUID位，导致任何用户运行它都以root身份执行，从而读取敏感文件、创建后门。要找出系统中有SUID/SGID位的文件，可以使用find命令：

find / -perm /4000 -type f 2>/dev/null; find / -perm /2000 -type f 2>/dev/null

这条命令会列出所有含SUID或SGID位的普通文件。输出的列表需要仔细核对，系统自带的passwd、sudo、mount等文件有SUID是正常的。如果发现可疑的二进制或脚本，比如位于/tmp或用户家目录下的奇怪文件，应立即移除特殊位并检查文件完整性。移除SUID/SGID位用chmod即可：

sudo chmod u-s /path/to/suspicious; sudo chmod g-s /path/to/suspicious

对于开发者自己编译的程序，建议不要轻易设置SUID。如果程序确实需要提权，更推荐通过systemd服务或sudo授权来完成，从架构上避免SUID滥用。

最小权限原则：给每个进程和用户刚刚够用的权限

最小权限原则是整个权限管理的核心。它要求任何用户、程序或进程只拥有完成自身任务所必需的权限，不多给一份。落到文件层面，除了常规的chmod和chown，还要注意默认权限掩码umask的影响。大多数Linux发行版默认umask是022，意味着新建文件权限为644、目录为755。如果希望新建文件默认不给组和其他用户写权限，可以设置更严格的022，而想要更安全的环境，生产服务器通常设置为027，禁止同组用户读取组文件之外的内容。

临时调整当前会话的umask可以用：

umask 027

持久化则写到/etc/profile或/etc/bashrc中。除了基础权限，访问控制列表(ACL)能提供更细粒度的授权。例如给特定用户读某个日志文件的权限，而不改变属组：

sudo setfacl -m u:alice:r /var/log/nginx/access.log

然后用getfacl查看生效情况。ACL虽然灵活，但过度使用会让权限模型复杂化，排查问题时容易混乱。建议先考虑把用户加入合适组，再考虑ACL。另外，对于部署目录，可以把属主设为应用用户，并用chown root:appuser设置组权限只让固定组可写，配合粘滞位(sticky bit)避免目录内文件被互相删除。

作者在日常运维中总结出一条经验：每次配置完权限后，都用普通用户身份实际执行一遍相关命令，确认权限不多不少。比如你给了某用户服务重启权限，就用su切换过去测试，而不要只看配置文件。还需定期用find扫描异常权限位，并把扫描命令加入crontab，实现自动化巡检。最小权限不是一次性的操作，而是随着业务变动不断调整的动态过程。

最后给一个实用的建议：不要批量给用户开放root权限组，改用sudo授权负责特定命令；对SUID/SGID文件建立白名单清单；所有文件授权都遵循“先用默认安全值拒绝，再按需放行”的思路。在权限管理上宁可多花十分钟思考，也好过日后被提权漏洞折腾得焦头烂额。具体命令在不同Linux发行版上可能略有差异，操作前请以官方文档和你当前系统的实际环境为准。

继续阅读