背景与适用场景

Linux 是一个多用户操作系统，文件权限管理是系统安全的基石。正确的权限设置可以防止未授权访问、限制用户操作范围、保护敏感数据。无论是最简单的个人 VPS 还是大型企业服务器，权限管理都是运维工程师每天都要面对的问题。

权限设置错误的典型表现包括：网站无法正常访问、应用程序无法写入日志、数据库无法启动、敏感配置文件被普通用户读取、安全漏洞被利用等。这些问题往往看起来五花八门，但追根溯源，十有八九是权限配置不当。

本文面向初中级运维工程师，深入讲解 Linux 权限模型的核心概念、chmod 和 chown 的详细用法、特殊权限位、ACL 访问控制列表，以及生产环境中常见的权限问题和解决方案。

第一部分：Linux 权限模型核心概念

基本权限模型

Linux 的每个文件都有三组权限信息：

• 所有者权限（Owner）：文件所属用户的权限
• 所属组权限（Group）：文件所属组的成员的权限
• 其他用户权限（Others）：除所有者和组成员之外的其他所有用户的权限

每组权限包含三个标志位：

• 读（r/4）：查看文件内容 / 列出目录文件列表
• 写（w/2）：修改文件内容 / 在目录中创建删除文件
• 执行（x/1）：执行文件 / 进入目录

查看文件权限

使用 ls -l 可以看到详细的权限信息：

ls -l /var/log/syslog

输出示例：

-rw-r----- 1 syslog adm  12345 May 29 10:30 /var/log/syslog

逐字段解释：

- rw- r-- ---
|  |   |   |
|  |   |   +-- Others 权限（无任何权限）
|  |   +------ Group 权限（只读）
|  +---------- Owner 权限（读写，无执行）
+------------- 文件类型（- = 普通文件，d = 目录，l = 符号链接）

权限位还可以用数字表示：640

权限与目录的关系

权限对文件和目录的意义不同：

关键点：目录的写权限允许删除目录内的文件，不管文件本身的权限是什么。这就是为什么目录权限要单独注意。

默认权限与 umask

创建新文件或目录时，系统会设置默认权限。默认权限由 umask 值决定。

查看当前 umask：

umask

输出通常是 0022 或 0002。

• 文件的默认权限：666 - umask
• 目录的默认权限：777 - umask

以 umask 0022 为例：

• 新建文件权限：666 - 022 = 644（rw-r--r--）
• 新建目录权限：777 - 022 = 755（rwxr-xr-x）

临时修改 umask（当前 shell 生效）：

umask 0027

永久修改 umask 需要在 shell 配置文件（如 ~/.bashrc 或 /etc/profile）中添加。

第二部分：chmod 详解

chmod 是 change mode 的缩写，用于修改文件或目录的权限。

数字权限法

最常用的权限设置方式：

chmod 755 /path/to/file     # rwxr-xr-x
chmod 644 /path/to/file     # rw-r--r--
chmod 600 /path/to/file     # rw-------
chmod 700 /path/to/directory # rwx------

三组权限分别对应三个数字：

# chmod ABC path
# A = 所有者权限
# B = 所属组权限
# C = 其他用户权限

# 755 含义：
# 7 = rwx（所有者：读+写+执行）
# 5 = r-x（所属组：读+执行）
# 5 = r-x（其他用户：读+执行）

符号权限法

更精细的权限控制方式：

# 语法：chmod [who][operator][permission] file

# who: u (所有者), g (所属组), o (其他用户), a (所有人)
# operator: + (添加), - (移除), = (设置)
# permission: r, w, x

常用操作示例：

# 给所有者添加执行权限
chmod u+x script.sh

# 移除所属组的写权限
chmod g-w file.txt

# 设置其他用户只有读权限
chmod o=r file.txt

# 给所有人添加读和执行权限
chmod a+rx program

# 设置所有者有所有权限，组和其他用户只有读和执行
chmod u=rwx,go=rx file

组合操作

一次性修改多组权限：

# 同时修改所有者和所属组权限
chmod ug+rw file.txt

# 设置所有者=读写执行，所属组=读执行，其他=读
chmod u=rwx,g=rx,o=r file

