一文搞懂Linux權限體系：從777到ACL高級權限控制

一、概述

1.1 從一次線上事故說起

2024年的一個深夜，我被一通緊急電話吵醒。公司的核心業(yè)務系統(tǒng)突然無法訪問，客戶投訴電話已經(jīng)打爆了客服熱線。我火速登錄服務器排查，發(fā)現(xiàn)問題出在一個看似簡單的操作上——某位同事為了"方便"，在部署時執(zhí)行了chmod -R 777 /var/www/html。

這個命令在當時看起來解決了文件訪問的問題，但卻為攻擊者打開了一扇大門。黑客通過上傳的惡意腳本獲得了執(zhí)行權限，進而拿下了整臺服務器。這次事故讓公司損失了近百萬，也讓我深刻認識到：Linux權限管理絕不是一個可以"隨便搞搞"的話題。

從那以后，我花了大量時間深入研究Linux權限體系，從最基礎的rwx到ACL、SELinux，再到現(xiàn)代容器環(huán)境下的權限控制。今天，我把這些年積累的經(jīng)驗整理成這篇文章，希望能幫助更多運維同學避開那些我曾經(jīng)踩過的坑。

1.2 為什么權限管理如此重要

在聊具體技術之前，我想先說說為什么我們需要認真對待權限管理。

安全是底線，不是選項。根據(jù)2024年的安全報告統(tǒng)計，超過60%的Linux服務器入侵事件與權限配置不當有關。很多時候，攻擊者不需要利用什么高深的0day漏洞，僅僅是利用管理員留下的權限漏洞就能得手。

權限管理是多人協(xié)作的基礎。在現(xiàn)代DevOps環(huán)境中，一臺服務器可能同時運行著多個應用，由不同的團隊負責維護。如果沒有清晰的權限邊界，要么是互相干擾，要么是出了問題找不到責任人。

合規(guī)審計的硬性要求。如果你的公司需要通過ISO 27001、等保三級或者SOC 2認證，權限管理是必查項目。審計師會仔細檢查你的服務器上是否存在777權限的文件、是否有不必要的SUID程序、是否啟用了SELinux等。

1.3 Linux權限體系的演進

Linux的權限體系并不是一成不變的，它經(jīng)歷了幾個重要的發(fā)展階段：

第一代：傳統(tǒng)Unix權限（1970s）這是最基礎的owner/group/others模型，通過rwx三個權限位控制訪問。簡單、高效，但靈活性不足。

第二代：特殊權限位（1980s）引入SUID、SGID、Sticky Bit，解決了一些特殊場景的需求，但也帶來了新的安全風險。

第三代：ACL訪問控制列表（1990s-2000s）POSIX ACL的出現(xiàn)讓權限管理更加精細化，可以針對單個用戶或組設置權限，不再受限于傳統(tǒng)的三元組模型。

第四代：強制訪問控制（2000s-至今）SELinux、AppArmor等MAC機制的出現(xiàn)，將權限控制提升到了一個新的高度。即使是root用戶，在MAC策略的約束下也不能為所欲為。

第五代：容器與云原生時代（2015-至今）隨著Docker、Kubernetes的普及，namespace、cgroup、seccomp等技術與傳統(tǒng)權限系統(tǒng)結(jié)合，形成了更加復雜但也更加安全的權限控制體系。

1.4 本文的適用場景和環(huán)境要求

這篇文章的內(nèi)容適用于以下場景：

Web應用服務器的權限規(guī)劃和加固

數(shù)據(jù)庫服務器的安全配置

多用戶共享開發(fā)環(huán)境的權限隔離

容器化應用的權限控制

安全合規(guī)審計的準備工作

環(huán)境要求：

# 操作系統(tǒng)版本（推薦）
RHEL/Rocky Linux/AlmaLinux 9.x
Ubuntu 24.04 LTS
Debian 12

# 內(nèi)核版本
Linux Kernel 6.1+（支持最新的安全特性）

# 必要的軟件包
acl     # ACL支持
attr    # 擴展屬性支持
policycoreutils-python-utils # SELinux工具（RHEL系）
apparmor-utils       # AppArmor工具（Ubuntu/Debian）
auditd   # 審計守護進程

二、詳細步驟

2.1 準備工作：理解基礎權限模型

在動手配置之前，我們需要先把基礎概念搞清楚。我見過太多人急于求成，對著網(wǎng)上的命令一頓復制粘貼，結(jié)果把系統(tǒng)搞得一團糟。

2.1.1 文件權限的本質(zhì)

在Linux中，一切皆文件。每個文件都有三組權限：

所有者（Owner）權限：文件創(chuàng)建者默認擁有的權限

所屬組（Group）權限：文件所屬用戶組的成員擁有的權限

其他人（Others）權限：系統(tǒng)上其他所有用戶的權限

每組權限包含三個基本操作：

r（read）：讀取權限

w（write）：寫入權限

x（execute）：執(zhí)行權限

對于文件和目錄，這些權限的含義略有不同：

權限 | 對文件的含義      | 對目錄的含義
------|------------------------|---------------------------
r   | 查看文件內(nèi)容      | 列出目錄中的文件名
w   | 修改文件內(nèi)容      | 在目錄中創(chuàng)建、刪除、重命名文件
x   | 執(zhí)行文件（腳本/程序） | 進入目錄（cd）

這里有個容易混淆的地方：目錄的r權限只能讓你看到文件名列表，如果沒有x權限，你無法讀取文件的詳細信息（如大小、權限、修改時間），也無法訪問目錄中的文件內(nèi)容。

我來演示一下：

# 創(chuàng)建測試目錄和文件
mkdir /tmp/perm_test
echo"secret content"> /tmp/perm_test/secret.txt

# 只給r權限，不給x權限
chmod 744 /tmp/perm_test
chmod 744 /tmp/perm_test/secret.txt

# 切換到普通用戶測試
su - testuser

# 可以看到文件名，但無法看到詳細信息
ls /tmp/perm_test
# 輸出：secret.txt

ls -l /tmp/perm_test
# 輸出：ls: cannot access '/tmp/perm_test/secret.txt': Permission denied

cat /tmp/perm_test/secret.txt
# 輸出：cat: /tmp/perm_test/secret.txt: Permission denied

2.1.2 數(shù)字表示法的換算

很多新手對權限的數(shù)字表示法感到困惑，其實換算規(guī)則很簡單：

r = 4
w = 2
x = 1

將需要的權限數(shù)字相加：
rwx = 4 + 2 + 1 = 7
rw- = 4 + 2 + 0 = 6
r-x = 4 + 0 + 1 = 5
r-- = 4 + 0 + 0 = 4

所以常見的權限組合：

