Click the Advanced button on any folder’s Security tab and you land in a different world. The everyday permissions — Full Control, Modify, Read & Execute, Write — vanish, replaced by a checkbox list of 14 fine-grained special permissions. Most Windows admins never set foot here. The few who do often do not understand what each entry actually controls.
This is Part 3 of the Windows Permissions Deep Dive pathway. Part 1 covered the design rules. Part 2 covered share-vs-NTFS stacking. Part 3 zooms into NTFS itself: what every special permission means, and why the “Applies to” dropdown is the most-misread control in the dialog.
What the basic permissions actually contain
The friendly names on the Security tab are not separate permissions — they are bundles. Each one is a preset combination of the 14 special permissions:
| Basic name | Bundle |
|---|---|
| Full Control | All 14 special permissions |
| Modify | Read & Execute + Write + Delete |
| Read & Execute | Traverse + List Folder + Read Attributes + Read Extended Attributes + Read Permissions |
| Read | List Folder + Read Attributes + Read Extended Attributes + Read Permissions |
| Write | Create Files + Create Folders + Write Attributes + Write Extended Attributes + Read Permissions |
| List Folder Contents | Same as Read & Execute but only inherits to subfolders, not files (folder-only) |
Setting “Modify” on the Security tab silently flips 9 of the 14 boxes on the Advanced screen. This is fine for 90% of real work. The other 10% — when you genuinely need to grant something halfway between Read and Modify, or block a specific dangerous action — is what Advanced is for.
The context fields at the top of the dialog
Before the checkbox list, the dialog has four fields that determine the scope. Read these every time:
Principal
The user or group the permission applies to. Per the Rule 1 from Part 1: almost always a group, very rarely a user.
Type — Allow or Deny
Most ACEs are Allow. Deny ACEs override Allows of the same right and propagate like Allows do — use sparingly.
Applies to
This dropdown is the trap that catches more admins than the checkboxes themselves. Options include:
- This folder only — the folder itself, nothing under it
- This folder, subfolders and files — the default; everything in the tree
- This folder and subfolders — folder + child folders, no files
- This folder and files — folder + child files, no subfolders
- Subfolders and files only — everything under, but not the folder itself
- Subfolders only / Files only — one or the other
And there is a separate checkbox: “Only apply these permissions to objects and/or containers within this container.” Tick this and inheritance stops at the first child — the permission applies to immediate children but not grandchildren. Most admins miss this and end up with permissions that propagate further than expected.
The 14 special permissions, one by one
1. Full Control
Sets every other box at once: read, write, delete, change permissions, take ownership. The master switch. Granting Full Control is almost never necessary — Modify covers all the day-to-day operations. Reserve Full Control for the resource owners and admin groups.
2. Traverse Folder / Execute File
Two unrelated things sharing a checkbox because both involve “passing through” an object.
- Traverse Folder — lets a user pass through a folder to reach what is inside, even without permission to read the folder’s own contents. Without Traverse, the user cannot even
cdthrough the folder to a subfolder where they do have rights. - Execute File — lets a user run an executable. Without it, they can open a .exe in a hex editor but cannot launch it.
By default, the special group Authenticated Users has the Bypass Traverse Checking right on the system, which short-circuits this permission — most users can traverse folders even without Traverse explicitly granted. This is why removing “Read” from a parent folder rarely blocks users from accessing children: Bypass Traverse Checking lets them slip past the parent.
3. List Folder / Read Data
Again, two things in one box. List Folder on a folder = see the names of files and subfolders inside. Read Data on a file = open and read its contents. Take this away and even “dir” fails on the folder.
4. Read Attributes
View the basic attribute bits: read-only, hidden, system, archive, plus the standard timestamps. Right-clicking a file and choosing Properties surfaces this metadata. Without Read Attributes you cannot see file size in Explorer.
5. Read Extended Attributes
Read the lesser-known extended attributes — OS/2 holdovers from Windows NT days, used by a handful of legacy applications. In practice, this almost never matters; it ships paired with Read Attributes by default.
6. Create Files / Write Data
Two things again. Create Files on a folder = make new files inside. Write Data on a file = overwrite or append to its existing content. Granting Write Data does not grant Append Data — the two are distinct, despite the GUI smashing them together with Create Folders.
7. Create Folders / Append Data
Mirror of #6. Create Folders = make a new subfolder. Append Data on a file = add to the end without overwriting earlier bytes. Append-without-Write is useful for log files: a service can append entries but cannot modify what is already there. Audit logs commonly use this pattern.
8. Write Attributes
Flip the attribute bits: mark something read-only, hidden, archive, etc. Also lets you change timestamps. Lower risk than it sounds — the attribute bits are advisory; they do not bypass the deeper ACL.
9. Write Extended Attributes
The write counterpart to #5. Same scope: legacy OS/2 extended attributes. Set it if your app needs it; otherwise ignore.
10. Delete Subfolders and Files
Permission to delete child items inside this folder, even if the user does not have Delete on those children individually. This is the “trash-can keeper” right: the user can empty the folder but cannot delete the folder itself.
11. Delete
Permission to delete this object — the folder or file itself. Note the asymmetry with #10: Delete Subfolders and Files on a parent lets you remove children; Delete on a child lets you remove the child. To delete a file you typically need both: Delete on the file (or Delete Subfolders and Files on its parent).
12. Read Permissions
See the ACL itself: who has what access, who owns the object, what auditing rules apply. Strip Read Permissions and the Security tab refuses to open for that user. Almost always granted to anyone who has any access.
13. Change Permissions
Modify the ACL: add, remove, or change ACEs. This is dangerous — a user with Change Permissions on an object can grant themselves additional rights and effectively elevate to Full Control. Restrict tightly. Granted only to resource owners, delegated admins, and high-trust accounts.
14. Take Ownership
Become the object’s owner. The owner of an object always has implicit Read Permissions and Change Permissions on it, regardless of what the ACL says. Take Ownership therefore = an escape hatch to Full Control on anything you can claim. Members of the Administrators group have this on everything by default; nobody else should.
The “Only apply to objects within this container” checkbox
This one tiny checkbox quietly trips a lot of admins. It limits inheritance depth to the immediate children of the folder, regardless of what the “Applies to” dropdown says.
The asymmetry it creates
Tick the box and set Applies-to = “This folder, subfolders and files” — the permission applies to the folder itself and its direct children, but a sub-subfolder three levels down inherits nothing from this ACE. Useful when you want a permission that holds at the top of a tree but does not cascade indefinitely.
What the source-of-confusion looks like
An admin grants Guest Full Control with Applies-to = “This folder, subfolders and files” AND the “only apply within this container” box ticked. Guest cannot delete the folder itself (the ACE does not apply to the folder, because of the checkbox), but Guest CAN delete every immediate child file and subfolder. Result: an unexpectedly destructive permission that feels weaker than “Full Control” suggests.
Practical groupings: read, write, delete, attributes
Mentally cluster the 14 permissions into four buckets — it makes the dialog tractable:
- Read group — List Folder/Read Data, Read Attributes, Read Extended Attributes, Read Permissions. Use when you want pure read access; this is the “Read” basic permission.
- Write group — Create Files/Write Data, Create Folders/Append Data, Write Attributes, Write Extended Attributes. The “Write” basic permission.
- Delete + ownership — Delete, Delete Subfolders and Files, Change Permissions, Take Ownership. The dangerous bucket. Audit anyone who has these.
- Execute / traverse — Traverse Folder/Execute File. Almost universally granted via Bypass Traverse Checking anyway.
When you find yourself reaching for Advanced, ask: which bucket am I trying to grant partially? Usually you want write-but-not-delete, or read-and-execute-but-not-read-permissions. Those are the rare cases where Advanced earns its keep.
DSACLS — the command-line alternative
For NTFS file system permissions, the command-line equivalent is icacls; for Active Directory object permissions, it is dsacls. Both produce a single readable text block that captures every special permission and the “Applies to” scope, in a form that can be diffed, scripted, and stored in source control.
If you find yourself in the Advanced dialog more than a handful of times per quarter, you have outgrown the GUI. Capture your work as icacls commands:
icacls "D:\Shares\Finance" /grant "DOMAIN\FinanceEditors:(OI)(CI)(RX,WD,AD,WA)"
That single line grants the FinanceEditors group: Read & Execute, Write Data, Append Data, Write Attributes — inheriting to objects (OI) and containers (CI). Reproducible, scriptable, auditable. Far better than 15 clicks in a dialog.
Things that bite people
The Guest account with elevated special permissions
The Guest account exists for the lowest possible trust. Granting Guest anything beyond Read on a single folder is almost always a configuration mistake, often the result of someone clicking through a wizard that suggested permissive defaults. Audit Guest access on every share; it should be empty in nearly every environment.
Take Ownership granted “just in case”
Take Ownership effectively grants Full Control to anyone who has it, because the owner can always change the ACL. Granting Take Ownership to a non-admin group is a hidden privilege escalation. Never grant Take Ownership outside of true admin roles.
Append Data without Write Data
An interesting pattern for audit logs: grant Append Data but not Write Data. The service can add entries; it cannot modify existing entries. Useful when an attacker who compromises the service still cannot tamper with the audit trail.
Delete on a file but not its parent
If a user has Delete on a file but no rights on the parent folder, the delete operation often fails — deleting a file modifies the parent folder. The user needs either Delete on the file and Write on the parent, or Delete Subfolders and Files on the parent.
Bypass Traverse Checking masks the absence of Traverse
Removing Traverse Folder from a permission rarely blocks anything, because Bypass Traverse Checking on the system overrides it for most users. To actually block traversal you have to revoke Bypass Traverse Checking too — which most admins never touch.
The Effective Access tab does not show special permissions clearly
The Effective Access tab gives the boolean answer for each special permission but does not explain which ACE caused which result. For deep troubleshooting, dump the full ACL with icacls or PowerShell Get-Acl and read each ACE.
Summary
The basic Security tab covers 90% of needs. Advanced exists for the remaining 10% where you genuinely need property-level control. Read the four context fields (Principal, Type, Applies to, and the “only within container” checkbox) every time. Cluster the 14 permissions into four mental buckets: read, write, delete-and-ownership, traverse. Tightly restrict the delete-and-ownership bucket. Use icacls for anything you need to repeat.
What’s next
NTFS controls access to resources. The other half of Windows access control is access to the operating system — who can log on, who can install software, who can shut down the box. That is handled by built-in local groups. Part 4 walks every local group in Computer Management: Understanding Local Groups in Windows.