递归修改

修改目录及其所有内容：

# 递归修改目录权限
chmod -R 755 /var/www/html

# 递归修改，但只修改文件
find /var/www/html -type f -exec chmod 644 {} \;

# 递归修改，但只修改目录
find /var/www/html -type d -exec chmod 755 {} \;

常用权限值参考

特殊权限位

除了基本的 rwx 权限，Linux 还有三个特殊权限位：

SUID（Set User ID）

• 作用：执行文件时，以文件所有者的身份运行
• 设置：chmod u+s file 或 chmod 4755 file
• 典型应用：/usr/bin/passwd（修改密码时需要访问 /etc/shadow）

-rwsr-xr-x 1 root root  12345 May 29 10:30 /usr/bin/passwd
# 注意所有者权限位的 s，表示 SUID 已设置

SGID（Set Group ID）

• 作用：执行文件时，以文件所属组的身份运行；目录中新创建的文件继承目录的组
• 设置：chmod g+s dir 或 chmod 2755 dir
• 典型应用：共享目录，团队成员创建的文件都属于同一个组

drwxrwsr-x 2 root root  4096 May 29 10:30 /shared/project
# 注意所属组权限位的 s，表示 SGID 已设置

Sticky Bit

• 作用：目录中只有文件所有者可以删除或重命名自己的文件
• 设置：chmod +t /shared 或 chmod 1777 /shared
• 典型应用：/tmp 目录，所有用户都可以在 /tmp 中创建文件，但不能删除他人文件

drwxrwxrwt 10 root root  4096 May 29 10:30 /tmp
# 注意其他用户权限位的 t，表示 Sticky Bit 已设置

权限修改示例

让脚本可执行：

chmod +x /usr/local/bin/myscript.sh
chmod u+x /usr/local/bin/myscript.sh     # 效果相同
chmod 755 /usr/local/bin/myscript.sh     # 效果相同，但更明确

设置 Web 目录权限（常见场景）：

# 目录需要 755（所有者读写执行，组和其他人读执行）
chmod 755 /var/www/html