755 = rwxr-xr-x # 所有者可讀寫執(zhí)行，其他人可讀和執(zhí)行
644 = rw-r--r-- # 所有者可讀寫，其他人只讀
700 = rwx------ # 只有所有者可訪問
600 = rw------- # 只有所有者可讀寫

我個人有個記憶口訣：**"7是全開，6是讀寫，5是讀執(zhí)行，4是只讀，0是全關"**。記住這幾個數(shù)字的含義，其他的都是組合。

2.2 核心配置：權限管理命令詳解

2.2.1 chmod：修改文件權限

chmod是最常用的權限管理命令，支持兩種模式：

符號模式：

# 基本語法
chmod [ugoa][+-=][rwx] 文件名

# u: user(所有者) g: group(所屬組) o: others(其他人) a: all(所有人)
# +: 添加權限 -: 移除權限 =: 設置權限

# 示例
chmod u+x script.sh   # 給所有者添加執(zhí)行權限
chmod g-w config.ini   # 移除所屬組的寫權限
chmod o=r public.html  # 設置其他人只有讀權限
chmod a+r readme.txt   # 所有人添加讀權限
chmod u+x,g=rx,o= app.sh # 組合操作

數(shù)字模式：

# 基本語法
chmod [權限數(shù)字] 文件名

# 示例
chmod 755 script.sh   # rwxr-xr-x
chmod 644 config.ini   # rw-r--r--
chmod 600 id_rsa     # rw-------
chmod 700 .ssh      # rwx------

遞歸操作：

# 遞歸修改目錄及其所有內(nèi)容
chmod -R 755 /var/www/html

# 但這種做法通常是錯誤的！
# 因為目錄需要x權限才能進入，但普通文件通常不需要執(zhí)行權限
# 正確的做法是分別處理目錄和文件

# 只修改目錄權限
find /var/www/html -typed -execchmod 755 {} ;

# 只修改文件權限
find /var/www/html -typef -execchmod 644 {} ;

這是一個非常重要的實踐經(jīng)驗。我見過很多人直接chmod -R 755，結(jié)果把所有文件都變成了可執(zhí)行的，這在安全上是不可接受的。

2.2.2 chown：修改文件所有者

# 基本語法
chown [用戶]:[組] 文件名

# 示例
chown nginx:nginx /var/www/html     # 修改所有者和所屬組
chown nginx /var/www/html        # 只修改所有者
chown :www-data /var/www/html      # 只修改所屬組
chown -R nginx:nginx /var/www/html   # 遞歸修改

# 使用UID和GID
chown 1000:1000 /data/app        # 在容器環(huán)境中常用

# 保持引用
chown --reference=/etc/nginx/nginx.conf /etc/nginx/conf.d/ # 復制參考文件的所有者

2.2.3 chgrp：修改文件所屬組

# 基本語法
chgrp [組] 文件名

# 示例
chgrp developers /opt/project
chgrp -R www-data /var/www/html

# 實際工作中，chown命令可以同時修改用戶和組，所以chgrp用得相對較少

2.3 特殊權限位配置

除了基本的rwx權限，Linux還有三個特殊權限位：SUID、SGID和Sticky Bit。這些權限位功能強大，但如果使用不當，也會帶來嚴重的安全風險。

2.3.1 SUID（Set User ID）

原理：當一個可執(zhí)行文件設置了SUID位后，任何用戶執(zhí)行該文件時，都會臨時獲得文件所有者的權限。

典型應用：/usr/bin/passwd命令就設置了SUID。普通用戶修改密碼時，需要寫入/etc/shadow文件，但這個文件只有root能寫。通過SUID，普通用戶執(zhí)行passwd時臨時獲得root權限，完成密碼修改。

# 查看passwd的權限
ls -l /usr/bin/passwd
# -rwsr-xr-x. 1 root root 32648 Aug 10 2021 /usr/bin/passwd
# 注意所有者權限位中的's'，這就是SUID的標志

# 設置SUID
chmod u+s /path/to/executable
chmod 4755 /path/to/executable # 4表示SUID

# 移除SUID
chmod u-s/path/to/executable
chmod 0755 /path/to/executable

安全警告：SUID是一個非常危險的權限。如果一個設置了SUID的程序存在漏洞，攻擊者可能借此獲得root權限。我的建議是：

定期審計系統(tǒng)中的SUID程序：find / -perm -4000 -type f 2>/dev/null

對于不必要的SUID程序，移除SUID位

永遠不要給shell腳本設置SUID（Linux內(nèi)核會忽略腳本的SUID位，但這是個好習慣）

2.3.2 SGID（Set Group ID）

SGID根據(jù)應用對象不同，有兩種效果：

對可執(zhí)行文件：執(zhí)行時臨時獲得文件所屬組的權限。

對目錄：在該目錄中創(chuàng)建的新文件會繼承目錄的所屬組，而不是創(chuàng)建者的主組。

# 查看SGID標志（所屬組權限位中的's'）
ls -ld /usr/bin/write
# -rwxr-sr-x. 1 root tty 19544 Aug 10 2021 /usr/bin/write

# 設置SGID
chmod g+s /path/to/dir
chmod 2755 /path/to/dir # 2表示SGID

# SGID目錄的實際應用：團隊共享目錄
mkdir /opt/project
groupadd developers
chgrp developers /opt/project
chmod 2775 /opt/project

# 現(xiàn)在，任何人在/opt/project中創(chuàng)建的文件，所屬組都會是developers

我在很多公司都用SGID來設置團隊共享目錄。它解決了一個常見問題：不同用戶創(chuàng)建的文件默認屬于各自的主組，其他組員可能無法訪問。設置SGID后，所有文件統(tǒng)一屬于項目組。

2.3.3 Sticky Bit（粘滯位）

原理：對于設置了Sticky Bit的目錄，即使用戶對目錄有寫權限，也只能刪除自己創(chuàng)建的文件，不能刪除其他用戶的文件。

典型應用：/tmp目錄就設置了Sticky Bit。所有用戶都能在/tmp中創(chuàng)建文件，但不能刪除別人的文件。

# 查看/tmp的權限
ls -ld /tmp
# drwxrwxrwt. 18 root root 4096 Jan 7 10:00 /tmp
# 注意最后的't'，這就是Sticky Bit的標志

# 設置Sticky Bit
chmod +t /path/to/dir
chmod 1777 /path/to/dir # 1表示Sticky Bit

# 移除Sticky Bit
chmod -t /path/to/dir

2.4 啟動驗證

配置完權限后，一定要驗證效果。我習慣用以下方法：

# 1. 使用stat命令查看詳細權限信息
stat/var/www/html
# 輸出會包含Access、Uid、Gid等詳細信息

