I need some clarification/confirmation/elaboration on the different roles DAC, ACL and MAC play in Linux file security.

After some research from the documentation, this is my understanding of the stack:

  1. SELinux must allow you access to the file object.
  2. If the file's ACLs (e.g., setfacl, getfacl for an ACL mount) explicitly allows/denies access to the object, then no further processing is required.
  3. Otherwise, it is up to the file's permissions (rwxrwxrwx DAC model).

Am I missing something? Are there situations where this is not the case?

  • 2
    I think that you are correct. Could you post the problem that you are having?
    – Kevin M
    Commented Jul 17, 2011 at 14:43
  • I apologize for the malformed question. I feel like, when it comes to this, I go into a "trial and error" mode. I am trying to confidently grasp it and was hoping someone could share a clearer picture of the roles played by each portion of the stack. Commented Jul 17, 2011 at 19:14
  • Edited the question to clarify what I'm looking for in answers. Commented Jul 17, 2011 at 19:17

3 Answers 3


When a process performs an operation to a file, the Linux kernel performs the check in the following order:

  1. Discretionary Access Control (DAC) or user dictated access control. This includes both classic UNIX style permission checks and POSIX Access Control Lists (ACL). Classical UNIX checks compare the current process UID and GID versus the UID and GID of the file being accessed with regards to which modes have been set (Read/Write/eXecute). Access Control List extends classic UNIX checks to allow more options regarding permission control.

  2. Mandatory Access Control (MAC) or policy based access control. This is implemented using Linux Security Modules (LSM) which are not real modules anymore (they used to be but it was dropped). They enable additionnal checks based on other models than the classical UNIX style security checks. All of those models are based on a policy describing what kind of opeartions are allowed for which process in which context.

Here is an example for inodes access (which includes file access) to back my answer with links to an online Linux Cross Reference. The "function_name (filename:line)" given are for the 3.14 version of the Linux kernel.

The function inode_permission (fs/namei.c:449) first checks for read permission on the filesystem itself (sb_permission in fs/namei.c:425), then calls __inode_permission (fs/namei.c:394) to check for read/write/execute permissions and POSIX ACL on an inode in do_inode_permission (fs/namei.c:368) (DAC) and then LSM-related permissions (MAC) in security_inode_permission (security/security.c:550).

There was only one exception to this order (DAC then MAC): it was for the mmap checks. But this has been fixed in the 3.15 version of the Linux kernel (relevant commit).

  • Excellently detailed answer with canonical sources. Thanks! Commented May 11, 2014 at 23:36

DAC = Discretionary Access Control
MAC = Mandatory Access Control
ACL = Access Control List

The ACL specifies the controls to be applied by the method of control, DAC or MAC. MAC is explicit, centrally controlled, and does not allow users to grant authority to an object unless they have explicit permissions to do so, whereas DAC allows users to grant other users access to objects they can access.

MAC ACLs will always be applied to a request first, and if access is denied processing stops. If access is permitted then the DAC ACLs are applied, and again if access is denied processing stops. Only if access is granted by both MAC and DAC ACLs can the user access the object they requested.

SELinux is a MAC implementation for Linux (there are others), while the traditional rwx file permissions, combined with the owning user and group form the complete DAC ACL. The SELinux 'policy' is essentially the MAC ACL.

setfacl extends the basic filesystem ACLs to allow more than a single user or group to be assigned an to ACL for files and directories. This is also a DAC implementation, and is therefore applied after the SELinux MAC ACLs.

  • 1
    Where do file ACL's (e.g., setfacl) come in? Commented Jul 18, 2011 at 0:30
  • 1
    setacl extends the basic filesystem ACLs to allow more than a single user or group to be assigned an to ACL for files and directories. This is also a DAC implementation, and is therefore applied after the SELinux MAC ACLs.
    – Mike Insch
    Commented Jul 18, 2011 at 8:33
  • Thanks Mike. One more question: As far as I can tell via my testing, the explicitly set setfacl ACLs override the traditional permissions. Is this true in every case? Commented Jul 18, 2011 at 13:30
  • As far as I know, yes, the setacl / setfacl ACLs will override the traditional 'simple' ACL on the file.
    – Mike Insch
    Commented Jul 18, 2011 at 14:54
  • 2
    Mike, your note about setfacl belongs to the answer. Commented May 12, 2014 at 9:16

Sorry to quibble, but I think some of the answers here might be incorrect. Directly from Fedora's http://docs.fedoraproject.org/en-US/Fedora/13/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Working_with_SELinux-SELinux_Contexts_Labeling_Files.html:

SELinux policy rules are checked after DAC rules. SELinux policy rules are not used if DAC rules deny access first.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .