一、概述

1.1 背景介紹

說實話，Linux 權限這塊我踩過不少坑。記得剛入行那會兒，有次為了圖省事直接chmod 777 -R /var/www，結果被老大罵了一頓——"你這是把大門敞開讓小偷隨便進啊！"

Linux 的權限體系是整個系統安全的基石。從最基礎的 rwx 三權分立，到 SUID/SGID 這些"特權通道"，再到 ACL 細粒度控制，最后是 SELinux/AppArmor 這種強制訪問控制，形成了一套層層遞進的安全防護網。

2026 年了，隨著容器化和云原生的普及，權限管理變得更加復雜。你不僅要管好宿主機的權限，還得搞清楚容器內的 UID 映射、Rootless 容器這些新玩意兒。這篇文章就把這些年我在生產環境中積累的經驗都掏出來，希望能幫你少走彎路。

1.2 技術特點

層次分明：基礎權限 → 特殊權限 → ACL → MAC，由簡到繁

向后兼容：新特性不影響老系統，平滑升級

靈活可控：從粗粒度到細粒度，滿足各種場景需求

審計友好：所有權限變更都可追溯，便于合規審計

1.3 適用場景

Web 服務器：Nginx/Apache 的目錄權限配置

多用戶開發環境：團隊協作時的代碼目錄權限管理

容器化部署：Docker/Kubernetes 中的權限映射

合規審計：滿足等保、SOC2 等安全合規要求

數據安全：敏感文件的訪問控制

1.4 環境要求

二、詳細步驟

2.1 準備工作

2.1.1 系統檢查

# 檢查系統版本
cat /etc/os-release

# 檢查內核版本（需要 5.4+ 以獲得完整特性支持）
uname -r

# 檢查文件系統類型
df -Th

# 檢查是否支持 ACL
grep -i acl /boot/config-$(uname -r) 2>/dev/null || zcat /proc/config.gz 2>/dev/null | grep -i acl

# 檢查 SELinux 狀態（RHEL 系）
getenforce 2>/dev/null ||echo"SELinux not installed"

# 檢查 AppArmor 狀態（Debian 系）
aa-status 2>/dev/null ||echo"AppArmor not installed"

2.1.2 安裝必要工具

# RHEL/CentOS 系列
sudo dnf install -y acl attr policycoreutils-python-utils setools-console

# Debian/Ubuntu 系列
sudo apt update
sudo apt install -y acl attr apparmor-utils auditd

2.2 核心配置

2.2.1 基礎權限：rwx 三劍客

先來復習一下基礎，這塊很多人以為自己懂了，其實細節上還是會犯錯。

# 權限的數字表示法
# r=4, w=2, x=1
# 755 = rwxr-xr-x = 所有者全權限，組和其他人只讀+執行

# 查看文件權限的詳細信息
ls -la /etc/passwd
# -rw-r--r-- 1 root root 2847 Jan 15 10:23 /etc/passwd
# │├─┤├─┤├─┤
# │ │ │ └── 其他用戶權限 (r--)
# │ │ └───── 所屬組權限 (r--)
# │ └──────── 所有者權限 (rw-)
# └────────── 文件類型 (-=普通文件, d=目錄, l=鏈接)

# 修改權限的兩種方式
# 方式一：數字法（推薦，精確控制）
chmod 644 config.yml   # rw-r--r--
chmod 755 script.sh   # rwxr-xr-x
chmod 600 .ssh/id_rsa  # rw------- (私鑰必須是600!)

# 方式二：符號法（適合微調）
chmod u+x script.sh   # 給所有者加執行權限
chmod g-w config.yml   # 去掉組的寫權限
chmod o= secret.txt   # 清空其他用戶的所有權限
chmod a+r public.html  # 所有人加讀權限

我踩過的坑：有次部署應用，死活啟動不了，查了半天發現是配置文件權限給成了000。所以現在我養成習慣，部署腳本里一定會加權限檢查。

2.2.2 目錄權限的特殊之處

目錄的權限和文件不太一樣，這點很多新手會搞混：

# 目錄權限含義：
# r - 可以列出目錄內容（ls）
# w - 可以在目錄中創建/刪除文件
# x - 可以進入目錄（cd）和訪問目錄中的文件

