一、概述

1.1 背景介紹

說(shuō)實(shí)話，Linux 權(quán)限這塊我踩過(guò)不少坑。記得剛?cè)胄心菚?huì)兒，有次為了圖省事直接chmod 777 -R /var/www，結(jié)果被老大罵了一頓——"你這是把大門(mén)敞開(kāi)讓小偷隨便進(jìn)??！"

Linux 的權(quán)限體系是整個(gè)系統(tǒng)安全的基石。從最基礎(chǔ)的 rwx 三權(quán)分立，到 SUID/SGID 這些"特權(quán)通道"，再到 ACL 細(xì)粒度控制，最后是 SELinux/AppArmor 這種強(qiáng)制訪問(wèn)控制，形成了一套層層遞進(jìn)的安全防護(hù)網(wǎng)。

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

1.2 技術(shù)特點(diǎn)

層次分明：基礎(chǔ)權(quán)限 → 特殊權(quán)限 → ACL → MAC，由簡(jiǎn)到繁

向后兼容：新特性不影響老系統(tǒng)，平滑升級(jí)

靈活可控：從粗粒度到細(xì)粒度，滿足各種場(chǎng)景需求

審計(jì)友好：所有權(quán)限變更都可追溯，便于合規(guī)審計(jì)

1.3 適用場(chǎng)景

Web 服務(wù)器：Nginx/Apache 的目錄權(quán)限配置

多用戶開(kāi)發(fā)環(huán)境：團(tuán)隊(duì)協(xié)作時(shí)的代碼目錄權(quán)限管理

容器化部署：Docker/Kubernetes 中的權(quán)限映射

合規(guī)審計(jì)：滿足等保、SOC2 等安全合規(guī)要求

數(shù)據(jù)安全：敏感文件的訪問(wèn)控制

1.4 環(huán)境要求

二、詳細(xì)步驟

2.1 準(zhǔn)備工作

2.1.1 系統(tǒng)檢查

# 檢查系統(tǒng)版本
cat /etc/os-release

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

# 檢查文件系統(tǒng)類型
df -Th

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

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

# 檢查 AppArmor 狀態(tài)（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 基礎(chǔ)權(quán)限：rwx 三劍客

先來(lái)復(fù)習(xí)一下基礎(chǔ)，這塊很多人以為自己懂了，其實(shí)細(xì)節(jié)上還是會(huì)犯錯(cuò)。

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

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

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

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

我踩過(guò)的坑：有次部署應(yīng)用，死活啟動(dòng)不了，查了半天發(fā)現(xiàn)是配置文件權(quán)限給成了000。所以現(xiàn)在我養(yǎng)成習(xí)慣，部署腳本里一定會(huì)加權(quán)限檢查。

2.2.2 目錄權(quán)限的特殊之處

目錄的權(quán)限和文件不太一樣，這點(diǎn)很多新手會(huì)搞混：

# 目錄權(quán)限含義：
# r - 可以列出目錄內(nèi)容（ls）
# w - 可以在目錄中創(chuàng)建/刪除文件
# x - 可以進(jìn)入目錄（cd）和訪問(wèn)目錄中的文件

# 實(shí)驗(yàn)：創(chuàng)建測(cè)試目錄
mkdir -p /tmp/perm_test &&cd/tmp/perm_test

# 場(chǎng)景1：只有 r 沒(méi)有 x
mkdir test_r && chmod 444 test_r
echo"hello"> test_r/file.txt 2>/dev/null # 會(huì)失敗
ls test_r/                  # 能看到文件名，但看不到詳情
cat test_r/file.txt             # 失敗，因?yàn)闆](méi)有 x 權(quán)限

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

# 場(chǎng)景3：生產(chǎn)環(huán)境常用配置
chmod 755 /var/www/html   # Web 目錄，所有人可讀可進(jìn)入
chmod 750 /app/config    # 配置目錄，組內(nèi)可讀，其他人禁止
chmod 700 /root/.ssh    # SSH 目錄，僅所有者可訪問(wèn)

2.2.3 特殊權(quán)限：SUID、SGID、Sticky Bit

這三個(gè)特殊權(quán)限是很多安全問(wèn)題的根源，但用好了也是利器：

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

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

# 設(shè)置 SUID
chmod u+s /usr/local/bin/myapp
chmod 4755 /usr/local/bin/myapp

