Access control lists: entries, masks and inheritance

Access control lists assign rights to named identities, but masks, entry order and inheritance determine how visible grants become effective access.

An access control list gives an object access rules for particular identities. It can express more than one owner, one owning group and an “everyone else” class.

The phrase “has an ACL” does not identify one universal evaluation algorithm. Linux POSIX-style ACLs and Windows discretionary ACLs have different structures and rules. A network file server may map one arrangement into another.

A visible Linux grant can be capped

An original Linux access ACL is:

user::rw-
user:1100:rw-
group::r--
mask::r--
other::---

The owner has read/write access. Named user 1100 also has a visible read/write entry, but the mask limits the effective permissions of named users and the applicable group entries. It does not cap the owner or other entry in this model.

For a nonowner process with UID 1100, the calculation is:

Named-user entry: rw- = binary 110
Mask:            r-- = binary 100
Effective rights: 110 AND 100 = 100 = r--
Read request: allowed
Write request: denied

The visible rw- entry is therefore not proof of an effective write grant. Changing the mask can affect several entries, not just the named user whose result you are investigating.

If a named-user entry matches, that branch is evaluated. A denial there does not simply fall through to the other class to find a more generous permission.

Mode bits can show the mask

With an extended POSIX ACL, the group-class bits displayed by a traditional mode listing correspond to the ACL mask. They do not necessarily describe only the owning group's entry.

That is why a short ls listing may be insufficient to explain access. Inspect the full ACL, the requested operation and the relevant identity.

ACL element	Role
Owner entry	Owner's rights
Named user entries	Rights associated with particular UIDs
Owning/named group entries	Applicable group rights
Mask	Effective ceiling for the group class and named users
Other entry	Rights when the earlier applicable classes do not match

Directory search and listing rights still matter before a file's ACL can be used. An effective read grant on a film does not bypass a blocked directory component.

A new child can have fewer rights than its parent

Use the preceding access ACL as a starting idea, but consider a directory with this separate default ACL:

default:user::rwx
default:user:1100:rwx
default:group::r-x
default:mask::rwx
default:other::---

An importer creates an ordinary file and requests mode 0640. The new object's access ACL is derived from the default ACL, then constrained by the requested mode. The owner-class ceiling is read/write, the group-class ceiling is read, and the other-class ceiling is none.

The inherited named-user entry may still visibly include broader permissions, but its effective access is constrained by the resulting mask. UID 1100 does not get write merely because the parent's default named-user entry contained write.

If a later creation requests mode 0660 instead, its group-class ceiling includes write, so the resulting mask can permit the named user's write in this example. These are two different creation requests under the same default policy.

New file's requested mode	Group-class ceiling	Named user 1100's effective read/write result
0640	Read	Read, without write
0660	Read and write	Read and write

When a default ACL is present, this inheritance-and-requested-mode process determines the initial ACL; applying a separate simplistic “always subtract umask from the inherited ACL” rule does not describe the Linux contract. Without a default ACL, ordinary creation mode and umask supply the basic permissions.

This explains why two import tools can create different access results in the same directory. Inspect the actual child ACL and the creator's requested mode rather than assuming that the parent dictates one identical outcome for every file.

A Windows DACL is an ordered list

A Windows DACL contains access-control entries for security identifiers. Entries can allow or deny rights. The access check evaluates the entries in order while tracking the requested rights; ordering is part of the meaning.

Consider an original simplified ordered list:

1. DENY  service-SID WRITE
2. ALLOW media-group READ, WRITE
Process belongs to service-SID and media-group

A read-only request can be satisfied by the group allow. A write request is denied by the earlier applicable deny. This example assumes the shown rights and identities; it does not model every Windows right or inheritance flag.

It would be inaccurate to describe every possible DACL as an unordered union of allows followed by one universal denial rule. Windows tools normally maintain canonical ordering, and inherited entries have their own ordering and applicability.

A null DACL and an empty DACL are also different: the former has no discretionary ACL restriction, while the latter grants no discretionary access. That distinction is useful when reading security descriptors; it is not a suggestion to remove a DACL to solve a storage error.

Inheritance describes creation and propagation

A Linux directory's default ACL supplies a starting ACL for newly created child objects, constrained by the requested creation mode. Its access ACL controls access to the directory itself. Editing a default ACL does not retroactively rewrite every existing child's access ACL.

Windows inheritance uses entry flags and propagation behavior. A child can contain explicit and inherited entries, and protected inheritance changes the result. Copying or moving content can also affect how the destination obtains its security state, depending on the operation and tool.

For an Emby library, compare the ACL on an old readable file with one newly imported file that fails. The parent policy, creation identity and actual child ACL can explain the difference. A grant visible on the parent is only part of that lifecycle; inspect the child's effective access under the running server identity.