# 實驗：創建測試目錄
mkdir -p /tmp/perm_test &&cd/tmp/perm_test

# 場景1：只有 r 沒有 x
mkdir test_r && chmod 444 test_r
echo"hello"> test_r/file.txt 2>/dev/null # 會失敗
ls test_r/                  # 能看到文件名，但看不到詳情
cat test_r/file.txt             # 失敗，因為沒有 x 權限

# 場景2：只有 x 沒有 r
mkdir test_x && chmod 111 test_x
echo"hello"> test_x/file.txt
ls test_x/                  # 失敗，不能列目錄
cat test_x/file.txt             # 成功！知道文件名就能訪問

# 場景3：生產環境常用配置
chmod 755 /var/www/html   # Web 目錄，所有人可讀可進入
chmod 750 /app/config    # 配置目錄，組內可讀，其他人禁止
chmod 700 /root/.ssh    # SSH 目錄，僅所有者可訪問

2.2.3 特殊權限：SUID、SGID、Sticky Bit

這三個特殊權限是很多安全問題的根源，但用好了也是利器：

# SUID (Set User ID) - 數字表示：4xxx
# 執行文件時，臨時獲得文件所有者的權限
# 典型例子：passwd 命令需要修改 /etc/shadow，普通用戶執行時臨時獲得 root 權限

ls -la /usr/bin/passwd
# -rwsr-xr-x 1 root root 68208 Mar 14 2023 /usr/bin/passwd
#  ^-- 注意這個 s，表示設置了 SUID

# 設置 SUID
chmod u+s /usr/local/bin/myapp
chmod 4755 /usr/local/bin/myapp

# SGID (Set Group ID) - 數字表示：2xxx
# 對文件：執行時臨時獲得文件所屬組的權限
# 對目錄：在該目錄下創建的文件自動繼承目錄的所屬組（團隊協作神器！）

# 團隊共享目錄配置
mkdir -p /data/team_project
chown root:developers /data/team_project
chmod 2775 /data/team_project
# 現在 developers 組的成員在這里創建的文件，所屬組都是 developers

# Sticky Bit - 數字表示：1xxx
# 只對目錄有效：目錄中的文件只能被文件所有者或 root 刪除
# 典型例子：/tmp 目錄

ls -ld /tmp
# drwxrwxrwt 15 root root 4096 Jan 20 10:00 /tmp
#     ^-- 注意這個 t，表示設置了 Sticky Bit

# 設置 Sticky Bit
chmod +t /data/shared
chmod 1777 /data/shared

安全警告：SUID 是安全審計的重點關注對象。定期檢查系統中的 SUID 文件：

# 查找所有 SUID 文件
find / -perm -4000 -typef 2>/dev/null

# 查找所有 SGID 文件
find / -perm -2000 -typef 2>/dev/null

# 生產環境建議：建立基線，定期對比
find / -perm -4000 -typef 2>/dev/null | sort > /var/log/suid_baseline_$(date +%Y%m%d).txt

2.2.4 文件所有權：chown 和 chgrp

# 修改所有者
chown nginx /var/www/html/index.html

# 修改所有者和所屬組
chown nginx:www-data /var/www/html/index.html

# 只修改所屬組
chgrp www-data /var/www/html/index.html
# 或者
chown :www-data /var/www/html/index.html

# 遞歸修改（謹慎使用！）
chown -R nginx:www-data /var/www/html/

# 只修改符合條件的文件（更安全的做法）
find /var/www/html -typef -execchown nginx:www-data {} ;
find /var/www/html -typed -execchown nginx:www-data {} ;

# 參考符號鏈接的目標（默認不跟隨）
chown -h nginx:www-data /var/www/html/link # 修改鏈接本身
chown nginx:www-data /var/www/html/link  # 修改鏈接指向的文件

2.2.5 ACL：細粒度權限控制

傳統的 rwx 權限有個致命缺陷：只能設置一個所有者和一個所屬組。如果你想讓用戶 A 有讀寫權限，用戶 B 只有讀權限，用戶 C 完全沒權限，傳統權限就搞不定了。這時候 ACL 就派上用場了。

# 查看文件的 ACL
getfacl /data/project/config.yml

# 輸出示例：
# file: data/project/config.yml
# owner: root
# group: developers
# user::rw-
# userrw-    # alice 用戶有讀寫權限
# userr--     # bob 用戶只有讀權限
# group::r--
# grouprw-     # ops 組有讀寫權限
# mask::rw-
# other::---