# 文件需要 644（所有者读写，其他人只读）
chmod 644 /var/www/html/*.html

# 允许 PHP 写入的上传目录
chmod 775 /var/www/html/uploads

设置数据库文件权限（MySQL 为例）：

# 数据目录
chown -R mysql:mysql /var/lib/mysql
chmod -R 700 /var/lib/mysql

# 配置文件
chown mysql:mysql /etc/mysql/my.cnf
chmod 640 /etc/mysql/my.cnf

权限检查与诊断

查看文件权限：

ls -la /path/to/file
stat /path/to/file

查看目录权限：

ls -ld /path/to/directory

使用 getfacl 查看 ACL 权限（如果配置了 ACL）：

getfacl /path/to/file

第三部分：chown 详解

chown 是 change owner 的缩写，用于修改文件或目录的所有者和所属组。

基本用法

只修改所有者：

chown user /path/to/file

同时修改所有者和所属组：

chown user:group /path/to/file

使用冒号分隔，冒号前是用户，冒号后是组。

只修改所属组：

chown :group /path/to/file

递归修改

递归修改目录及其所有内容：

chown -R user:group /path/to/directory

使用参考文件

使用另一个文件的权限作为参考：

chown --reference=/etc/passwd /etc/shadow

这会把 /etc/shadow 的所有者和所属组设置成和 /etc/passwd 一样。

常用场景

Web 应用权限设置

Nginx + PHP-FPM 场景（两者使用相同用户）：

chown -R www-data:www-data /var/www/html

Nginx 和 PHP-FPM 使用不同用户（推荐生产使用）：

# 网站目录所有者设为 nginx（nginx 运行用户）
chown -R nginx:nginx /var/www/html

# 上传目录所有者设为 php-fpm（PHP-FPM 运行用户）
chown -R php-fpm:php-fpm /var/www/html/uploads

# 或者使用 ACL 给两组用户不同权限
setfacl -R -m u:nginx:rx /var/www/html/uploads
setfacl -R -m u:php-fpm:rw /var/www/html/uploads

数据库权限设置

MySQL 数据目录：

chown -R mysql:mysql /var/lib/mysql
chmod -R 700 /var/lib/mysql

PostgreSQL 数据目录：

chown -R postgres:postgres /var/lib/postgresql
chmod -R 700 /var/lib/postgresql

日志目录权限

应用日志目录：

chown -R myapp:adm /var/log/myapp
chmod -R 750 /var/log/myapp

服务配置权限

Nginx 配置目录：

chown -R root:root /etc/nginx
chmod -R 640 /etc/nginx/*.conf
chmod 755 /etc/nginx

用户和组的创建

创建新用户：

# 创建用户（自动创建同名组）
useradd -m -s /bin/bash deploy

# 创建用户并指定组
useradd -m -g www-data -s /bin/bash deploy

# 创建系统用户（不创建家目录，不能登录）
useradd -r -s /sbin/nologin nginx

创建新组：

groupadd developers

将用户添加到组：

# 添加用户到附加组
usermod -aG developers user1

# 查看用户所属的组
groups user1
id user1

查看用户和组信息

# 查看用户信息
id username

# 查看所有用户
cat /etc/passwd

# 查看所有组
cat /etc/group

# 查看当前用户
whoami

# 查看当前用户详细信息
who am i

第四部分：ACL 访问控制列表

ACL（Access Control List）提供了比传统权限模型更细粒度的控制。

检查 ACL 支持

大多数现代 Linux 文件系统（ext4、xfs、btrfs）都支持 ACL。检查文件系统是否支持：

# 临时启用 ACL（如果文件系统默认未启用）
tune2fs -o acl /dev/sda1
mount -o acl /dev/sda1 /mnt

查看 ACL 权限

getfacl /path/to/file

输出示例：

# file: file.txt
# owner: root
# group: root
user::rw-
user:www-data:rw-
group::r--
group:developers:rw-
mask::rw-
other::r--

设置 ACL 权限

给特定用户设置权限：

setfacl -m u:username:rw /path/to/file

给特定组设置权限：

setfacl -m g:groupname:rx /path/to/directory

ACL 权限格式

u:username:permission   # 特定用户的权限
g:groupname:permission # 特定组的权限
o:permission          # 其他用户权限（相当于 chmod o:）
m:permission          # 掩码权限

常用 ACL 操作

设置默认 ACL

目录可以设置默认 ACL，新创建的文件和子目录会自动继承：

# 为目录设置默认 ACL
setfacl -m d:u:www-data:rw /var/www/html/uploads

# 查看默认 ACL
getfacl /var/www/html/uploads

删除 ACL 条目

# 删除特定用户的 ACL
setfacl -x u:username /path/to/file

# 删除特定组的 ACL
setfacl -x g:groupname /path/to/file

# 删除所有 ACL（恢复传统权限）
setfacl -b /path/to/file

递归设置 ACL

# 递归设置目录下所有文件和目录
setfacl -R -m u:www-data:rw /var/www/html/uploads

# 设置默认 ACL（只影响新建的文件）
setfacl -R -m d:u:www-data:rw /var/www/html/uploads

ACL 与传统权限的关系

• 传统权限是最基本的控制
• ACL 在传统权限基础上添加更细粒度的控制
• 有效权限（Effective Permission）受 mask 限制
• getfacl 输出中，mask:: 行显示当前生效的掩码

修改 mask：

setfacl -m m::rwx /path/to/file

Web 应用 ACL 配置示例

Nginx + PHP-FPM 分离用户的场景：

# /var/www/html 目录，nginx 用户需要读取，php-fpm 用户需要读写
chown nginx:nginx /var/www/html
chmod 750 /var/www/html

# 为 php-fpm 用户添加写权限
setfacl -R -m u:php-fpm:rw /var/www/html/uploads

# 为 nginx 用户添加读权限
setfacl -R -m u:nginx:rx /var/www/html/uploads

# 设置默认 ACL，新文件自动继承
setfacl -R -m d:u:php-fpm:rw /var/www/html/uploads
setfacl -R -m d:u:nginx:rx /var/www/html/uploads

# 验证
getfacl /var/www/html/uploads

备份和恢复 ACL

备份：

getfacl -R /path/to/directory > acl_backup.txt

恢复：

setfacl --restore=acl_backup.txt

第五部分：生产环境权限问题排查

问题一：Web 应用无法读取文件

现象

Nginx 返回 403 Forbidden。

排查步骤

1. 查看 Nginx 错误日志

tail -20 /var/log/nginx/error.log

1. 查看文件权限

ls -la /var/www/html/index.html

1. 查看 Nginx 运行用户

ps aux | grep nginx

1. 常见原因

• 文件所有者不是 Nginx 运行用户
• 目录缺少执行权限（无法 cd 进入）
• SELinux 或 AppArmor 限制

解决方案

# 确保文件所有者正确
chown nginx:nginx /var/www/html/index.html

# 确保目录有执行权限
chmod 755 /var/www/html

# 确保文件有读权限
chmod 644 /var/www/html/index.html

问题二：Web 应用无法写入文件

现象

上传图片失败，或日志无法写入。

排查步骤

1. 查看 PHP-FPM 或应用错误日志

2. 检查目录权限

ls -ld /var/www/html/uploads

1. 检查 PHP-FPM 运行用户

ps aux | grep php-fpm

1. 检查目录所在文件系统是否可写

df -h /var/www/html/uploads
mount | grep /var/www

解决方案

上传目录需要可写权限：

chown php-fpm:php-fpm /var/www/html/uploads
chmod 775 /var/www/html/uploads

如果使用了 SELinux：

# 查看 SELinux 上下文
ls -Z /var/www/html/uploads

# 修改 SELinux 上下文
chcon -R -t httpd_sys_rw_content_t /var/www/html/uploads

# 永久修改（下次 restorecon 不会重置）
semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/html/uploads(/.*)?"

问题三：数据库无法启动

现象

MySQL 或 PostgreSQL 启动失败。

排查步骤

1. 查看数据库错误日志

# MySQL
tail -50 /var/log/mysql/error.log

# PostgreSQL
tail -50 /var/log/postgresql/postgresql-XX-main.log

1. 检查数据目录权限

# MySQL
ls -la /var/lib/mysql

# PostgreSQL
ls -la /var/lib/postgresql

1. 检查配置文件权限

# MySQL
ls -la /etc/mysql/my.cnf

# PostgreSQL
ls -la /etc/postgresql/*/main/postgresql.conf

