Section 4: Effective Permissions

The Big Picture: The Final Answer

A user is rarely on a file's list by name alone. You may be in the group Users, the group Marketing, and also have your own entry. Each of these entries may say something different. So what can you actually do?

The final answer is called your effective permission: the real rights you end up with after Windows has added up everything that applies to you.

Why is this possible? Because of what Chapter 24 taught about tokens. When you sign in, Windows builds your access token. It lists your own SID and the SID of every group you belong to. When you open a file, Windows compares the SIDs in your token with the entries in the file's ACL.

  Your access token                      File's ACL
  ┌────────────────────────┐             ┌────────────────────────────┐
  │ User:   Harshil        │             │ Harshil    → Read          │
  │ Groups: Users          │  compare    │ Marketing  → Modify        │
  │         Marketing      │ ─────────►  │ Users      → Read          │
  │         Everyone       │             │ Interns    → Deny: Write   │
  └────────────────────────┘             └────────────────────────────┘
                                         Which entries match my SIDs?

4.1 How Windows Computes Effective Permission from Multiple Group Memberships

What it is: Windows looks at every entry that matches any SID in your token, and adds up all the Allows. That is a union (a combined set): if one entry gives you Read and another gives you Write, you get both.

The steps:

1. Collect your SIDs: your user, every group, and special groups like Everyone.
2. Find every ACL entry that names one of those SIDs.
3. Add together everything the matching Allow entries give you.
4. Remove anything a matching Deny entry takes away (Section 4.2).
5. What is left is your effective permission.

Example. Priya is in the groups Users and Marketing. The folder D:\Campaigns has this list:

Priya's effective permission is Read & execute + Write, which is about the same as Modify minus the delete right. The rights from both groups are added.

The ACL walk. Windows reads the ACL from the top, one entry at a time. It keeps a list of what it still needs. It stops early when everything asked for has been granted, or when one Deny matches:

  Priya asks: "Open Plan.docx for writing"

  Entry 1: Interns   → Deny: Write     does it match my token?  no  → skip
  Entry 2: Priya     → (none)
  Entry 3: Marketing → Allow: Write    matches!  Write granted ✔
  Entry 4: Users     → Allow: Read     (not needed any more)

  Needed rights all granted → ACCESS ALLOWED

If the walk reaches the end of the list and some needed right was never granted, the answer is denied. This is why "no entry at all" means "no access": the default is no.

Effective permission on a share + NTFS combo. For network users, work out the share result and the NTFS result separately, using this union rule for each. Then take the more restrictive (Section 2.2).

Example: Ravi connects over the network to \\FILESRV\Docs.

If Ravi sat at FILESRV itself, only step 2 would count.

How to see the answer without guessing: Windows can compute it for you.

1. Right-click the item → Properties → Security → Advanced.
2. Open the Effective Access tab.
3. Click Select a user and type a user or group name. Then click View effective access.
4. Windows lists every permission with a tick or a cross.

Tick marks show what the ACL allows for that person. (It is a calculation. It does not know about things like the share permission, or a UAC filtered token. Treat it as a very good guide, not a promise.) Next to each cross, an extra column often tells you which entry limited the right.

4.2 Deny Always Overrides Allow

What it is: If any matching entry denies a right, you do not get that right, even when other entries allow it. A Deny is like a "stop" sign that beats any number of "go" signs.

Why it exists: Sometimes you need to exclude one person or one group, while leaving the rest of the group in. For example: everyone in Staff may read the folder, except the temporary Contractors.

Example:

A user who is in both Staff and Contractors gets Modify, but not Write. They can read, but they cannot change or create anything. (Remember: Modify includes Write; the Deny removes it.)

Important detail about order. In Section 3 you saw the reading order: explicit Deny, explicit Allow, inherited Deny, inherited Allow. That gives one subtle result:

So "Deny always wins" is the right rule of thumb at the same level. An entry set directly on the item is read before an inherited one. This is a good reason to avoid Deny when you can: it makes the result harder to predict.

Common mistakes with Deny:

1. Denying "Everyone". Everyone includes you. A Deny for Everyone locks out even the Administrators group, and the owner's only way out is to change the list as the owner (Section 5).
2. Using Deny when "not allowed" is enough. If a group is simply not on the list, it already has no access.
3. Forgetting a group. A user who is in a denied group stays denied, whatever else they belong to.

Best practice:

Windows tip: In icacls, a Deny entry looks like Contractors:(DENY)(W). The word (DENY) is easy to spot, which makes a quick icacls <path> a good first check when something is blocked.

Summary