Read an ACL and Its Effective Rights

A report's short listing does not explain the assistant's access, so let's read its full ACL information. getfacl displays the base owner/group/others entries and any extended named entries or mask. It is an inspection tool, not a command that grants the permissions it prints.

The crucial reading habit is to distinguish a requested entry from effective access. An assistant's rw- entry can still lack effective write if the mask excludes it. We will read the surrounding fields instead of focusing on the most generous-looking line.

Prepare the example

Use the practice Linux filesystem and installed ACL tools. The first line prepares a disposable file. If you have not yet added an extended ACL, the inspection can legitimately show only base entries; use the named-entry lesson when you want to construct the richer example.

Bash · Linux terminal

touch marks.txt
getfacl marks.txt

Expected behavior; machine-dependent details

The listing reflects actual ownership, entries and any effective-rights comments.

After touch, getfacl marks.txt reports the actual current configuration. Read the owner and group comments, then the entries. A base user:: entry refers to the owner, while a form such as user:assistant:rw- refers to a named user. The empty name field in a base entry is meaningful, not a missing account name.

Where a mask is present, compare it with named-user and group-class requests. For example, rw- limited by r-- has effective read only. The owner and others base entries are not constrained by that mask in the same way. Read a directory's default entries separately from its current access entries, because their purpose is inheritance.

getfacl displays the Access Control List attached to a file or directory. It is the right tool when ls -l does not explain why a named user has extra access.

Step 1: Open your Terminal

You can open the terminal on your Linux system using Ctrl + Alt + T or from your application menu.

Step 2: Check if ACL is supported

Most modern Linux filesystems like ext4 support ACLs, but they may need to be enabled. To check if it's supported on a mounted partition, you can use:

mount | grep acl

If your partition is mounted with acl, you're good to go.

Step 3: Use getfacl to view ACLs

The basic syntax is:

getfacl <filename or directory>

Let’s try an example:

getfacl myfile.txt

If ACLs are set, you might see output like this:

# file: myfile.txt
# owner: alice
# group: alice
user::rw-
user:bob:r--
group::r--
mask::r--
other::r--

Let’s break that down:

• user::rw- – The file owner's permissions
• user:bob:r-- – Bob has read-only access
• group::r-- – The group’s permissions
• mask::r-- – The maximum effective permissions for users and groups (except the owner)
• other::r-- – Everyone else’s permissions

Step 4: View ACLs on a directory

You can also use getfacl on directories:

getfacl /home/alice/docs

This will list default and specific ACLs set on the directory. For example:

# file: home/alice/docs
# owner: alice
# group: alice
user::rwx
user:bob:r-x
group::r-x
mask::r-x
other::r-x

Extra Tip: List recursively

To view ACLs recursively (including all subfolders and files), use:

getfacl -R /path/to/directory

Read ACL entries with getfacl

The getfacl command is your friend when you're dealing with advanced permissions in Linux. Whether you're auditing access or troubleshooting user access issues, it's a powerful tool to inspect what permissions are in place.

Coming up next, we’ll learn how to set ACLs using setfacl.

Your task: Does user:assistant:rw- always guarantee effective write regardless of mask?

Use the practice Linux filesystem and installed ACL tools. The first line prepares a disposable file. If you have not yet added an extended ACL, the inspection can legitimately show only base entries; use the named-entry lesson when you want to construct the richer example.

Bash · complete example for this question

touch marks.txt
getfacl marks.txt

Expected behavior; machine-dependent details

The listing reflects actual ownership, entries and any effective-rights comments.

Worked answer

No; the mask can restrict it.

A named rw- request does not bypass the mask. Check the permitted overlap before claiming the user can write. Named entries are meaningful, but they are not an escape from the ACL's group-class limit.

Read an ACL as a collection of identified entries and applicable limits. Separate base entries, named entries, mask and defaults. Use the listing to explain an observed access result, and do not confuse an inspection with a change to the policy.