# 2. 使用namei命令檢查路徑上的所有權限
namei -l /var/www/html/index.php
# 這會顯示路徑上每一級目錄的權限，幫你找到權限鏈條中的問題

# 3. 使用sudo -u切換用戶測試
sudo -u nginx cat /var/www/html/config.php
sudo -u www-data ls -la /var/www/html

# 4. 使用getfacl查看ACL（如果使用了ACL）
getfacl /var/www/html

三、示例代碼和配置

3.1 Web應用目錄權限配置

這是我在工作中最常見的場景。一個典型的Web應用需要考慮：運行用戶、上傳目錄、日志目錄、配置文件等不同位置的權限。

#!/bin/bash
# web_permission_setup.sh
# Web應用權限配置腳本

# 定義變量
WEB_ROOT="/var/www/myapp"
WEB_USER="nginx"
WEB_GROUP="www-data"
UPLOAD_DIR="${WEB_ROOT}/uploads"
LOG_DIR="/var/log/myapp"
CONFIG_DIR="${WEB_ROOT}/config"

# 1. 創(chuàng)建目錄結(jié)構(gòu)
mkdir -p${WEB_ROOT}/{public,config,uploads,storage}
mkdir -p${LOG_DIR}

# 2. 設置基本所有權
chown -R${WEB_USER}:${WEB_GROUP}${WEB_ROOT}
chown -R${WEB_USER}:${WEB_GROUP}${LOG_DIR}

# 3. 設置目錄權限
# 目錄需要執(zhí)行權限才能進入
find${WEB_ROOT}-typed -execchmod 755 {} ;

# 4. 設置文件權限
# 普通文件不需要執(zhí)行權限
find${WEB_ROOT}-typef -execchmod 644 {} ;

