用户与权限管理是 Ubuntu 服务器安全的第一道防线。无论是新部署一台云主机，还是维护一台长期运行的生产机器，正确理解账号体系、sudo 授权机制与文件权限，都直接决定了这台机器是否安全、是否可审计、是否可控。今天我们从最基础的账号概念讲起，逐步深入到实战配置与常见问题排查，帮你把用户与权限这块地基打牢。
一、Ubuntu 账号体系的核心概念
Linux 是典型的多用户操作系统，所有资源访问都围绕「用户（User）」和「组（Group）」展开。每个用户都拥有一个唯一的数字标识 UID（User ID），每个组拥有 GID（Group ID）。在 Ubuntu 中，系统账号相关信息主要存储在以下几个关键文件中：
/etc/passwd：用户账号信息，每一行记录用户名、UID、GID、家目录、登录 Shell 等。/etc/shadow：用户加密后的密码与密码过期策略，仅 root 可读。/etc/group：组信息，记录组名、GID 与组成员。
Ubuntu 默认的普通用户 UID 从 1000 开始，而系统服务账号通常使用较小的 UID 区间。以 root 为例，其 UID 固定为 0，是系统中权限最高的超级用户。出于安全考虑，Ubuntu 默认禁用 root 的密码登录，转而引导管理员通过 sudo 以普通用户身份提权，这也是 Ubuntu 与部分其他发行版最显著的区别之一。
二、sudo 授权机制
sudo（superuser do）允许授权用户以 root 或其他用户身份执行特定命令，同时记录每次提权操作，便于审计。sudo 的授权规则写在 /etc/sudoers 文件中，但我们几乎从不直接编辑它，而是通过 visudo 命令进行修改，因为它会在保存前做语法校验，避免因格式错误导致系统无法提权。
查看当前用户的 sudo 权限：
sudo -l
默认安装时，系统创建的第一个用户会被加入 sudo 组，通过 /etc/sudoers 中以下规则获得完整提权能力：
%sudo ALL=(ALL:ALL) ALL
这行配置的含义是：属于 sudo 组（%sudo）的成员，可以在任意主机（第一个 ALL）上，以任意用户、任意组（ALL:ALL）身份，执行任意命令（最后一个 ALL）。
给新用户授予 sudo 权限，最简洁的方式是把它加入 sudo 组：
sudo usermod -aG sudo alice
需要注意的是，-aG 表示「追加到附加组」，不要漏掉 -a，否则会把用户从原有的其他附加组中移除。修改组成员身份后，用户需要重新登录才会生效。
三、文件权限与 chmod / chown
文件权限是 Linux 安全模型的核心。使用 ls -l 查看文件时，最前面的一段形如 -rw-r--r--，它由三部分组成：文件类型、属主权限、属组权限、其他用户权限。其中 r 表示读（4）、w 表示写（2）、x 表示执行（1）。
常见的权限修改命令是 chmod，既可以用符号模式，也可以用八进制数字模式。数字模式更直观、更不易出错：
# 给 owner 读写执行(7)，group 读执行(5)，其他读执行(5)
chmod 755 /opt/app/start.sh
# 配置文件通常只需属主可写
chmod 644 /etc/myapp/config.ini
chown 用于变更文件的属主与属组：
# 将文件属主改为 alice，属组改为 dev
sudo chown alice:dev /var/www/project
对于目录，往往还需要配合 -R 递归修改，但要谨慎：并非所有文件都适合一刀切地改成同一权限。例如网页目录通常需要 Web 服务进程（如 www-data）可读，但不应让其随意可写，否则一旦站点存在漏洞就容易被写入恶意文件。
四、实战：创建账号并配置权限
下面通过一个完整流程，演示如何在 Ubuntu 上创建一个运维账号并赋予合理的 sudo 权限。
# 1. 创建用户并指定家目录与默认 Shell
sudo useradd -m -s /bin/bash alice
# 2. 设置密码
sudo passwd alice
# 3. 加入 sudo 组授予提权能力
sudo usermod -aG sudo alice
# 4. 验证权限
su - alice
sudo whoami # 应输出 root
如果需要更细粒度的授权（例如只允许某个用户执行重启服务命令，而不给完整 root 权限），可以直接在 sudoers 中写规则：
alice ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart nginx
这行配置允许 alice 免密执行 systemctl restart nginx，其余命令仍需密码或无权执行。生产环境中，遵循「最小权限原则」配置 sudo 规则，能显著降低误操作和提权攻击的风险。
五、常见问题
问题一：修改了 sudoers 文件后 sudo 报语法错误怎么办？
这就是为什么必须用 visudo 编辑。若已经出错导致无法提权，可以通过恢复模式或物理控制台，以 root 直接登录后修复，或使用 pkexec visudo 尝试。预防永远优于修复。
问题二：用户加入 sudo 组后仍然提示 not in sudoers。
最常见原因是修改组成员后没有重新登录。组成员信息在登录时加载，需要用户退出当前会话重新登录，或执行 newgrp sudo 临时刷新。
问题三：chmod 777 能解决权限问题吗？
能「看起来」解决，但极其危险。777 意味着任何用户都可读写执行，几乎等于放弃了权限控制。遇到权限问题时，应分析「谁需要什么权限」，而不是简单放开。
总结
今天我们把 Ubuntu 用户与权限管理的骨架完整梳理了一遍：账号体系决定了「谁是谁」，sudo 决定了「谁能做什么」，文件权限决定了「谁能碰什么」。这三个层次环环相扣，共同构成服务器安全的基础。在后续的运维工作中，无论配置 Web 服务、数据库还是容器，你都会反复与它们打交道。建议你在一台测试机上亲手走一遍创建账号、配置 sudo、调整文件权限的完整流程，形成肌肉记忆。
下期预告：第 5 天我们将进入「文件系统与磁盘管理——分区、挂载、LVM 与 RAID 实战」，学会如何规划磁盘、扩容逻辑卷，为存储管理打好基础。
暂无评论内容