# 設置用戶 ACL
setfacl -m urw /data/project/config.yml  # 給 alice 讀寫權限
setfacl -m ur /data/project/config.yml   # 給 bob 只讀權限

# 設置組 ACL
setfacl -m grw /data/project/config.yml   # 給 ops 組讀寫權限

# 刪除特定 ACL
setfacl -x u:alice /data/project/config.yml   # 刪除 alice 的 ACL
setfacl -x g:ops /data/project/config.yml    # 刪除 ops 組的 ACL

# 刪除所有 ACL（恢復到傳統權限）
setfacl -b /data/project/config.yml

# 遞歸設置 ACL
setfacl -R -m urwX /data/project/     # X 表示僅對目錄設置執行權限

# 設置默認 ACL（新創建的文件自動繼承）
setfacl -d -m urw /data/project/     # 目錄下新文件自動給 alice 讀寫權限
setfacl -d -m grwx /data/project/  # 目錄下新文件自動給 developers 組全權限

ACL 的 mask 機制：這是個容易被忽略但很重要的概念。mask 定義了 ACL 權限的上限。

# 查看當前 mask
getfacl /data/project/config.yml | grep mask

# 設置 mask（限制所有 ACL 的最大權限）
setfacl -m m::r /data/project/config.yml
# 即使 alice 設置了 rw 權限，實際生效的也只有 r（被 mask 限制）

# 注意：chmod 會影響 mask！
chmod 640 /data/project/config.yml
# 這會把 mask 設置為 r--，可能導致 ACL 權限失效

我的經驗：ACL 雖然強大，但也增加了復雜度。我的建議是：

能用組權限解決的，就不要用 ACL

用了 ACL 一定要做好文檔記錄

定期審計 ACL 配置，避免權限膨脹

2.3 啟動和驗證

2.3.1 權限配置驗證腳本

#!/bin/bash
# 文件名：check_permissions.sh
# 用途：驗證關鍵目錄和文件的權限配置

RED='?33[0;31m'
GREEN='?33[0;32m'
YELLOW='?33[1;33m'
NC='?33[0m'

check_permission() {
 localpath=$1
 localexpected_perm=$2
 localexpected_owner=$3
 localexpected_group=$4

 if[[ ! -e"$path"]];then
   echo-e"${RED}[FAIL]${NC}$pathdoes not exist"
   return1
 fi

 localactual_perm=$(stat-c"%a""$path")
 localactual_owner=$(stat-c"%U""$path")
 localactual_group=$(stat-c"%G""$path")

 localstatus=0

 if[["$actual_perm"!="$expected_perm"]];then
   echo-e"${RED}[FAIL]${NC}$pathpermission: expected$expected_perm, got$actual_perm"
    status=1
 fi

 if[["$actual_owner"!="$expected_owner"]];then
   echo-e"${RED}[FAIL]${NC}$pathowner: expected$expected_owner, got$actual_owner"
    status=1
 fi

 if[["$actual_group"!="$expected_group"]];then
   echo-e"${YELLOW}[WARN]${NC}$pathgroup: expected$expected_group, got$actual_group"
 fi

 if[[$status-eq 0 ]];then
   echo-e"${GREEN}[OK]${NC}$path"
 fi

 return$status
}

echo"=== Permission Check Report ==="
echo"Date:$(date)"
echo""

# 檢查關鍵系統文件
echo"--- System Files ---"
check_permission"/etc/passwd""644""root""root"
check_permission"/etc/shadow""640""root""shadow"
check_permission"/etc/ssh/sshd_config""600""root""root"

# 檢查 SSH 目錄
echo""
echo"--- SSH Directory ---"
check_permission"$HOME/.ssh""700""$USER""$USER"
check_permission"$HOME/.ssh/authorized_keys""600""$USER""$USER"2>/dev/null
check_permission"$HOME/.ssh/id_rsa""600""$USER""$USER"2>/dev/null

# 檢查 Web 目錄（如果存在）
if[[ -d"/var/www/html"]];then
 echo""
 echo"--- Web Directory ---"
  check_permission"/var/www/html""755""www-data""www-data"
fi