# 5. 配置文件加強保護
# 配置文件只允許所有者讀寫
chmod 600${CONFIG_DIR}/*.php
chmod 600${CONFIG_DIR}/.env

# 6. 上傳目錄特殊處理
# 禁止執(zhí)行任何腳本
chmod 755${UPLOAD_DIR}
# 在nginx配置中也要禁用PHP執(zhí)行（后面會講）

# 7. 日志目錄
chmod 750${LOG_DIR}
chmod 640${LOG_DIR}/*.log2>/dev/null

# 8. 可執(zhí)行腳本（如果有）
chmod 750${WEB_ROOT}/bin/*.sh 2>/dev/null

# 9. 使用SGID確保新文件屬于正確的組
chmod g+s${UPLOAD_DIR}
chmod g+s${LOG_DIR}

echo"權限配置完成！"

# 驗證
echo"=== 驗證權限設置 ==="
ls -la${WEB_ROOT}
ls -la${CONFIG_DIR}
ls -la${UPLOAD_DIR}

配合Nginx配置，禁止上傳目錄執(zhí)行腳本：

# /etc/nginx/conf.d/myapp.conf

server {
  listen 80;
  server_name myapp.example.com;
  root /var/www/myapp/public;

  # 禁止uploads目錄執(zhí)行PHP
  location ^~ /uploads/ {
    location ~ .php$ {
      deny all;
      return 403;
    }
  }

  # 禁止訪問隱藏文件和配置文件
  location ~ /. {
    deny all;
    return 404;
  }

  location ~ /config/ {
    deny all;
    return 404;
  }
}

3.2 數(shù)據(jù)庫文件權限配置

數(shù)據(jù)庫文件的權限配置需要特別謹慎，因為這里存儲著最敏感的數(shù)據(jù)。

#!/bin/bash
# mysql_permission_setup.sh
# MySQL數(shù)據(jù)庫權限配置腳本

# MySQL數(shù)據(jù)目錄
MYSQL_DATA="/var/lib/mysql"
MYSQL_LOG="/var/log/mysql"
MYSQL_CONFIG="/etc/mysql"
MYSQL_USER="mysql"
MYSQL_GROUP="mysql"

# 1. 數(shù)據(jù)目錄 - 只有mysql用戶可以訪問
chown -R${MYSQL_USER}:${MYSQL_GROUP}${MYSQL_DATA}
chmod 750${MYSQL_DATA}
find${MYSQL_DATA}-typed -execchmod 750 {} ;
find${MYSQL_DATA}-typef -execchmod 640 {} ;

# 2. 日志目錄
chown -R${MYSQL_USER}:${MYSQL_GROUP}${MYSQL_LOG}
chmod 750${MYSQL_LOG}
chmod 640${MYSQL_LOG}/*.log2>/dev/null

# 3. 配置文件
# my.cnf應該是root擁有，mysql可讀
chown root:${MYSQL_GROUP}${MYSQL_CONFIG}/my.cnf
chmod 640${MYSQL_CONFIG}/my.cnf

# conf.d目錄下的配置文件
chown root:${MYSQL_GROUP}${MYSQL_CONFIG}/conf.d/*
chmod 640${MYSQL_CONFIG}/conf.d/*

# 4. Socket文件目錄
mkdir -p /var/run/mysqld
chown${MYSQL_USER}:${MYSQL_GROUP}/var/run/mysqld
chmod 755 /var/run/mysqld

# 5. 備份目錄 - 更嚴格的權限
BACKUP_DIR="/backup/mysql"
mkdir -p${BACKUP_DIR}
chown root:${MYSQL_GROUP}${BACKUP_DIR}
chmod 750${BACKUP_DIR}

echo"MySQL權限配置完成！"

3.3 SSH密鑰權限配置

SSH對密鑰文件的權限要求非常嚴格。權限配置不正確，SSH會直接拒絕使用這些密鑰。

#!/bin/bash
# ssh_permission_setup.sh
# SSH密鑰權限配置腳本

SSH_DIR="$HOME/.ssh"

# 1. .ssh目錄
chmod 700${SSH_DIR}

# 2. 私鑰文件 - 只有所有者可讀
chmod 600${SSH_DIR}/id_rsa
chmod 600${SSH_DIR}/id_ed25519
chmod 600${SSH_DIR}/id_ecdsa
# 處理所有私鑰
find${SSH_DIR}-name"id_*"! -name"*.pub"-execchmod 600 {} ;

# 3. 公鑰文件
chmod 644${SSH_DIR}/*.pub

# 4. authorized_keys - 非常重要
chmod 600${SSH_DIR}/authorized_keys

# 5. known_hosts
chmod 644${SSH_DIR}/known_hosts

# 6. config文件
chmod 600${SSH_DIR}/config

# 對于服務器端的SSH配置
# /etc/ssh/sshd_config
sudo chmod 600 /etc/ssh/sshd_config
sudo chmod 600 /etc/ssh/ssh_host_*_key
sudo chmod 644 /etc/ssh/ssh_host_*_key.pub

echo"SSH權限配置完成！"

# 驗證
echo"=== 驗證SSH權限 ==="
ls -la${SSH_DIR}

3.4 ACL高級權限配置

當傳統(tǒng)的owner/group/others模型無法滿足需求時，就需要使用ACL了。

場景示例：一個項目目錄需要讓開發(fā)組有讀寫權限，運維組有只讀權限，而某個特定的外包人員需要只讀特定子目錄。

#!/bin/bash
# acl_setup.sh
# ACL權限配置示例

PROJECT_DIR="/opt/project"
DEV_GROUP="developers"
OPS_GROUP="operations"
CONTRACTOR="john_contractor"

# 1. 首先確保文件系統(tǒng)支持ACL
# 檢查掛載選項
mount | grep" / "| grep acl
# 如果沒有，需要重新掛載或修改/etc/fstab

# 2. 設置基本權限
chown -R root:${DEV_GROUP}${PROJECT_DIR}
chmod 750${PROJECT_DIR}

# 3. 為開發(fā)組設置默認ACL
# -d: 設置默認ACL，對新建文件生效
# -m: 修改ACL
setfacl -R -m g:${DEV_GROUP}:rwx${PROJECT_DIR}
setfacl -R -d -m g:${DEV_GROUP}:rwx${PROJECT_DIR}

# 4. 為運維組設置只讀權限
setfacl -R -m g:${OPS_GROUP}:rx${PROJECT_DIR}
setfacl -R -d -m g:${OPS_GROUP}:rx${PROJECT_DIR}

# 5. 為外包人員設置特定目錄的權限
setfacl -m u:${CONTRACTOR}:rx${PROJECT_DIR}/docs
setfacl -R -m u:${CONTRACTOR}:rx${PROJECT_DIR}/docs

# 6. 查看ACL設置
echo"=== ACL配置結(jié)果 ==="
getfacl${PROJECT_DIR}

# 7. 備份ACL配置（很重要?。?getfacl -R${PROJECT_DIR}> /backup/project_acl_backup.txt

# 8. 恢復ACL配置
# setfacl --restore=/backup/project_acl_backup.txt

ACL常用命令速查：

# 查看文件的ACL
getfacl /path/to/file

# 設置用戶ACL
setfacl -m urwx /path/to/file

# 設置組ACL
setfacl -m grx /path/to/file

# 設置默認ACL（對目錄中新建的文件生效）
setfacl -d -m urwx /path/to/dir

# 遞歸設置ACL
setfacl -R -m urwx /path/to/dir

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

# 移除所有ACL
setfacl -b /path/to/file

# 復制ACL到另一個文件
getfacl file1 | setfacl --set-file=- file2

3.5 SELinux配置實戰(zhàn)

SELinux是紅帽系Linux發(fā)行版的默認強制訪問控制系統(tǒng)。很多管理員因為它"太麻煩"而直接禁用，這是非常不明智的做法。

#!/bin/bash
# selinux_web_setup.sh
# SELinux配置示例 - Web應用場景

# 1. 檢查SELinux狀態(tài)
getenforce
# Enforcing: 強制模式，違反策略會被阻止
# Permissive: 寬容模式，違反策略只記錄不阻止
# Disabled: 禁用

# 2. 查看當前SELinux策略
sestatus

# 3. 設置Web目錄的SELinux上下文
# httpd_sys_content_t: 允許httpd讀取
# httpd_sys_rw_content_t: 允許httpd讀寫
WEB_ROOT="/var/www/myapp"

# 設置靜態(tài)內(nèi)容為只讀
semanage fcontext -a -t httpd_sys_content_t"${WEB_ROOT}(/.*)?"

# 設置uploads目錄為可寫
semanage fcontext -a -t httpd_sys_rw_content_t"${WEB_ROOT}/uploads(/.*)?"

# 應用上下文
restorecon -Rv${WEB_ROOT}

# 4. 查看文件的SELinux上下文
ls -Z${WEB_ROOT}

# 5. 臨時修改上下文（重啟或restorecon后會失效）
chcon -t httpd_sys_rw_content_t${WEB_ROOT}/temp

# 6. 常見的布爾值設置
# 允許httpd連接網(wǎng)絡（如調(diào)用外部API）
setsebool -P httpd_can_network_connect on

# 允許httpd連接數(shù)據(jù)庫
setsebool -P httpd_can_network_connect_db on

# 允許httpd發(fā)送郵件
setsebool -P httpd_can_sendmail on

# 允許httpd執(zhí)行CGI腳本
setsebool -P httpd_enable_cgi on

# 7. 查看所有httpd相關的布爾值
getsebool -a | grep httpd

# 8. 排查SELinux拒絕問題
# 查看審計日志
ausearch -m avc -ts recent

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

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

echo"SELinux配置完成！"

SELinux常用上下文類型：

httpd_sys_content_t   - Web服務器只讀內(nèi)容
httpd_sys_rw_content_t  - Web服務器可讀寫內(nèi)容
httpd_sys_script_exec_t - Web服務器可執(zhí)行腳本
mysqld_db_t       - MySQL數(shù)據(jù)庫文件
postgresql_db_t     - PostgreSQL數(shù)據(jù)庫文件
ssh_home_t        - SSH配置文件
user_home_t       - 用戶主目錄內(nèi)容
tmp_t          - 臨時文件
var_log_t        - 日志文件

3.6 AppArmor配置實戰(zhàn)

Ubuntu和Debian系統(tǒng)默認使用AppArmor。相比SELinux，AppArmor的配置更加直觀。

#!/bin/bash
# apparmor_setup.sh
# AppArmor配置示例

# 1. 檢查AppArmor狀態(tài)
aa-status

# 2. 查看加載的配置文件
ls /etc/apparmor.d/

# 3. 創(chuàng)建自定義配置文件
cat > /etc/apparmor.d/usr.local.bin.myapp <

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

# 允許讀取配置文件
 /etc/myapp/** r,
 /etc/myapp/config.ini r,

# 允許讀寫數(shù)據(jù)目錄
 /var/lib/myapp/** rw,
 /var/lib/myapp/ r,

# 允許讀寫日志
 /var/log/myapp/** rw,
 /var/log/myapp/ r,

# 允許執(zhí)行自身
 /usr/local/bin/myapp mr,

# 允許網(wǎng)絡訪問
 network inet stream,
 network inet dgram,

# 拒絕所有其他訪問
 deny /home/** rw,
 deny /root/** rw,
 deny /etc/passwd w,
 deny /etc/shadow rw,
}
EOF

# 4. 檢查配置文件語法
apparmor_parser -p /etc/apparmor.d/usr.local.bin.myapp

# 5. 加載配置文件
apparmor_parser -r /etc/apparmor.d/usr.local.bin.myapp

# 6. 設置為強制模式
aa-enforce /usr/local/bin/myapp

# 7. 臨時設置為寬容模式（用于調(diào)試）
aa-complain /usr/local/bin/myapp

# 8. 查看AppArmor日志
journalctl -xe | grep apparmor
dmesg | grep apparmor

3.7 容器環(huán)境權限配置

在2025年，容器已經(jīng)成為應用部署的主流方式。容器環(huán)境的權限控制有其特殊性。

# docker-compose.yml 安全配置示例
version:'3.8'

services:
webapp:
 image:myapp:latest
 user:"1000:1000"# 不使用root用戶運行

 # 只讀文件系統(tǒng)
 read_only:true

 # 掛載必要的可寫目錄
 volumes:
  -./config:/app/config:ro   # 配置文件只讀
  -webapp_data:/app/data:rw   # 數(shù)據(jù)目錄可寫
  -webapp_logs:/var/log/app:rw # 日志目錄可寫

 # tmpfs用于臨時文件
 tmpfs:
  -/tmp:size=100M,mode=1777
  -/run:size=10M,mode=755

 # 安全選項
 security_opt:
  -no-new-privileges:true # 禁止提權
  -seccomp:default    # 使用默認的seccomp配置

 # 移除不必要的能力
 cap_drop:
  -ALL

 # 只添加必要的能力
 cap_add:
  -NET_BIND_SERVICE# 如果需要綁定低端口

 # AppArmor配置（如果使用）
 # security_opt:
 #  - apparmor:docker-default

volumes:
webapp_data:
webapp_logs:

Kubernetes Pod安全配置：

# pod-security.yaml
apiVersion:v1
kind:Pod
metadata:
name:secure-app
spec:
securityContext:
 runAsNonRoot:true
 runAsUser:1000
 runAsGroup:1000
 fsGroup:1000
 seccompProfile:
  type:RuntimeDefault

containers:
-name:app
 image:myapp:latest

 securityContext:
  allowPrivilegeEscalation:false
  readOnlyRootFilesystem:true
  capabilities:
   drop:
    -ALL

 volumeMounts:
 -name:tmp
  mountPath:/tmp
 -name:data
  mountPath:/app/data
 -name:config
  mountPath:/app/config
  readOnly:true

volumes:
-name:tmp
 emptyDir:
  medium:Memory
  sizeLimit:100Mi
-name:data
 persistentVolumeClaim:
  claimName:app-data-pvc
-name:config
 configMap:
  name:app-config
  defaultMode:0400# 只讀權限

四、最佳實踐和注意事項

4.1 權限設計原則

經(jīng)過多年的實踐，我總結(jié)出以下權限設計原則：

4.1.1 最小權限原則

這是安全領域最重要的原則之一：只授予完成任務所必需的最小權限。

# 錯誤示范 - 圖方便
chmod 777 /var/www/html
chmod -R 777 /opt/app

# 正確做法 - 精確控制
chmod 755 /var/www/html
chmod 644 /var/www/html/*.php
chmod 600 /var/www/html/config.php

4.1.2 職責分離原則

不同的任務應該由不同的用戶/組來執(zhí)行，避免權限過度集中。

# 創(chuàng)建專用用戶和組
groupadd webapp
useradd -r -g webapp -s /sbin/nologin webapp

groupadd dbbackup
useradd -r -g dbbackup -s /sbin/nologin dbbackup

# Web應用使用webapp用戶運行
# 數(shù)據(jù)庫備份使用dbbackup用戶執(zhí)行

4.1.3 縱深防御原則

不要依賴單一的安全措施，應該建立多層防御。

# 第一層：文件系統(tǒng)權限
chmod 600 /etc/myapp/secrets.conf

# 第二層：SELinux/AppArmor
semanage fcontext -a -t myapp_secret_t"/etc/myapp/secrets.conf"

# 第三層：使用加密存儲敏感信息
# 不要明文存儲密碼，使用vault或加密配置

# 第四層：審計監(jiān)控
auditctl -w /etc/myapp/secrets.conf -p rwa -k secrets_access

4.2 常見安全加固措施

4.2.1 審計SUID/SGID程序

#!/bin/bash
# audit_suid_sgid.sh
# 審計SUID/SGID程序

echo"=== SUID程序 ==="
find / -perm -4000 -typef 2>/dev/null |whilereadfile;do
  ls -l"$file"
  rpm -qf"$file"2>/dev/null || dpkg -S"$file"2>/dev/null ||echo"未知來源"
 echo"---"
done

echo"=== SGID程序 ==="
find / -perm -2000 -typef 2>/dev/null |whilereadfile;do
  ls -l"$file"
  rpm -qf"$file"2>/dev/null || dpkg -S"$file"2>/dev/null ||echo"未知來源"
 echo"---"
done

# 移除不必要的SUID
# chmod u-s /usr/bin/unnecessary_suid_program

4.2.2 查找全局可寫文件

#!/bin/bash
# find_world_writable.sh
# 查找全局可寫文件和目錄

echo"=== 全局可寫目錄（不含Sticky Bit）==="
find / -typed -perm -0002 ! -perm -1000 2>/dev/null

echo"=== 全局可寫文件 ==="
find / -typef -perm -0002 2>/dev/null

echo"=== 無主文件 ==="
find / -nouser -o -nogroup 2>/dev/null

4.2.3 限制umask

# /etc/profile 或 /etc/bashrc
umask027 # 新建文件默認權限640，目錄750

# 對于安全要求更高的環(huán)境
umask077 # 新建文件默認權限600，目錄700

# 在systemd服務中設置
# /etc/systemd/system/myapp.service
[Service]
UMask=0027

4.3 常見錯誤和教訓

4.3.1 錯誤一：濫用777權限

這是最常見也是最危險的錯誤。我曾經(jīng)遇到過一個客戶，他們的生產(chǎn)服務器上有超過10萬個777權限的文件。

錯誤做法：

# "反正能用就行"
chmod 777 /var/www/html
chmod -R 777 /opt/app

正確做法：

# 分析實際需求
# Web服務器運行用戶是nginx
chown -R nginx:nginx /var/www/html
find /var/www/html -typed -execchmod 755 {} ;
find /var/www/html -typef -execchmod 644 {} ;
# 需要寫入的目錄單獨處理
chmod 775 /var/www/html/uploads

4.3.2 錯誤二：忽略路徑上的權限

很多人只關注目標文件的權限，忽略了路徑上每一級目錄的權限。

# 文件權限正確
chmod 644 /opt/app/data/config/secrets.json

# 但是目錄權限錯了
chmod 777 /opt/app/data # 任何人都能進入并創(chuàng)建文件

# 正確做法：檢查整個路徑
namei -l /opt/app/data/config/secrets.json

4.3.3 錯誤三：復制文件不檢查權限

使用cp、scp等命令復制文件時，可能會改變文件的權限和所有者。

# 錯誤：復制后不檢查權限
cp /root/app.conf /etc/myapp/

# 正確：復制時保留權限，或者復制后重新設置
cp -p /root/app.conf /etc/myapp/  # -p保留權限
# 或者
cp /root/app.conf /etc/myapp/
chown root:myapp /etc/myapp/app.conf
chmod 640 /etc/myapp/app.conf

4.3.4 錯誤四：誤解SELinux拒絕

很多人遇到SELinux拒絕就直接禁用，這是非常不明智的。

# 錯誤做法
setenforce 0
# 在/etc/selinux/config中設置SELINUX=disabled

# 正確做法
# 1. 查看SELinux拒絕原因
ausearch -m avc -ts recent | audit2why

# 2. 根據(jù)原因采取措施
# 如果是上下文問題
restorecon -Rv /path/to/file

# 如果需要開啟布爾值
setsebool -P httpd_can_network_connect on

# 3. 只有在確認安全的情況下才生成自定義策略

4.4 性能考慮

權限檢查會帶來一定的性能開銷，雖然通?？梢院雎裕诟咝阅軋鼍跋滦枰⒁猓?/p>

# ACL會比傳統(tǒng)權限檢查慢一些
# 如果不需要ACL的靈活性，使用傳統(tǒng)權限更高效

# SELinux在enforce模式下會進行額外的檢查
# 確保策略配置正確，避免不必要的deny日志

# 對于高頻訪問的文件，權限設計要簡單直接
# 避免復雜的ACL規(guī)則鏈

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

5.1 日志查看

權限問題的排查首先要看日志：

# 1. 系統(tǒng)日志
journalctl -xe
tail -f /var/log/messages
tail -f /var/log/syslog

# 2. 應用日志
tail -f /var/log/nginx/error.log
tail -f /var/log/apache2/error.log
tail -f /var/log/php-fpm/error.log

# 3. SELinux審計日志
ausearch -m avc -ts today
ausearch -m avc -c httpd # 查找httpd相關的拒絕

# 4. AppArmor日志
journalctl -xe | grep apparmor
dmesg | grep apparmor

# 5. 使用audit2why分析SELinux拒絕原因
ausearch -m avc -ts today | audit2why

5.2 問題排查流程

當遇到"Permission denied"錯誤時，我通常按以下流程排查：

#!/bin/bash
# permission_troubleshoot.sh
# 權限問題排查腳本

TARGET=$1# 要檢查的文件或目錄

if[ -z"$TARGET"];then
 echo"用法:$0<文件或目錄>"
 exit1
fi

echo"=== 第一步：檢查文件是否存在 ==="
ls -la"$TARGET"2>&1

echo""
echo"=== 第二步：檢查路徑上所有目錄的權限 ==="
namei -l"$TARGET"

echo""
echo"=== 第三步：檢查ACL ==="
getfacl"$TARGET"2>&1

echo""
echo"=== 第四步：檢查SELinux上下文 ==="
ls -Z"$TARGET"2>&1

echo""
echo"=== 第五步：檢查SELinux狀態(tài) ==="
getenforce

echo""
echo"=== 第六步：最近的SELinux拒絕 ==="
ausearch -m avc -ts recent 2>&1 | head -50

echo""
echo"=== 第七步：檢查AppArmor狀態(tài) ==="
aa-status 2>&1 | head -20

echo""
echo"=== 第八步：檢查文件系統(tǒng)掛載選項 ==="
# 檢查是否有noexec、nosuid等選項
df"$TARGET"| tail -1 | awk'{print $1}'| xargs -I {} mount | grep {}

echo""
echo"=== 第九步：檢查文件屬性 ==="
lsattr"$TARGET"2>&1

5.3 使用auditd監(jiān)控權限變更

auditd是Linux系統(tǒng)審計的核心工具，可以監(jiān)控文件訪問和權限變更。

#!/bin/bash
# audit_setup.sh
# 配置auditd監(jiān)控權限相關事件

# 1. 安裝auditd
yum install -y audit audit-libs # RHEL系
apt install -y auditd audispd-plugins # Debian系

# 2. 啟動auditd服務
systemctlenableauditd
systemctl start auditd

# 3. 配置審計規(guī)則
cat >> /etc/audit/rules.d/permissions.rules <=1000 -F auid!=unset-k perm_change
-a always,exit-F arch=b64 -S chown,fchown,fchownat,lchown -F auid>=1000 -F auid!=unset-k owner_change
-a always,exit-F arch=b64 -S setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr -F auid>=1000 -F auid!=unset-k attr_change

# 監(jiān)控敏感文件訪問
-w /etc/passwd -p wa -k passwd_changes
-w /etc/shadow -p wa -k shadow_changes
-w /etc/sudoers -p wa -k sudoers_changes
-w /etc/ssh/sshd_config -p wa -k sshd_config

# 監(jiān)控SUID/SGID變更
-a always,exit-F arch=b64 -S chmod,fchmod,fchmodat -F perm=04000 -k suid_change
-a always,exit-F arch=b64 -S chmod,fchmod,fchmodat -F perm=02000 -k sgid_change

# 監(jiān)控特定目錄
-w /var/www/html -p wa -k web_content
-w /etc/myapp/ -p wa -k app_config
EOF

# 4. 重新加載規(guī)則
augenrules --load
auditctl -l

# 5. 查看審計日志
ausearch -k perm_change -ts today
ausearch -k passwd_changes -ts today

# 6. 生成審計報告
aureport --summary
aureport --file --start today

5.4 監(jiān)控告警配置

結(jié)合Prometheus和AlertManager實現(xiàn)權限異常告警：

# prometheus/rules/permission_alerts.yml
groups:
-name:permission_alerts
rules:
-alert:SuidFileCreated
 expr:increase(audit_suid_changes_total[5m])>0
 for:0m
 labels:
  severity:critical
 annotations:
  summary:"SUID文件被創(chuàng)建或修改"
  description:"在主機{{ $labels.instance }}上檢測到SUID文件變更"

-alert:SensitiveFileAccessed
 expr:increase(audit_sensitive_file_access_total[5m])>5
 for:0m
 labels:
  severity:warning
 annotations:
  summary:"敏感文件被頻繁訪問"
  description:"文件{{ $labels.file }}在5分鐘內(nèi)被訪問超過5次"

-alert:PermissionChangeSpike
 expr:increase(audit_permission_changes_total[10m])>100
 for:5m
 labels:
  severity:warning
 annotations:
  summary:"權限變更操作異常增多"
  description:"10分鐘內(nèi)權限變更操作超過100次，可能存在異常"

使用自定義腳本導出審計指標：

#!/bin/bash
# audit_exporter.sh
# 導出審計指標供Prometheus采集

METRICS_FILE="/var/lib/node_exporter/audit_metrics.prom"

# SUID變更計數(shù)
suid_changes=$(ausearch -k suid_change -ts today 2>/dev/null | grep -c"type=SYSCALL")
echo"audit_suid_changes_total$suid_changes">$METRICS_FILE

# 權限變更計數(shù)
perm_changes=$(ausearch -k perm_change -ts today 2>/dev/null | grep -c"type=SYSCALL")
echo"audit_permission_changes_total$perm_changes">>$METRICS_FILE

# 敏感文件訪問計數(shù)
sensitive_access=$(ausearch -k passwd_changes -k shadow_changes -k sudoers_changes -ts today 2>/dev/null | grep -c"type=SYSCALL")
echo"audit_sensitive_file_access_total$sensitive_access">>$METRICS_FILE

5.5 實時權限監(jiān)控腳本

#!/bin/bash
# realtime_permission_monitor.sh
# 實時監(jiān)控關鍵目錄的權限變化

WATCH_DIRS="/etc /var/www /opt/app"
BASELINE_FILE="/var/lib/permission_baseline.txt"
ALERT_EMAIL="security@example.com"

# 生成基線
generate_baseline() {
 echo"生成權限基線..."
 fordirin$WATCH_DIRS;do
    find$dir-typef -printf"%p %m %u %g
"2>/dev/null
    find$dir-typed -printf"%p %m %u %g
"2>/dev/null
 done| sort >$BASELINE_FILE
 echo"基線已保存到$BASELINE_FILE"
}

# 檢查變化
check_changes() {
  CURRENT_FILE=$(mktemp)

 fordirin$WATCH_DIRS;do
    find$dir-typef -printf"%p %m %u %g
"2>/dev/null
    find$dir-typed -printf"%p %m %u %g
"2>/dev/null
 done| sort >$CURRENT_FILE

  DIFF=$(diff$BASELINE_FILE$CURRENT_FILE)

 if[ -n"$DIFF"];then
   echo"檢測到權限變化："
   echo"$DIFF"

   # 發(fā)送告警
   echo"權限變化告警:$DIFF"| mail -s"權限變化告警"$ALERT_EMAIL
 fi

  rm -f$CURRENT_FILE
}

case"$1"in
  baseline)
    generate_baseline
    ;;
  check)
    check_changes
    ;;
  *)
   echo"用法:$0{baseline|check}"
   exit1
    ;;
esac

六、總結(jié)

6.1 要點回顧

經(jīng)過這篇文章的學習，我們掌握了Linux權限體系的完整知識：

基礎權限：

rwx三種基本權限，對文件和目錄的含義不同

數(shù)字表示法：r=4, w=2, x=1，權限數(shù)字是各位相加

chmod、chown、chgrp三個核心命令

遞歸操作時要區(qū)分文件和目錄

特殊權限：

SUID：執(zhí)行時獲得文件所有者權限，安全風險高

SGID：對目錄設置時新文件繼承目錄的組

Sticky Bit：防止用戶刪除他人文件

ACL高級權限：

setfacl/getfacl命令實現(xiàn)精細化權限控制

默認ACL對新建文件生效

記得備份ACL配置

強制訪問控制：

SELinux：基于安全上下文的強制訪問控制

AppArmor：基于路徑的配置文件更直觀

不要因為"麻煩"而禁用，學會正確配置

容器環(huán)境：

不要用root運行容器

使用只讀文件系統(tǒng)

最小化capabilities

啟用seccomp

監(jiān)控審計：

auditd記錄權限相關操作

建立權限基線并定期檢查

配置告警及時發(fā)現(xiàn)異常

6.2 安全事故案例總結(jié)

回顧文章開頭提到的事故，以及我這些年遇到的其他案例，有幾點深刻教訓：

永遠不要圖方便用777。這是血的教訓，沒有例外。

SELinux/AppArmor是最后一道防線。即使前面的防線都被突破，MAC機制仍可能阻止攻擊者。

定期審計比事后補救更重要。每周花一小時檢查權限配置，可以避免未來無數(shù)小時的救火。

權限管理是團隊協(xié)作的事。制定規(guī)范、培訓團隊、代碼審查，缺一不可。

6.3 進階方向

如果你想在權限管理方面繼續(xù)深入，可以關注以下方向：

Linux Capabilities深入學習：比傳統(tǒng)的root權限更細粒度的能力控制

Seccomp和沙箱技術：限制進程可以執(zhí)行的系統(tǒng)調(diào)用

eBPF安全應用：新一代的Linux安全監(jiān)控技術

零信任架構(gòu)：在云原生環(huán)境下的權限設計理念

PAM模塊開發(fā)：自定義認證和授權邏輯

6.4 參考資料

Red Hat Enterprise Linux Security Guide (2024)

Ubuntu Security Documentation

SELinux Project Wiki: https://selinuxproject.org

AppArmor Documentation: https://gitlab.com/apparmor/apparmor/-/wikis

Linux Audit Documentation: https://github.com/linux-audit

CIS Benchmark for Linux: https://www.cisecurity.org/benchmark/distribution_independent_linux

NIST SP 800-123: Guide to General Server Security

附錄

附錄A：命令速查表

# === 基礎權限命令 ===
chmod 755 file          # 設置權限為rwxr-xr-x
chmod u+x file          # 給所有者添加執(zhí)行權限
chmod g-w file          # 移除組的寫權限
chmod o=r file          # 設置其他人只有讀權限
chmod -R 755 dir         # 遞歸設置目錄權限
chown user:group file      # 修改所有者和組
chown -R user:group dir     # 遞歸修改所有者
chgrp group file         # 修改所屬組

# === 特殊權限命令 ===
chmod u+s file          # 設置SUID
chmod g+s dir          # 設置SGID
chmod +t dir           # 設置Sticky Bit
chmod 4755 file         # SUID + 755
chmod 2755 dir          # SGID + 755
chmod 1777 dir          # Sticky Bit + 777

# === ACL命令 ===
getfacl file           # 查看ACL
setfacl -m urwx file    # 設置用戶ACL
setfacl -m grx file    # 設置組ACL
setfacl -d -m urwx dir   # 設置默認ACL
setfacl -R -m urwx dir   # 遞歸設置ACL
setfacl -x u:user file      # 移除用戶ACL
setfacl -b file         # 移除所有ACL
getfacl -R dir > backup.acl   # 備份ACL
setfacl --restore=backup.acl   # 恢復ACL

# === SELinux命令 ===
getenforce            # 查看SELinux狀態(tài)
setenforce 1           # 設置為強制模式
setenforce 0           # 設置為寬容模式
sestatus             # 查看詳細狀態(tài)
ls -Z file            # 查看文件安全上下文
chcon -t httpd_sys_content_t file# 臨時修改上下文
restorecon -Rv dir        # 恢復默認上下文
semanage fcontext -l       # 列出上下文映射
semanage fcontext -a -ttype"path(/.*)?"# 添加上下文映射
getsebool -a           # 列出所有布爾值
setsebool -P bool on       # 設置布爾值
ausearch -m avc -ts today    # 查看AVC拒絕
audit2why < /var/log/audit/audit.log ?# 分析拒絕原因
audit2allow -M policy < avc.log ??# 生成允許策略

# === AppArmor命令 ===
aa-status ? ? ? ? ? ? ? ? ? ? ? ??# 查看狀態(tài)
aa-enforce /path/to/profile ? ? ??# 設置強制模式
aa-complain /path/to/profile ? ? ?# 設置寬容模式
aa-disable /path/to/profile ? ? ??# 禁用配置文件
apparmor_parser -r /etc/apparmor.d/profile ?# 重新加載配置

# === 審計命令 ===
auditctl -l ? ? ? ? ? ? ? ? ? ? ??# 列出審計規(guī)則
auditctl -w /path -p rwxa -k key ?# 添加監(jiān)控規(guī)則
ausearch -k key -ts today ? ? ? ??# 搜索審計日志
aureport --summary ? ? ? ? ? ? ? ?# 生成審計報告
augenrules --load ? ? ? ? ? ? ? ??# 加載規(guī)則文件

# === 查找命令 ===
find / -perm -4000 -type?f ? ? ? ?# 查找SUID文件
find / -perm -2000 -type?f ? ? ? ?# 查找SGID文件
find / -perm -0002 -type?f ? ? ? ?# 查找全局可寫文件
find / -nouser -o -nogroup ? ? ? ?# 查找無主文件

附錄B：常用權限配置參考

# === Web應用 ===
/var/www/html      755  nginx:nginx  # Web根目錄
/var/www/html/*.php   644  nginx:nginx  # PHP文件
/var/www/html/config  750  nginx:nginx  # 配置目錄
/var/www/html/uploads  755  nginx:nginx  # 上傳目錄（SGID）
/var/www/html/.env   600  nginx:nginx  # 環(huán)境配置

# === SSH ===
~/.ssh         700  user:user   # SSH目錄
~/.ssh/id_rsa      600  user:user   # 私鑰
~/.ssh/id_rsa.pub    644  user:user   # 公鑰
~/.ssh/authorized_keys 600  user:user   # 授權密鑰
~/.ssh/config      600  user:user   # SSH配置
/etc/ssh/sshd_config  600  root:root   # SSHD配置

# === 數(shù)據(jù)庫 ===
/var/lib/mysql     750  mysql:mysql  # MySQL數(shù)據(jù)目錄
/etc/mysql/my.cnf    640  root:mysql  # MySQL配置
/var/log/mysql     750  mysql:mysql  # MySQL日志

# === 系統(tǒng)關鍵文件 ===
/etc/passwd       644  root:root   # 用戶信息
/etc/shadow       000  root:root   # 密碼哈希
/etc/sudoers      440  root:root   # sudo配置
/etc/crontab      644  root:root   # 計劃任務

# === 日志文件 ===
/var/log        755  root:root   # 日志目錄
/var/log/messages    640  root:root   # 系統(tǒng)日志
/var/log/secure     600  root:root   # 安全日志

附錄C：SELinux常用上下文類型

類型             說明
------------------------------------------------------------
httpd_sys_content_t      Web服務器只讀內(nèi)容
httpd_sys_rw_content_t    Web服務器可讀寫內(nèi)容
httpd_sys_script_exec_t    Web服務器可執(zhí)行腳本
httpd_log_t          Web服務器日志
mysqld_db_t          MySQL數(shù)據(jù)庫文件
mysqld_log_t         MySQL日志
postgresql_db_t        PostgreSQL數(shù)據(jù)庫文件
ssh_home_t          SSH配置文件
sshd_key_t          SSH主機密鑰
user_home_t          用戶主目錄內(nèi)容
admin_home_t         管理員主目錄
tmp_t             臨時文件
var_log_t           日志文件
etc_t             配置文件
bin_t             可執(zhí)行文件
lib_t             庫文件
container_file_t       容器文件（Podman/Docker）
svirt_sandbox_file_t     容器沙箱文件

附錄D：常見錯誤排查

錯誤信息	可能原因	排查方法
Permission denied	文件權限不足	ls -l ,namei -l
Operation not permitted	SELinux拒絕	ausearch -m avc
cannot execute binary file	缺少執(zhí)行權限或架構(gòu)不匹配	file ,chmod +x
Text file busy	文件正在執(zhí)行	lsof ,fuser
Read-only file system	文件系統(tǒng)只讀	mount ,remount

附錄E：術語表

術語	英文	說明
DAC	Discretionary Access Control	自主訪問控制，傳統(tǒng)的owner/group/others模型
MAC	Mandatory Access Control	強制訪問控制，如SELinux、AppArmor
ACL	Access Control List	訪問控制列表，擴展的權限機制
SUID	Set User ID	設置用戶ID，執(zhí)行時臨時獲得所有者權限
SGID	Set Group ID	設置組ID
Sticky Bit	-	粘滯位，防止刪除他人文件
umask	User file creation mask	文件創(chuàng)建掩碼，控制新建文件的默認權限
Context	Security Context	安全上下文，SELinux的核心概念
Boolean	SELinux Boolean	SELinux布爾值，控制策略行為的開關
Capability	Linux Capability	Linux能力，細粒度的root權限分解
Namespace	Linux Namespace	Linux命名空間，容器隔離的基礎

寫在最后

權限管理看似簡單，實則博大精深。從最基礎的rwx到復雜的SELinux策略，每一層都有其存在的意義。作為運維工程師，我們的職責不僅是讓系統(tǒng)"能用"，更要讓它"安全"。

希望這篇文章能幫助你建立起完整的權限知識體系。如果你在實踐中遇到問題，歡迎交流討論。記住，在安全面前，沒有"圖方便"這回事。

祝工作順利，系統(tǒng)安全！