第 04 章：权限与用户

zjc 于 2026-01-04 发布

这是《Linux 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。 Linux 的安全边界建立在用户、组、文件权限、sudo 和审计之上。生产事故里，很多问题不是复杂漏洞，而是 root 直接运行业务、配置文件权限过大、sudo 规则过宽或共享账号导致无法追责。

4.1 用户与组

查看身份：

id
whoami
groups
who
w
last

用户信息：

getent passwd app
getent group app
cat /etc/passwd
cat /etc/group

/etc/passwd 示例：

app:x:1001:1001:Order Service:/opt/app:/sbin/nologin

字段含义：

字段	含义
name	用户名
password	历史密码字段，通常为 `x`
uid	用户 ID
gid	主组 ID
gecos	描述
home	家目录
shell	登录 Shell

服务账号常使用 /sbin/nologin 或 /usr/sbin/nologin，路径因发行版可能不同。

4.2 用户管理

创建用户：

sudo useradd -m -s /bin/bash dev01
sudo useradd -r -s /sbin/nologin -d /opt/app app

设置密码：

sudo passwd dev01
sudo passwd -l app
sudo passwd -u dev01

修改用户：

sudo usermod -aG docker dev01
sudo usermod -s /sbin/nologin app
sudo usermod -L old-user

删除用户：

sudo userdel dev01
sudo userdel -r dev01

userdel -r 会删除家目录和邮箱。生产环境更常见的做法是先锁定账号，确认无资源归属后再删除。

4.3 组管理

sudo groupadd release
sudo groupadd -g 2000 data
sudo gpasswd -a dev01 release
sudo gpasswd -d dev01 release
sudo groupdel release

查看成员：

getent group release
lid -g release

-aG 中的 a 很重要：

sudo usermod -aG docker dev01

漏掉 a 可能覆盖用户所属组，造成权限丢失。

4.4 文件属主与权限

ls -l app.conf
stat app.conf

修改属主：

sudo chown app:app app.conf
sudo chown app app.conf
sudo chgrp app app.conf
sudo chown -R app:app /opt/app

修改权限：

chmod 640 app.conf
chmod 750 deploy.sh
chmod u+x deploy.sh

常用基线：

对象	建议
配置文件	`640` 或更严格
私钥	`600`
可执行脚本	`750`
应用目录	`750`
日志目录	属组可写或应用可写
Web 根目录	避免应用可写执行同时开放

私钥权限过宽时，SSH 通常会拒绝使用：

chmod 600 ~/.ssh/id_ed25519

4.5 umask

查看：

umask
umask -S

常见值：

umask 022
目录初始权限 777 - 022 = 755
文件初始权限 666 - 022 = 644

umask 027
目录初始权限 777 - 027 = 750
文件初始权限 666 - 027 = 640

设置：

umask 027

服务进程的 umask 应在 systemd、启动脚本或应用配置中显式设置，不要依赖登录 Shell 的默认值。

systemd 示例：

[Service]
UMask=0027

4.6 ACL

传统权限只有一套属主、属组和其他人。ACL 可以给多个用户或组设置不同规则。

getfacl app.conf
setfacl -m u:dev01:r app.conf
setfacl -m g:audit:r app.conf
setfacl -x u:dev01 app.conf
setfacl -b app.conf
setfacl -R -m g:release:rwX /srv/share

查看：

ls -l app.conf
getfacl app.conf

权限位末尾出现 + 表示有 ACL：

-rw-r-----+ 1 app app 1024 Aug 25 10:00 app.conf

ACL 适合临时协作和例外授权。长期权限模型仍应优先使用属组和目录规划。

4.7 sudo

查看当前用户可用权限：

sudo -l

常见命令：

sudo systemctl restart nginx
sudo -u app /opt/app/bin/server --check
sudo -i
sudo -s

推荐使用 sudo -u app 验证应用用户视角：

sudo -u app cat /opt/app/conf/app.yml
sudo -u app /opt/app/bin/healthcheck.sh

最小授权示例：

dev01 ALL=(app) /opt/app/bin/deploy.sh
ops01 ALL=(root) /usr/bin/systemctl restart nginx, /usr/bin/systemctl reload nginx

不推荐：

dev01 ALL=(ALL) NOPASSWD: ALL

sudo 规则文件建议放在：

/etc/sudoers.d/<team-or-role>

不要直接用普通编辑器修改 /etc/sudoers。修改后必须校验语法：

sudo visudo -f /etc/sudoers.d/release
sudo visudo -c

4.8 切换用户与审计

su - app
sudo -iu app
sudo -u app bash

区别：

命令	行为
`su - app`	需要目标用户密码，加载登录环境
`su app`	切换用户，保留部分当前环境
`sudo -iu app`	用 sudo 授权，加载登录环境
`sudo -u app bash`	以指定用户执行命令

审计关注：

sudo journalctl -t sudo --since today
sudo grep sudo /var/log/auth.log
sudo grep sudo /var/log/secure

日志文件名因发行版而异。

4.9 资源限制与 PAM

查看限制：

ulimit -n
ulimit -u
ulimit -a

临时修改：

ulimit -n 65535

服务建议使用 systemd 管理：

[Service]
LimitNOFILE=65535
LimitNPROC=4096

PAM 提供认证、授权、会话和密码策略模块。常见配置目录：

/etc/pam.d/
/etc/security/limits.conf
/etc/security/limits.d/

修改 PAM 前必须保留会话并演练，错误配置可能导致无法登录。

4.10 生产权限模型

一个典型的应用部署模型：

发布账号 release
  |-- 可写发布目录
  |-- 可执行部署脚本
  +-- 不能直接读数据库密码

应用账号 app
  |-- 运行服务
  |-- 读写应用数据和日志
  +-- 无登录 Shell

运维账号 ops
  |-- 登录跳板机
  |-- 受限 sudo
  +-- 操作有审计

目录示例：

sudo mkdir -p /opt/app/{conf,logs,run}
sudo chown -R app:app /opt/app
sudo chmod -R 750 /opt/app
sudo chmod 640 /opt/app/conf/*

原则：

一个应用一个账号；
root 不运行业务；
密钥最小可读；
sudo 按命令授权；
变更可追踪到人；
权限由配置管理维护。

4.11 常见问题排查

Permission denied

id
ls -ld /opt/app /opt/app/conf
ls -l /opt/app/conf/app.yml
getfacl /opt/app/conf/app.yml
sudo -u app cat /opt/app/conf/app.yml

检查路径上每一级目录的执行权限。

无法通过 SSH 登录

sudo journalctl -u ssh --since today
sudo grep sshd /var/log/auth.log
sudo passwd -S dev01
sudo chage -l dev01

常见原因：

账号锁定；
密码过期；
Shell 为 nologin；
SSH 禁用密码或 root 登录；
家目录权限异常；
密钥权限过宽。

sudo 报不是 sudoers

sudo -l
sudo visudo -c
getent group wheel
getent group sudo

处理时应通过配置管理修改授权，而不是临时加入过宽组。

本章小结

用户和组定义身份，文件权限定义资源访问边界，sudo 提供受控提权，审计回答“谁在何时做了什么”。生产环境应坚持独立应用账号、最小权限、无共享账号、密钥文件严格权限和可回滚的配置管理。

思考题

usermod -G 和 usermod -aG 有什么区别？
为什么 /etc/sudoers 必须用 visudo 校验？
ACL 和传统属组权限各适合什么场景？
应用进程的文件数限制应该在哪里配置？
为一个 Java 服务设计用户、目录和 sudo 权限方案。