echo""
echo"=== Check Complete ==="

2.3.2 SUID/SGID 審計

#!/bin/bash
# 文件名：audit_suid.sh
# 用途：審計系統中的 SUID/SGID 文件

BASELINE_FILE="/var/log/suid_baseline.txt"
CURRENT_FILE="/tmp/suid_current_$(date +%Y%m%d).txt"

# 生成當前 SUID 文件列表
find / -typef ( -perm -4000 -o -perm -2000 ) 2>/dev/null | sort >"$CURRENT_FILE"

if[[ -f"$BASELINE_FILE"]];then
 echo"=== SUID/SGID File Changes ==="
 echo""

 # 新增的 SUID 文件
  new_files=$(comm -13"$BASELINE_FILE""$CURRENT_FILE")
 if[[ -n"$new_files"]];then
   echo"!!! NEW SUID/SGID FILES DETECTED !!!"
   echo"$new_files"
   echo""
 fi

 # 刪除的 SUID 文件
  removed_files=$(comm -23"$BASELINE_FILE""$CURRENT_FILE")
 if[[ -n"$removed_files"]];then
   echo"--- Removed SUID/SGID files ---"
   echo"$removed_files"
   echo""
 fi

 if[[ -z"$new_files"&& -z"$removed_files"]];then
   echo"No changes detected since last baseline."
 fi
else
 echo"No baseline file found. Creating baseline..."
  cp"$CURRENT_FILE""$BASELINE_FILE"
 echo"Baseline created at$BASELINE_FILE"
 echo""
 echo"Current SUID/SGID files:"
  cat"$CURRENT_FILE"
fi

三、示例代碼和配置

3.1 完整配置示例

3.1.1 SELinux 配置（RHEL/CentOS 系）

SELinux 是強制訪問控制（MAC）的實現，比傳統權限更加嚴格。很多人遇到問題就直接setenforce 0關掉，這是非常不好的習慣。

# 查看 SELinux 狀態
getenforce
# Enforcing = 強制模式（生產環境推薦）
# Permissive = 寬容模式（只記錄不阻止，調試用）
# Disabled = 禁用

sestatus
# 查看詳細狀態

# 臨時切換模式（重啟后失效）
sudo setenforce 0 # 切換到 Permissive
sudo setenforce 1 # 切換到 Enforcing

# 永久修改（需要重啟）
sudo vim /etc/selinux/config
# SELINUX=enforcing

# 查看文件的 SELinux 上下文
ls -Z /var/www/html/
# -rw-r--r--. root root unconfined_uhttpd_sys_content_t:s0 index.html
#            └─────────────────────────────────────────┘
#                  SELinux 上下文

# 修改文件的 SELinux 上下文
# 臨時修改（重新標記后會恢復）
chcon -t httpd_sys_content_t /var/www/html/newfile.html

# 永久修改（推薦）
semanage fcontext -a -t httpd_sys_content_t"/data/web(/.*)?"
restorecon -Rv /data/web/

# 查看 SELinux 布爾值
getsebool -a | grep httpd

# 設置布爾值（允許 httpd 連接網絡）
setsebool -P httpd_can_network_connect on

SELinux 故障排查：

# 查看 SELinux 拒絕日志
sudo ausearch -m avc -ts recent

# 使用 audit2why 分析原因
sudo ausearch -m avc -ts recent | audit2why

# 生成允許規則（謹慎使用！）
sudo ausearch -m avc -ts recent | audit2allow -M mypolicy
sudo semodule -i mypolicy.pp

# 實用技巧：臨時切換到 Permissive 模式測試
sudo setenforce 0
# 測試功能是否正常
# 如果正常，說明是 SELinux 問題
sudo setenforce 1
# 然后根據日志修復 SELinux 配置

3.1.2 AppArmor 配置（Ubuntu/Debian 系）

# 查看 AppArmor 狀態
sudo aa-status

# 查看特定程序的配置文件
cat /etc/apparmor.d/usr.sbin.nginx

# AppArmor 模式
# enforce - 強制模式
# complain - 投訴模式（只記錄不阻止）
# disabled - 禁用

# 切換到投訴模式（調試用）
sudo aa-complain /usr/sbin/nginx

# 切換到強制模式
sudo aa-enforce /usr/sbin/nginx