# SGID (Set Group ID) - 數(shù)字表示：2xxx
# 對(duì)文件：執(zhí)行時(shí)臨時(shí)獲得文件所屬組的權(quán)限
# 對(duì)目錄：在該目錄下創(chuàng)建的文件自動(dòng)繼承目錄的所屬組（團(tuán)隊(duì)協(xié)作神器?。?
# 團(tuán)隊(duì)共享目錄配置
mkdir -p /data/team_project
chown root:developers /data/team_project
chmod 2775 /data/team_project
# 現(xiàn)在 developers 組的成員在這里創(chuàng)建的文件，所屬組都是 developers

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

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

# 設(shè)置 Sticky Bit
chmod +t /data/shared
chmod 1777 /data/shared

安全警告：SUID 是安全審計(jì)的重點(diǎn)關(guān)注對(duì)象。定期檢查系統(tǒng)中的 SUID 文件：

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

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

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

2.2.4 文件所有權(quán)：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

# 遞歸修改（謹(jǐn)慎使用！）
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 {} ;

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

2.2.5 ACL：細(xì)粒度權(quán)限控制

傳統(tǒng)的 rwx 權(quán)限有個(gè)致命缺陷：只能設(shè)置一個(gè)所有者和一個(gè)所屬組。如果你想讓用戶 A 有讀寫(xiě)權(quán)限，用戶 B 只有讀權(quán)限，用戶 C 完全沒(méi)權(quán)限，傳統(tǒng)權(quán)限就搞不定了。這時(shí)候 ACL 就派上用場(chǎng)了。

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

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

# 設(shè)置用戶 ACL
setfacl -m urw /data/project/config.yml  # 給 alice 讀寫(xiě)權(quán)限
setfacl -m ur /data/project/config.yml   # 給 bob 只讀權(quán)限

# 設(shè)置組 ACL
setfacl -m grw /data/project/config.yml   # 給 ops 組讀寫(xiě)權(quán)限

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

# 刪除所有 ACL（恢復(fù)到傳統(tǒng)權(quán)限）
setfacl -b /data/project/config.yml

# 遞歸設(shè)置 ACL
setfacl -R -m urwX /data/project/     # X 表示僅對(duì)目錄設(shè)置執(zhí)行權(quán)限

# 設(shè)置默認(rèn) ACL（新創(chuàng)建的文件自動(dòng)繼承）
setfacl -d -m urw /data/project/     # 目錄下新文件自動(dòng)給 alice 讀寫(xiě)權(quán)限
setfacl -d -m grwx /data/project/  # 目錄下新文件自動(dòng)給 developers 組全權(quán)限

ACL 的 mask 機(jī)制：這是個(gè)容易被忽略但很重要的概念。mask 定義了 ACL 權(quán)限的上限。

# 查看當(dāng)前 mask
getfacl /data/project/config.yml | grep mask

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

# 注意：chmod 會(huì)影響 mask！
chmod 640 /data/project/config.yml
# 這會(huì)把 mask 設(shè)置為 r--，可能導(dǎo)致 ACL 權(quán)限失效

我的經(jīng)驗(yàn)：ACL 雖然強(qiáng)大，但也增加了復(fù)雜度。我的建議是：

能用組權(quán)限解決的，就不要用 ACL

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

定期審計(jì) ACL 配置，避免權(quán)限膨脹

2.3 啟動(dòng)和驗(yàn)證

2.3.1 權(quán)限配置驗(yàn)證腳本

#!/bin/bash
# 文件名：check_permissions.sh
# 用途：驗(yàn)證關(guān)鍵目錄和文件的權(quán)限配置

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""

# 檢查關(guān)鍵系統(tǒng)文件
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 審計(jì)

#!/bin/bash
# 文件名：audit_suid.sh
# 用途：審計(jì)系統(tǒng)中的 SUID/SGID 文件

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

# 生成當(dāng)前 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 是強(qiáng)制訪問(wèn)控制（MAC）的實(shí)現(xiàn)，比傳統(tǒng)權(quán)限更加嚴(yán)格。很多人遇到問(wèn)題就直接setenforce 0關(guān)掉，這是非常不好的習(xí)慣。

# 查看 SELinux 狀態(tài)
getenforce
# Enforcing = 強(qiáng)制模式（生產(chǎn)環(huán)境推薦）
# Permissive = 寬容模式（只記錄不阻止，調(diào)試用）
# Disabled = 禁用

