Understand an Extended ACL

The teacher wants one assistant to read a report without opening it to every unrelated user. The owner/group/others model may not describe that exception neatly. An access control list, or ACL, adds entries for named users and groups to the file's access information.

There is an important second part: the ACL mask limits effective permissions for named users and the group class. An entry can request read/write while the mask permits only read. We will read both pieces together, then distinguish a file's access ACL from inheritance rules on a directory.

Prepare the example

Use a Linux filesystem with ACL support and the installed getfacl utility. The block prepares an owned disposable report before inspecting it. The practice account must exist if you later refer to it in a named entry; an initial file need not already have an extended ACL.

Bash · Linux terminal

touch marks.txt
getfacl marks.txt

Expected behavior; machine-dependent details

Owner, group and ACL entries depend on the file's settings.

touch marks.txt prepares the report, and getfacl marks.txt prints its ACL information. A basic result can show owner, group and others entries without a named-user exception. The absence of an extended entry is not a tool failure; it tells you what is currently configured.

For the illustration, imagine a named entry requesting rw- while the mask is r--. The overlapping permission is read, so effective write is absent. That mask example is a hypothetical extended ACL, not a claim that the initial inspection created it. A directory default ACL supplies rules for newly created children; changing it does not retroactively rewrite every existing report below that directory.

Traditional permissions provide one owner, one group and one “others” class. Access Control Lists, or ACLs, add more specific user and group entries when those three classes are not flexible enough.

Step 1: Create a New File or Directory

We’ll start by creating a directory named project.

mkdir project
cd project
touch report.txt

Step 2: Check Current Permissions

Let's check who can access the file:

ls -l report.txt

-rw-r--r-- 1 youruser yourgroup 0 Jul 2 11:00 report.txt

By default, only the owner can write. Others can only read.

Step 3: Enable ACL Support (usually pre-enabled)

Most modern Linux filesystems support ACL by default. But to be sure, run:

mount | grep acl

If you don’t see anything, check if the partition is mounted with ACL support. You may need to modify /etc/fstab and remount.

Step 4: Give Another User Permission Using ACL

Now let's say you want to give another user—let’s say alice—write access to report.txt.

setfacl -m u:alice:rw report.txt

-m means “modify ACL”, u:alice:rw means user alice gets read+write.

Step 5: View the ACLs

To see what ACLs are set:

getfacl report.txt

# file: report.txt
# owner: youruser
# group: yourgroup
user::rw-
user:alice:rw-
group::r--
mask::rw-
other::r--

Step 6: Add Group Permissions

You can also grant access to an entire group:

setfacl -m g:designers:r report.txt

This gives read-only access to the designers group.

Step 7: Remove an ACL

To remove a specific ACL entry:

setfacl -x u:alice report.txt

To remove all ACL entries:

setfacl -b report.txt

Wrap-up

And that’s it! Using ACLs, you can assign different levels of access to different users or groups—without changing ownership or default file permissions.

Try it out yourself. Create a test file and give a friend access using ACL!

Happy learning ‍

Let's read one complete permission relationship without assuming it was created by the earlier inspection command. Suppose a report has a named entry user:school-assistant:rw- and a group-class mask mask::r--. The assistant entry requests both read and write, but the mask allows only read. Effective rights come from the overlapping bits, so the answer is r--.

This is a hypothetical ACL configuration to reason about. A real getfacl listing can mark an entry whose effective permissions are narrower than requested. The base owner and others entries are not limited by that mask in the same way. When changing an ACL with setfacl, inspect the result again because its mask may be recalculated; do not assume an earlier displayed limit remains untouched.

Your task: Does a directory default ACL retroactively change existing children?

Use a Linux filesystem with ACL support and the installed getfacl utility. The block prepares an owned disposable report before inspecting it. The practice account must exist if you later refer to it in a named entry; an initial file need not already have an extended ACL.

Bash · complete example for this question

touch marks.txt
getfacl marks.txt

Expected behavior; machine-dependent details

Owner, group and ACL entries depend on the file's settings.

Worked answer

No; it supplies inheritance rules for newly created objects.

A default ACL affects creation of new children, not all earlier files automatically. If the requirement is to update existing reports, plan an explicit update separately. When predicting a named user's current access, read the entry and mask together rather than stopping at the requested bits.

Use ACLs for access relationships that need more detail than one owning group. Distinguish requested rights from effective rights and access ACLs from default inheritance. Inspect the actual object after a change; inherited policy and existing-file policy are not the same event.