# 禁用特定配置
sudo aa-disable /usr/sbin/nginx

# 重新加載配置
sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.nginx

# 查看日志
sudo dmesg | grep apparmor
sudo journalctl -k | grep apparmor

自定義 AppArmor 配置示例：

# /etc/apparmor.d/usr.local.bin.myapp
#include

/usr/local/bin/myapp {
#include
#include

# 可執行文件
 /usr/local/bin/myapp mr,

# 配置文件（只讀）
 /etc/myapp/** r,

# 數據目錄（讀寫）
 /var/lib/myapp/** rw,

# 日志目錄
 /var/log/myapp/** w,

# 臨時文件
 /tmp/myapp-* rw,

# 網絡訪問
 network inet stream,
 network inet dgram,

# 拒絕其他所有訪問
 deny /etc/shadow r,
 deny /etc/passwd w,
}

3.2 實際應用案例

案例一：容器環境權限管理

2026 年了，不懂容器權限基本沒法干活。這塊坑特別多，我來詳細說說。

# Docker 默認以 root 運行，這是個安全隱患
docker run -it ubuntu whoami
# root

# 指定用戶運行（推薦）
docker run -it --user 1000:1000 ubuntu whoami
# 會顯示 uid=1000

# 在 Dockerfile 中指定用戶
# Dockerfile 示例
cat < Dockerfile
FROM ubuntu:22.04

# 創建非 root 用戶
RUN groupadd -r appgroup && useradd -r -g appgroup appuser

# 設置工作目錄權限
WORKDIR /app
COPY --chown=appuser:appgroup . .

# 切換到非 root 用戶
USER appuser

CMD ["./myapp"]
EOF

UID 映射問題：容器內的 UID 和宿主機是共享的！

# 容器內 UID 1000 = 宿主機 UID 1000
# 這可能導致權限問題

# 查看容器內進程的實際 UID
docker run -d --nametestnginx
ps aux | grep nginx
# 你會看到宿主機上顯示的是 UID，不是用戶名

# 解決方案：使用 User Namespace（Rootless 容器）
# Docker Rootless 模式
dockerd-rootless-setuptool.sh install

# 驗證 Rootless 模式
docker info | grep -i rootless

Kubernetes 中的權限控制：

# Pod Security Context 示例
apiVersion:v1
kind:Pod
metadata:
name:secure-pod
spec:
securityContext:
 runAsNonRoot:true
 runAsUser:1000
 runAsGroup:1000
 fsGroup:1000
containers:
-name:app
 image:myapp:latest
 securityContext:
  allowPrivilegeEscalation:false
  readOnlyRootFilesystem:true
  capabilities:
   drop:
    -ALL
   add:
    -NET_BIND_SERVICE# 只添加必要的 capability

案例二：Web 服務器權限配置最佳實踐

#!/bin/bash
# 文件名：setup_web_permissions.sh
# 用途：配置 Nginx Web 服務器的權限

WEB_ROOT="/var/www/html"
WEB_USER="www-data"
WEB_GROUP="www-data"
UPLOAD_DIR="${WEB_ROOT}/uploads"

# 創建目錄結構
mkdir -p"${WEB_ROOT}"/{static,uploads,logs}

# 設置所有權
chown -R${WEB_USER}:${WEB_GROUP}${WEB_ROOT}

# 設置目錄權限
find${WEB_ROOT}-typed -execchmod 755 {} ;

# 設置文件權限
find${WEB_ROOT}-typef -execchmod 644 {} ;

# 上傳目錄特殊處理（需要寫權限，但禁止執行）
chmod 775${UPLOAD_DIR}
# 在 Nginx 配置中禁止執行上傳目錄的腳本
# location /uploads/ {
#   location ~ .(php|pl|py|sh)$ { deny all; }
# }

# 配置文件權限（敏感信息）
chmod 640 /etc/nginx/conf.d/*.conf
chown root:${WEB_GROUP}/etc/nginx/conf.d/*.conf

echo"Web permissions configured successfully!"

四、最佳實踐和注意事項

4.1 最佳實踐

4.1.1 最小權限原則

這是安全的黃金法則，說起來簡單做起來難。

# 錯誤示范（千萬別這么干！）
chmod 777 /var/www/html # 全開放，等著被黑吧
chmod -R 777 /     # 系統直接廢了

# 正確做法：按需分配
# 1. 先確定誰需要訪問
# 2. 確定需要什么權限（讀/寫/執行）
# 3. 只給必要的權限

# 常用權限速查
# 644 - 普通文件（所有者讀寫，其他人只讀）
# 755 - 可執行文件/目錄（所有者全權限，其他人讀+執行）
# 600 - 敏感文件（僅所有者讀寫）
# 700 - 私有目錄（僅所有者訪問）
# 640 - 配置文件（所有者讀寫，組內只讀）
# 750 - 應用目錄（所有者全權限，組內讀+執行）

4.1.2 安全加固清單

#!/bin/bash
# 文件名：security_hardening.sh
# 用途：系統權限安全加固

echo"=== Starting Security Hardening ==="

# 1. 關鍵系統文件權限
chmod 644 /etc/passwd
chmod 640 /etc/shadow
chmod 644 /etc/group
chmod 640 /etc/gshadow
chmod 600 /etc/ssh/sshd_config
chmod 700 /root

# 2. 限制 cron 訪問
chmod 600 /etc/crontab
chmod 700 /etc/cron.d
chmod 700 /etc/cron.daily
chmod 700 /etc/cron.hourly

# 3. 設置 umask（新文件默認權限）
# 在 /etc/profile 或 /etc/bashrc 中設置
# umask 027 # 新文件 640，新目錄 750

# 4. 禁用不必要的 SUID
# 根據實際需求決定是否移除
# chmod u-s /usr/bin/chage
# chmod u-s /usr/bin/gpasswd

echo"=== Security Hardening Complete ==="

4.2 注意事項

4.2.1 常見錯誤

4.2.2 危險操作警告

# 這些命令可能導致系統崩潰，請三思！

# 1. 遞歸修改根目錄權限
chmod -R 777 /     # 絕對禁止！
chown -R user:group / # 絕對禁止！

# 2. 修改關鍵系統文件
chmod 777 /etc/shadow # 安全漏洞
chmod 777 /etc/sudoers # sudo 會拒絕工作

# 3. 移除自己的權限
chmod 000 ~/.bashrc  # 可能無法登錄

五、故障排查和監控

5.1 故障排查

5.1.1 權限問題診斷流程

# 第一步：檢查基礎權限
ls -la /path/to/file
stat/path/to/file

# 第二步：檢查 ACL
getfacl /path/to/file

# 第三步：檢查擴展屬性
lsattr /path/to/file

# 第四步：檢查 SELinux（RHEL 系）
ls -Z /path/to/file
ausearch -m avc -ts recent

# 第五步：檢查 AppArmor（Debian 系）
aa-status
dmesg | grep apparmor

5.2 性能監控

5.2.1 權限審計配置

# 使用 auditd 監控權限變更
# 安裝 auditd
sudo apt install auditd # Debian/Ubuntu
sudo dnf install audit # RHEL/CentOS

# 添加審計規則
sudo auditctl -w /etc/passwd -p wa -k passwd_changes
sudo auditctl -w /etc/shadow -p wa -k shadow_changes
sudo auditctl -w /etc/sudoers -p wa -k sudoers_changes

# 查看審計日志
sudo ausearch -k passwd_changes

5.3 備份與恢復

# 備份文件權限
getfacl -R /data > /backup/data_acl_backup.txt

# 恢復文件權限
setfacl --restore=/backup/data_acl_backup.txt

六、總結

6.1 技術要點回顧

基礎權限：rwx 三權分立，數字法和符號法靈活運用

特殊權限：SUID/SGID/Sticky Bit 各有用途，謹慎使用

ACL：細粒度控制，注意 mask 機制

SELinux/AppArmor：強制訪問控制，別輕易關閉

容器權限：UID 映射、Rootless 模式是趨勢

6.2 進階學習方向

Linux Capabilities：比 SUID 更細粒度的特權控制

Seccomp：系統調用過濾，容器安全必備

eBPF 安全：新一代內核級安全監控

6.3 參考資料

Linux man pages - chmod/chown

Red Hat SELinux Guide

Ubuntu AppArmor Wiki

Docker Security Best Practices

作者寄語：權限管理看似簡單，實則博大精深。記住最小權限原則，養成良好習慣，你的系統會更加安全。有問題歡迎交流！