用户与权限管理：别让权限成为你的噩梦

说实话，我见过太多线上事故是因为权限配置不当引发的。有一次半夜三点，某团队误操作把 /etc 目录权限改成了 777，整个集群的服务全部挂掉。嗯，从那以后，我每次讲权限管理都会拿这个案例开场。

用户、组、文件权限、sudo、ACL——这些概念看似基础，但真正玩明白的人不多。今天咱们就把它彻底讲透。

用户与组管理：Linux 的身份证系统

Linux 是多用户系统，每个进程、每个文件都归属于某个用户和组。说白了，这就是一套身份认证体系。

核心文件

文件 作用 格式示例
/etc/passwd 用户账户信息 root:x:0:0:root:/root:/bin/bash
/etc/shadow 加密密码存储 root:$6$...:18937:0:99999:7:::
/etc/group 组信息 docker:x:999:jenkins,deploy
/etc/gshadow 组密码（极少用） docker:::jenkins,deploy
千万别手改这些文件——我见过有人用 vi 直接编辑 /etc/passwd，结果语法错误导致所有用户无法登录。请用 vipw 和 vigr 命令，它们会做语法校验。

常用命令速查

# 创建用户，自动创建同名组和家目录
useradd -m -s /bin/bash deployer

# 设置/修改密码
passwd deployer

# 创建组
groupadd devops

# 将用户加入组（附加组）
usermod -aG docker deployer

# 查看用户所属组
groups deployer

# 删除用户（-r 删除家目录和邮件池）
userdel -r deployer

我个人习惯在创建运维账号时，统一用 useradd -m -s /bin/bash -G wheel,docker 这种写法，把常用附加组一次性加好。省得后面再补。

文件权限：rwx 不是摆设

Linux 文件权限分三组：所有者（u）、所属组（g）、其他人（o）。每组三个位：读（r=4）、写（w=2）、执行（x=1）。

chmod：改权限

# 数字法（推荐）
chmod 755 script.sh    # rwxr-xr-x
chmod 644 config.yml   # rw-r--r--

# 符号法
chmod u+x script.sh    # 给所有者加执行
chmod g-w config.yml   # 去掉组的写权限
chmod o-r private.key  # 其他人不可读

# 递归修改（慎用）
chmod -R 755 /app/logs
我的习惯：生产环境配置文件一律 640，脚本文件 750，密钥文件 600。别问为什么，问就是吃过亏。

chown：改归属

# 修改所有者和组
chown deployer:devops app.jar

# 只改所有者
chown deployer app.jar

# 只改组
chown :devops app.jar

# 递归
chown -R deployer:devops /app

我曾经遇到一个案例：某 Java 应用日志目录所有者是 root，应用进程用 deployer 用户跑，结果日志写不进去，磁盘报警才发现。嗯，这种低级错误其实很常见。

sudo 机制：给普通用户一把「临时钥匙」

sudo 的核心思想是：普通用户临时提权执行特定命令，不需要知道 root 密码。

配置文件 /etc/sudoers

千万别直接编辑！用 visudo 命令，它会检查语法。

# 允许 wheel 组所有成员执行任何命令
%wheel ALL=(ALL) ALL

# 允许 deployer 无密码重启 nginx
deployer ALL=(root) NOPASSWD: /usr/bin/systemctl restart nginx

# 允许 devops 组执行特定命令集
Cmnd_Alias DEVOPS_CMDS = /usr/bin/systemctl *, /usr/bin/docker *
%devops ALL=(root) DEVOPS_CMDS

sudo 最佳实践：

  • 永远用 visudo 编辑，别手写
  • 遵循最小权限原则——只给需要的命令
  • 用 NOPASSWD 时要谨慎，自动化脚本可以用
  • 定期审计 /var/log/secure 或 /var/log/auth.log 中的 sudo 记录

ACL 权限控制：rwx 不够用了怎么办？

标准权限只有三组，但实际场景往往更复杂。比如：一个文件要让 A 用户读写、B 用户只读、C 组可执行——传统 rwx 做不到。这时候就需要 ACL。

ACL 基础操作

# 查看 ACL
getfacl /data/project

# 设置 ACL：给用户 alice 读写权限
setfacl -m u:alice:rw /data/project

# 设置 ACL：给组 devops 读执行权限
setfacl -m g:devops:rx /data/project

# 删除特定 ACL
setfacl -x u:alice /data/project

# 递归设置（注意：会覆盖已有 ACL）
setfacl -R -m u:alice:rw /data/project

# 设置默认 ACL（新建文件自动继承）
setfacl -d -m u:alice:rw /data/project
ACL 的坑：chmod 会改变 ACL mask 值，导致 ACL 权限「失效」。我曾经排查过一个诡异问题：ACL 明明设了读写，但用户就是写不进去。最后发现是有人执行了 chmod 750，把 mask 从 rw 降成了 r-x。解决方案：用 setfacl -m m::rwx 手动修正 mask。

知识体系总览

下面这张图把本章的核心逻辑串起来了，建议你保存下来当速查表。

用户与权限管理知识体系 用户管理 useradd / usermod / userdel passwd / /etc/passwd 组管理 groupadd / groupmod / groupdel /etc/group / gpasswd 文件权限 chmod / chown / chgrp rwx / 数字法 / 符号法 sudo 提权机制 visudo / /etc/sudoers NOPASSWD / Cmnd_Alias ACL 权限控制 setfacl / getfacl 默认 ACL / mask 机制 核心原则：最小权限 + 按需提权 + 定期审计

实战场景：搭建一个安全的运维账号体系

光说不练假把式。下面是我在项目中常用的账号体系搭建流程，你可以直接套用。

  1. 创建运维组：groupadd -g 2000 ops
  2. 创建运维用户：useradd -m -s /bin/bash -g ops -G docker,wheel alice
  3. 设置 sudo 权限：在 /etc/sudoers.d/ops 中写入 %ops ALL=(ALL) ALL
  4. 配置 SSH 密钥登录：禁止密码登录，只允许密钥
  5. 设置日志审计：开启 sudo 日志记录，配置 rsyslog 转发到集中日志平台
  6. 定期轮换密钥：每 90 天强制更新一次
避坑指南：我曾经在给客户做安全审计时发现，他们的 sudo 规则里写的是 %ops ALL=(ALL) NOPASSWD: ALL——这跟直接给 root 密码没区别。记住：NOPASSWD 只给特定命令，别给 ALL。
← 上一章 📖 返回目录 下一章 →