解决方案

MySQL 数据目录权限修复：

# 停止 MySQL
systemctl stop mysql

# 修复权限
chown -R mysql:mysql /var/lib/mysql
chmod -R 700 /var/lib/mysql

# 重启 MySQL
systemctl start mysql

PostgreSQL 数据目录权限修复：

# 停止 PostgreSQL
systemctl stop postgresql

# 修复权限
chown -R postgres:postgres /var/lib/postgresql
chmod -R 700 /var/lib/postgresql

# 重启 PostgreSQL
systemctl start postgresql

问题四：SSH 密钥登录失败

现象

使用 SSH 公钥认证失败。

排查步骤

1. 检查用户家目录权限

ls -la ~user/

1. 检查 .ssh 目录权限

ls -la ~user/.ssh/

1. 检查 authorized_keys 文件权限

ls -la ~user/.ssh/authorized_keys

正确权限要求

/home/username     -> 700 或 755
/home/username/.ssh   -> 700
/home/username/.ssh/authorized_keys -> 600

修复权限

chmod 700 ~user/.ssh
chmod 600 ~user/.ssh/authorized_keys
chmod 755 ~user

问题五：脚本执行报错 "Permission denied"

现象

执行 shell 脚本报错：bash: ./script.sh: Permission denied

排查步骤

1. 检查脚本权限

ls -la script.sh

1. 检查脚本是否有 shebang 行

head -1 script.sh

解决方案

添加执行权限：

chmod +x script.sh
# 或
chmod 755 script.sh

如果脚本使用 #!/bin/bash，确保 /bin/bash 有执行权限：

ls -la /bin/bash

问题六：共享目录中用户无法访问他人文件

