Linux 系统管理入门：用户、权限与 sudo

刚接手服务器时，最容易犯的错误就是「先 root 干起来再说」。等你把业务跑起来、用户也多起来之后，再想收紧权限，成本就高了。这篇文章不讲概念，讲我怎么给一台多用户服务器规划账号和权限，以及中间踩过的坑。

#用户：useradd 不只是创建账号

创建用户时，我几乎总是这样写：

sudo useradd --create-home --shell /bin/bash --groups sudo deploy
sudo passwd deploy

--create-home 会生成 /home/deploy，否则很多软件默认往家目录写配置时会报错；--groups sudo 把用户加进 sudo 组。注意 useradd 默认的 umask 是 022，也就是说家目录是 755，别人能进入但写不了——这是合理的默认值，别手贱改成 777。

创建之后用这几条命令确认落盘情况：

id deploy                 # uid/gid/所属组
getent passwd deploy      # 来自 /etc/passwd 的记录
ls -ld /home/deploy       # drwxr-xr-x 就是对的

如果哪天发现用户登录后没有家目录、提示 Could not chdir to home directory，多半是当初漏了 --create-home，用 sudo mkhomedir_helper deploy 补上即可。

#权限：先看懂 rwx 再谈安全

文件权限是 owner / group / other 三段，每个用户最终的有效权限取决于「身份匹配」：先看你是不是 owner，不是就看属组，都不是才落到 other。这个匹配顺序就是 ACL 和多用户环境里很多「怪现象」的根源。

chmod 777 的问题不在于「7」这个数字，而在于它把第三段的 other 也给了读写执行。对普通文件，chmod 664（属主读写、属组读写、他人只读）通常就够了；对目录，执行位决定能不能 cd 进去，所以目录至少是 755。

还有个经常被忽略的点：对脚本用 setuid（4755）几乎总是坏主意。setuid 让程序以文件属主身份运行，等于给所有能执行它的人开了一条提权通道。真需要提权就好好用 sudo，按命令白名单给。

#sudo：白名单比 ALL 好得多

visudo 编辑 /etc/sudoers，语法核心是「谁在哪台机器上能以什么身份执行什么命令」：

%ops ALL=(ALL:ALL) /usr/bin/systemctl, /usr/bin/journalctl, /bin/systemctl
%ops ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart blog-app

几个要点：

• 匹配顺序：第一条命中的规则生效，所以把精确规则写在宽泛规则前面。
• 命令最好写绝对路径，防止 PATH 劫持（这就是为什么 sudoers 里有 secure_path）。
• 别写 %ops ALL=(ALL) ALL，那是把 root 分发出去。给一组命令就够了，比如重启服务、查日志。
• NOPASSWD 只给确无风险的命令；给了 NOPASSWD 之后再想收回，用户会不习惯，但该收就收。

改完一定要验证，而且验证分两步：

sudo visudo -c                    # 语法检查，错误会阻止保存
sudo -u deploy sudo -l            # 以 deploy 身份列出可执行命令

我见过最疼的一次事故：有人为了「省事」把 /etc 整个 chmod -R 777，结果 sudo 因为 /etc/sudoers 权限不对直接罢工，最后只能进单用户模式恢复。所以永远不要用 chmod -R 去修权限问题，权限问题要先定位「是谁、在哪一段、为什么被拒」。

#收尾：关密码登录前的自检清单

计划用密钥登录、关闭 SSH 密码登录之前，按这个顺序做：

1. 保持当前会话不关，另开一个会话用新密钥登录，确认能进。
2. 确认新账号 sudo 能执行所需命令（sudo -l 的输出逐条核对）。
3. 确认 /etc/shadow 对普通用户不可读：ls -l /etc/shadow 应是 -rw-------。
4. 再改 sshd_config 的 PasswordAuthentication no，sshd -t 检查后 reload。

最小权限不是一次配置，而是每次变更时的习惯：默认拒绝，按需放行，验证后再上线。