DAC（文件權限）、ACL 和 MAC (SELinux) 在 Linux 文件安全中扮演什麼角色？

我需要對 DAC、ACL 和 MAC 在 Linux 文件安全中扮演的不同角色進行一些澄清/確認/闡述。

經過對文件的一些研究，這是我對堆棧的理解：

1. SELinux 必須允許您訪問文件對象。
2. 如果文件的 ACL（例如，setfacl對於getfaclACL 掛載）明確允許/拒絕訪問該對象，則不需要進一步處理。
3. 否則，取決於文件​​的權限（rwxrwxrwx DAC 模型）。

我錯過了什麼嗎？有沒有不是這種情況的情況？

當程序對文件執行操作時，Linux 核心按以下順序執行檢查：

1. 自主訪問控制 (DAC)或使用者指定的訪問控制。這包括經典的 UNIX 樣式權限檢查和POSIX 訪問控制列表 (ACL)。經典的 UNIX 檢查比較目前程序的 UID 和 GID 與正在訪問的文件的 UID 和 GID 的設置模式（讀/寫/執行）。訪問控制列表擴展了經典的 UNIX 檢查以允許有關權限控制的更多選項。
2. 強制訪問控制 (MAC)或基於策略的訪問控制。這是使用Linux 安全模組 (LSM)實現的，這些模組不再是真正的模組（它們曾經是，但它已被刪除）。它們支持基於其他模型的附加檢查，而不是經典的 UNIX 樣式安全檢查。所有這些模型都基於一種策略，該策略描述了在哪種情況下允許哪種操作用於哪種過程。

這是 inode 訪問（包括文件訪問）的範例，通過線上Linux Cross Reference的連結來支持我的答案。給出的“ function_name(filename:line)”是針對 3.14 版本的 Linux 核心的。

該函式inode_permission（fs/namei.c:449）首先檢查文件系統本身（sb_permission在fs/namei.c:425中）的讀取權限，然後呼叫__inode_permission（fs/namei.c:394）檢查讀取/寫入/執行do_inode_permission( fs/namei.c:368 ) (DAC)中的 inode 上的權限和 POSIX ACL ，然後是security_inode_permission( security/security.c:550 )中的 LSM 相關權限 (MAC )。

這個命令只有一個例外（DAC 然後是 MAC）：它用於 mmap 檢查。但這已在 3.15 版本的 Linux 核心中得到修復（相關送出）。

引用自：https://unix.stackexchange.com/questions/16828