现象

团队成员在共享目录中无法读取他人创建的文件。

排查步骤

1. 检查目录权限

ls -ld /shared

1. 检查文件默认权限

umask

解决方案

使用 SGID 确保文件继承目录的组：

# 设置目录 SGID
chmod 2775 /shared

# 设置目录所有者和组
chown :developers /shared

# 设置 umask 让新建文件自动有组写权限
# 在 /etc/profile 或 ~/.bashrc 中添加：
umask 002

验证：

# 用户 A 创建文件
touch /shared/file_a.txt
ls -la /shared/file_a.txt
# 应该是 -rw-rw-r-- (664)

# 用户 B 可以读取和修改

第六部分：安全最佳实践

最小权限原则

只授予完成任务所需的最小权限，不要过度授权。

# 不推荐：所有文件都用 777
chmod -R 777 /var/www/html

# 推荐：目录 755，文件 644
find /var/www/html -type d -exec chmod 755 {} \;
find /var/www/html -type f -exec chmod 644 {} \;

# 需要写入的目录单独设置
chmod 775 /var/www/html/uploads
chown www-data:www-data /var/www/html/uploads

敏感文件保护

敏感文件要严格控制访问权限：

# 用户密码文件
chmod 640 /etc/passwd
chmod 600 /etc/shadow

# SSH 私钥
chmod 600 ~/.ssh/id_rsa
chmod 644 ~/.ssh/id_rsa.pub