sestatus
# 查看詳細(xì)狀態(tài)

# 臨時(shí)切換模式（重啟后失效）
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 上下文
# 臨時(shí)修改（重新標(biāo)記后會(huì)恢復(fù)）
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

# 設(shè)置布爾值（允許 httpd 連接網(wǎng)絡(luò)）
setsebool -P httpd_can_network_connect on

SELinux 故障排查：

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

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

# 生成允許規(guī)則（謹(jǐn)慎使用?。?sudo ausearch -m avc -ts recent | audit2allow -M mypolicy
sudo semodule -i mypolicy.pp

# 實(shí)用技巧：臨時(shí)切換到 Permissive 模式測(cè)試
sudo setenforce 0
# 測(cè)試功能是否正常
# 如果正常，說(shuō)明是 SELinux 問(wèn)題
sudo setenforce 1
# 然后根據(jù)日志修復(fù) SELinux 配置

3.1.2 AppArmor 配置（Ubuntu/Debian 系）

# 查看 AppArmor 狀態(tài)
sudo aa-status

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

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

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

# 切換到強(qiáng)制模式
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

# 可執(zhí)行文件
 /usr/local/bin/myapp mr,

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

# 數(shù)據(jù)目錄（讀寫(xiě)）
 /var/lib/myapp/** rw,

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

# 臨時(shí)文件
 /tmp/myapp-* rw,

# 網(wǎng)絡(luò)訪問(wèn)
 network inet stream,
 network inet dgram,

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

3.2 實(shí)際應(yīng)用案例

案例一：容器環(huán)境權(quán)限管理

2026 年了，不懂容器權(quán)限基本沒(méi)法干活。這塊坑特別多，我來(lái)詳細(xì)說(shuō)說(shuō)。

# Docker 默認(rèn)以 root 運(yùn)行，這是個(gè)安全隱患
docker run -it ubuntu whoami
# root

# 指定用戶運(yùn)行（推薦）
docker run -it --user 1000:1000 ubuntu whoami
# 會(huì)顯示 uid=1000

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

# 創(chuàng)建非 root 用戶
RUN groupadd -r appgroup && useradd -r -g appgroup appuser

# 設(shè)置工作目錄權(quán)限
WORKDIR /app
COPY --chown=appuser:appgroup . .

# 切換到非 root 用戶
USER appuser

CMD ["./myapp"]
EOF

UID 映射問(wèn)題：容器內(nèi)的 UID 和宿主機(jī)是共享的！

# 容器內(nèi) UID 1000 = 宿主機(jī) UID 1000
# 這可能導(dǎo)致權(quán)限問(wèn)題

# 查看容器內(nèi)進(jìn)程的實(shí)際 UID
docker run -d --nametestnginx
ps aux | grep nginx
# 你會(huì)看到宿主機(jī)上顯示的是 UID，不是用戶名

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

# 驗(yàn)證 Rootless 模式
docker info | grep -i rootless

Kubernetes 中的權(quán)限控制：

# 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 服務(wù)器權(quán)限配置最佳實(shí)踐

#!/bin/bash
# 文件名：setup_web_permissions.sh
# 用途：配置 Nginx Web 服務(wù)器的權(quán)限

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

# 創(chuàng)建目錄結(jié)構(gòu)
mkdir -p"${WEB_ROOT}"/{static,uploads,logs}

# 設(shè)置所有權(quán)
chown -R${WEB_USER}:${WEB_GROUP}${WEB_ROOT}

# 設(shè)置目錄權(quán)限
find${WEB_ROOT}-typed -execchmod 755 {} ;

# 設(shè)置文件權(quán)限
find${WEB_ROOT}-typef -execchmod 644 {} ;

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

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

echo"Web permissions configured successfully!"

四、最佳實(shí)踐和注意事項(xiàng)

4.1 最佳實(shí)踐

4.1.1 最小權(quán)限原則

這是安全的黃金法則，說(shuō)起來(lái)簡(jiǎn)單做起來(lái)難。

# 錯(cuò)誤示范（千萬(wàn)別這么干?。?chmod 777 /var/www/html # 全開(kāi)放，等著被黑吧
chmod -R 777 /     # 系統(tǒng)直接廢了

# 正確做法：按需分配
# 1. 先確定誰(shuí)需要訪問(wèn)
# 2. 確定需要什么權(quán)限（讀/寫(xiě)/執(zhí)行）
# 3. 只給必要的權(quán)限

# 常用權(quán)限速查
# 644 - 普通文件（所有者讀寫(xiě)，其他人只讀）
# 755 - 可執(zhí)行文件/目錄（所有者全權(quán)限，其他人讀+執(zhí)行）
# 600 - 敏感文件（僅所有者讀寫(xiě)）
# 700 - 私有目錄（僅所有者訪問(wèn)）
# 640 - 配置文件（所有者讀寫(xiě)，組內(nèi)只讀）
# 750 - 應(yīng)用目錄（所有者全權(quán)限，組內(nèi)讀+執(zhí)行）

4.1.2 安全加固清單

#!/bin/bash
# 文件名：security_hardening.sh
# 用途：系統(tǒng)權(quán)限安全加固

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

# 1. 關(guān)鍵系統(tǒng)文件權(quán)限
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 訪問(wèn)
chmod 600 /etc/crontab
chmod 700 /etc/cron.d
chmod 700 /etc/cron.daily
chmod 700 /etc/cron.hourly

# 3. 設(shè)置 umask（新文件默認(rèn)權(quán)限）
# 在 /etc/profile 或 /etc/bashrc 中設(shè)置
# umask 027 # 新文件 640，新目錄 750

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

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

4.2 注意事項(xiàng)

4.2.1 常見(jiàn)錯(cuò)誤

4.2.2 危險(xiǎn)操作警告

# 這些命令可能導(dǎo)致系統(tǒng)崩潰，請(qǐng)三思！

# 1. 遞歸修改根目錄權(quán)限
chmod -R 777 /     # 絕對(duì)禁止！
chown -R user:group / # 絕對(duì)禁止！

# 2. 修改關(guān)鍵系統(tǒng)文件
chmod 777 /etc/shadow # 安全漏洞
chmod 777 /etc/sudoers # sudo 會(huì)拒絕工作

# 3. 移除自己的權(quán)限
chmod 000 ~/.bashrc  # 可能無(wú)法登錄

五、故障排查和監(jiān)控

5.1 故障排查

5.1.1 權(quán)限問(wèn)題診斷流程

# 第一步：檢查基礎(chǔ)權(quán)限
ls -la /path/to/file
stat/path/to/file

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

# 第三步：檢查擴(kuò)展屬性
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 性能監(jiān)控

5.2.1 權(quán)限審計(jì)配置

# 使用 auditd 監(jiān)控權(quán)限變更
# 安裝 auditd
sudo apt install auditd # Debian/Ubuntu
sudo dnf install audit # RHEL/CentOS

# 添加審計(jì)規(guī)則
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

# 查看審計(jì)日志
sudo ausearch -k passwd_changes

5.3 備份與恢復(fù)

# 備份文件權(quán)限
getfacl -R /data > /backup/data_acl_backup.txt

# 恢復(fù)文件權(quán)限
setfacl --restore=/backup/data_acl_backup.txt

六、總結(jié)

6.1 技術(shù)要點(diǎn)回顧

基礎(chǔ)權(quán)限：rwx 三權(quán)分立，數(shù)字法和符號(hào)法靈活運(yùn)用

特殊權(quán)限：SUID/SGID/Sticky Bit 各有用途，謹(jǐn)慎使用

ACL：細(xì)粒度控制，注意 mask 機(jī)制

SELinux/AppArmor：強(qiáng)制訪問(wèn)控制，別輕易關(guān)閉

容器權(quán)限：UID 映射、Rootless 模式是趨勢(shì)

6.2 進(jìn)階學(xué)習(xí)方向

Linux Capabilities：比 SUID 更細(xì)粒度的特權(quán)控制

Seccomp：系統(tǒng)調(diào)用過(guò)濾，容器安全必備

eBPF 安全：新一代內(nèi)核級(jí)安全監(jiān)控

6.3 參考資料

Linux man pages - chmod/chown

Red Hat SELinux Guide

Ubuntu AppArmor Wiki

Docker Security Best Practices

作者寄語(yǔ)：權(quán)限管理看似簡(jiǎn)單，實(shí)則博大精深。記住最小權(quán)限原則，養(yǎng)成良好習(xí)慣，你的系統(tǒng)會(huì)更加安全。有問(wèn)題歡迎交流！