# 数据库配置文件
chmod 640 /etc/mysql/my.cnf
chmod 640 /etc/postgresql/*/main/pg_hba.conf

# 应用密钥文件
chmod 600 /var/www/html/.env

服务专用用户

每个服务使用独立的系统用户：

# 创建 Nginx 用户（如默认不存在）
useradd -r -s /sbin/nologin nginx

# 创建 PHP-FPM 用户
useradd -r -s /sbin/nologin php-fpm

# 创建数据库用户
useradd -r -s /sbin/nologin mysql
useradd -r -s /sbin/nologin postgres

# 创建应用用户
useradd -m -s /bin/bash myapp

定期权限审计

建立权限检查机制：

#!/bin/bash
# 权限审计脚本

echo"=== 权限审计报告 ==="
echo"时间: $(date)"
echo""

# 检查敏感文件权限
echo"--- 敏感文件权限检查 ---"
for file in /etc/passwd /etc/shadow /etc/group; do
    perms=$(stat -c "%a"$file)
    owner=$(stat -c "%U:%G"$file)
echo"$file: $owner$perms"
done

echo""

# 检查是否存在 777 权限的文件或目录
echo"--- 检查 777 权限（危险）---"
find /var/www -perm -007 -type f 2>/dev/null | head -10
find /var/www -perm -007 -type d 2>/dev/null | head -10

echo""

# 检查未授权的可执行文件
echo"--- 检查可疑的可执行文件 ---"
find /tmp -perm /111 -type f 2>/dev/null | head -10

目录权限规范

常见目录的推荐权限：

umask 设置建议

根据应用场景设置合适的 umask：

# 系统级默认 umask（/etc/profile）
umask 0027

# 团队共享目录（在 ~/.bashrc 中针对特定用户）
if [ "$(id -gn)" = "developers" ]; then
umask 002
fi

# Web 应用用户
su - www-data -c "umask 002"

第七部分：权限操作的风险与回滚

高风险操作识别

以下操作具有破坏性，执行前务必确认：

权限备份

修改权限前备份当前权限：

# 使用 getfacl 备份目录权限
getfacl -R /etc/nginx > /backup/nginx_acl_$(date +%Y%m%d).txt

# 使用 getfacl 备份单个文件权限
getfacl /etc/passwd > /backup/passwd_acl.txt

权限恢复

# 恢复目录权限
setfacl --restore=/backup/nginx_acl_20260529.txt

# 恢复单个文件权限
setfacl --restore=/backup/passwd_acl.txt

误操作回滚

如果误修改了权限，按以下步骤恢复：

1. 查看文件原权限（如果有版本控制或备份）

# 从备份恢复
getfacl --restore=/path/to/backup.txt

1. 常见权限的默认值

# 普通文件
chmod 644 file

# 可执行文件
chmod 755 file

# 目录
chmod 755 directory

# 系统配置文件
chmod 640 /etc/passwd
chmod 600 /etc/shadow

权限修改的验证

修改权限后验证：

# 查看文件权限
ls -la /path/to/file

# 测试应用是否正常
systemctl restart nginx
curl -I http://localhost

# 测试文件是否可访问
sudo -u www-data cat /var/www/html/index.html

补充部分：特殊权限深度应用

SUID 实战应用

SUID（Set User ID）是一个特殊的权限位，允许程序以文件所有者的身份运行。这在需要临时提升权限的场景中很有用，但也会带来安全风险。

典型应用场景：ping 命令

ping 命令需要发送 ICMP 网络包，这需要 root 权限。但普通用户也需要能 ping 其他主机。解决方案就是给 ping 设置 SUID：

ls -la /bin/ping
# -rwsr-xr-x 1 root root 4096 May 29 10:30 /bin/ping
#                    ^ s 表示 SUID 已设置

普通用户执行 ping 时，实际是以 root 身份运行的。

查找所有 SUID 文件

# 查找系统中的 SUID 文件
find /usr -perm /4000 -type f 2>/dev/null

# 查找 SUID 文件并显示详细信息
find /usr -perm /4000 -type f -exec ls -la {} \; 2>/dev/null

# 查找 SUID 文件（排除已知的）
find / -perm -4000 -type f 2>/dev/null | grep -vE "^/(usr|bin|sbin)/"

安全风险

SUID 文件是潜在的安全风险点，攻击者可能利用 SUID 程序提权。需要定期检查：

#!/bin/bash
# 检查新增的 SUID 文件（需要建立基线）

KNOWN_SUID_FILE="/root/.known_suid_$(date +%Y%m)"

# 如果没有基线文件，创建基线
if [ ! -f "$KNOWN_SUID_FILE" ]; then
    find / -perm -4000 -type f 2>/dev/null > "$KNOWN_SUID_FILE"
echo"已创建 SUID 基线文件: $KNOWN_SUID_FILE"
exit 0
fi

# 检查新增的 SUID 文件
CURRENT_SUID=$(mktemp)
find / -perm -4000 -type f 2>/dev/null > "$CURRENT_SUID"

echo"=== SUID 变更检查 ==="
echo"基线文件: $KNOWN_SUID_FILE"

NEW_SUID=$(comm -13 "$KNOWN_SUID_FILE""$CURRENT_SUID")
if [ -n "$NEW_SUID" ]; then
echo"发现新增 SUID 文件:"
echo"$NEW_SUID"
else
echo"未发现新增 SUID 文件"
fi

# 删除临时文件
rm -f "$CURRENT_SUID"

移除 SUID 权限

如果某个 SUID 文件不需要 SUID，应该移除：

# 移除 SUID（保留所有者权限）
chmod u-s /usr/bin/someprogram

# 或
chmod 755 /usr/bin/someprogram

SGID 实战应用

SGID（Set Group ID）有两种用法：

1. 对文件：执行时以文件所属组身份运行
2. 对目录：目录中新建的文件继承目录的组

团队共享目录实战

# 创建一个团队共享目录
mkdir /opt/shared
groupadd developers
chown :developers /opt/shared
chmod 2775 /opt/shared  # 2 = SGID

# 添加团队成员
usermod -aG developers alice
usermod -aG developers bob

# 验证 SGID 效果
# alice 创建文件
su - alice -c "touch /opt/shared/alice_file.txt"
ls -la /opt/shared/alice_file.txt
# 应该显示 -rw-rw-r-- 和 developers 组

# bob 创建文件
su - bob -c "touch /opt/shared/bob_file.txt"
ls -la /opt/shared/bob_file.txt
# 应该显示 -rw-rw-r-- 和 developers 组

多个团队共享目录

如果一个目录需要多个组都能读写：

# 创建目录
mkdir /data/project
groupadd dev
groupadd qa

# 设置所有者为 dev 组
chown :dev /data/project
chmod 2770 /data/project

# 使用 ACL 给 qa 组添加写权限
setfacl -m g:qa:rw /data/project
setfacl -m d:g:qa:rw /data/project

# 验证
getfacl /data/project

Sticky Bit 实战应用

Sticky Bit 主要用于公共目录，确保用户只能删除自己的文件。

典型应用：/tmp 目录

ls -ld /tmp
# drwxrwxrwt 10 root root 4096 May 29 10:30 /tmp
#                  ^ t 表示 Sticky Bit

即使 /tmp 目录权限是 777，任何用户都可以在里面创建文件，但只能删除自己的文件。

创建带 Sticky Bit 的目录

# 创建公共目录
mkdir /opt/public
chmod 1777 /opt/public
chown root:root /opt/public

# 任何用户都可以在里面创建文件
# 但只有文件所有者能删除自己的文件

权限与 SELinux/AppArmor 的关系

在启用了 SELinux 或 AppArmor 的系统（如 CentOS/RHEL、Ubuntu）中，权限管理还需要考虑安全模块策略。

检查 SELinux 状态

# 查看 SELinux 状态
getenforce

# 查看详细状态
sestatus

# 查看文件 SELinux 上下文
ls -Z /var/www/html

查看文件 SELinux 上下文

# 查看单个文件的 SELinux 上下文
ls -Z /var/www/html/index.html

# 查看目录的 SELinux 上下文
ls -Zd /var/www/html

# 查看进程 SELinux 上下文
ps auxZ | grep nginx

修改 SELinux 上下文

# 修改目录的 SELinux 上下文
chcon -R -t httpd_sys_content_t /var/www/html

# 修改文件类型的 SELinux 上下文
chcon -t httpd_sys_rw_content_t /var/www/html/uploads

# 永久修改（下次 restorecon 不会重置）
semanage fcontext -a -t httpd_sys_content_t "/var/www/html(/.*)?"

恢复默认 SELinux 上下文

# 恢复目录的默认 SELinux 上下文
restorecon -R /var/www/html

# 查看默认上下文规则
semanage fcontext -l | grep /var/www

AppArmor 简介（Ubuntu）

Ubuntu 使用 AppArmor 作为安全模块：

# 查看 AppArmor 状态
aa-status

# 查看 nginx 的 AppArmor 配置文件
cat /etc/apparmor.d/usr.sbin.nginx

# 重新加载 AppArmor 配置
systemctl reload apparmor

总结

核心概念速记

1. 三组权限：所有者（u）、所属组（g）、其他用户（o）
2. 三个权限位：读（r=4）、写（w=2）、执行（x=1）
3. 目录的写权限：控制文件创建和删除，与文件本身权限无关
4. umask：从全权限中减去的值，控制新建文件默认权限
5. 特殊权限：SUID（4）、SGID（2）、Sticky Bit（1）
6. ACL：比传统权限更细粒度的控制机制

常用命令速查

# 修改权限
chmod 755 file                    # 数字方式
chmod u+x file                   # 符号方式
chmod -R 755 directory           # 递归

# 修改所有者和所属组
chown user:group file            # 同时修改
chown user file                  # 只改所有者
chown :group file                # 只改所属组
chown -R user:group directory    # 递归

# 查看权限
ls -la file                      # 查看文件权限
getfacl file                     # 查看 ACL 权限

# 设置 ACL
setfacl -m u:user:rw file       # 给用户设置权限
setfacl -m g:group:rx directory # 给组设置权限
setfacl -m d:u:user:rw directory # 设置默认 ACL
setfacl -b file                 # 删除所有 ACL

学习建议

1. 理解概念比死记硬背重要：权限模型是 Linux 安全的基础
2. 多动手实验：在测试环境尝试不同权限组合，观察效果
3. 关注报错信息：权限问题通常会给出明确的错误提示
4. 遵循最小权限原则：只授予必需的最小权限
5. 记录和备份：修改权限前记录原值，便于回滚

权限管理看似简单，实际上是 Linux 运维中最需要细心和经验的领域之一。养成正确的权限管理习惯，能避免大部分生产环境安全事故。