NTFS permissions¶

Exercise ntfs-permissions-annex.pdf · PDF

Right-click any folder on a Windows PC. Properties. There is a tab called Security that you have probably never opened. Open it. A list of names, and two columns of tick boxes: Allow and Deny. That list decides who can open your homework, who can delete it, and who can lock you out of it.

In Special permissions and ACL you gave Pau read-only access to the design folder on Linux. It took setgid, an ACL on the folder, another on each file and a default ACL. Today you do the same job on Windows, in half the time. Why is it easier? Because on Windows there are no three triplets at all: every file and folder has an ACL from the first day.

What you will learn

Open the Security tab and read an ACL: who, which permission, allowed or denied, inherited or not
Name the basic NTFS permissions and choose between Read & execute, Modify and Full control
Explain inheritance and switch it off for one folder
Give and remove permissions from the command line with icacls
Predict what happens when a Deny and an Allow meet
Why you give employees Modify, never Full control

Every file has an ACL¶

On Linux, the card on the door has three fixed lines (owner, group, others), and an ACL is an extra you staple on when they are not enough. On Windows the card is only a list, as long as it needs to be.

NTFS (New Technology File System) is the file system of Windows. It arrived with Windows NT 3.1 in 1993 and has stored an ACL for every file and folder since then.

Each line of an NTFS ACL is an ACE (access control entry): one user or group, a permission, and whether it is allowed or denied.

Look first: File Explorer → right-click C:\Users → Properties → Security. The list at the top is the ACL: one name per ACE. For the selected name, the bottom part shows the Allow and Deny columns.

Only on NTFS

Permissions live in the file system. A USB stick formatted as FAT32 or exFAT (Unit 4) has no permissions at all: anyone who plugs it in reads everything.

The basic permissions¶

From the lowest to the highest:

Permission	`icacls` letter	Lets you
Read	`R`	See the content and the properties
Read & execute	`RX`	The same, and run programs; on a folder, walk through it
Write	`W`	Create files and write in them (not read them)
Modify	`M`	Read, write, run and delete
Full control	`F`	Everything, plus change the permissions and take ownership

Folders also show List folder contents: see the names inside.

Careful: Full control is not the normal permission

The office rule: employees get Modify on their department's folder, never Full control. With Full control they can rewrite the ACL itself, and lock out everybody else, you included.

Inheritance: children copy the parent's card¶

Inheritance means that a new file or subfolder copies the ACEs of the folder it is created in. An inherited entry is marked (I) in icacls.

This is the big difference from Linux. Remember Pau seeing logo.txt in the list but not being able to open it? On Linux each file had its own card, and the folder's ACL did not travel to it. On Windows, children copy their parent's list by default, so that problem does not happen.

flowchart TB
    C["<b>C:\</b><br>Administrators, SYSTEM,<br>Users, Authenticated Users"] -->|"inherited (I)"| T["<b>C:\Tramuntana\design</b><br>the same four entries"]
    T -->|"inherited (I)"| F["<b>logo.txt</b><br>the same four entries"]

The flip side: a new folder is not private. Work in win11, in a terminal opened with Run as administrator (Start → type "Terminal" → right-click):

mkdir C:\Tramuntana\design
echo logo > C:\Tramuntana\design\logo.txt
icacls C:\Tramuntana\design

Every line carries (I): entries for Administrators, SYSTEM, Users and Authenticated Users, all copied from C:\. Can Pau read the folder now? Yes: he is a member of Users. To make a private department folder, you must first switch inheritance off for it.

Make it the design department's folder¶

icacls is the command-line tool that shows and changes NTFS ACLs. Order matters: first grant, then cut the inheritance.

icacls C:\Tramuntana\design /grant "Administrators:(OI)(CI)F" "SYSTEM:(OI)(CI)F" "design:(OI)(CI)M"
icacls C:\Tramuntana\design /inheritance:r
icacls C:\Tramuntana\design

The last command now shows exactly three lines, none with (I): Administrators:(OI)(CI)(F), SYSTEM:(OI)(CI)(F) and design:(OI)(CI)(M) (each with the computer name, BUILTIN\ or NT AUTHORITY\ in front).

Piece	Meaning
`/grant "name:perm"`	Add an Allow entry
`(OI)`	Object inherit: files inside copy this entry
`(CI)`	Container inherit: subfolders copy it
`/inheritance:r`	Remove the inherited entries; the explicit ones stay
`/deny "name:perm"`	Add a Deny entry
`/remove:d name`	Remove that name's Deny entries

If you cut inheritance first, the folder is left with an empty list and File Explorer complains. An administrator can still repair it, because the owner of a file may always change its ACL.

Careful: quotes and elevation

In PowerShell the parentheses must be inside quotes: "design:(OI)(CI)M". Without quotes, PowerShell tries to run (OI) as a command. And if /inheritance:r answers Access is denied, your terminal is not elevated: open it with Run as administrator.

Pau may look¶

Same request as in Special permissions and ACL: Pau reads, Pau changes nothing. One line:

icacls C:\Tramuntana\design /grant "pau:(OI)(CI)RX"

In the Security tab, Pau now appears with Read & execute, List folder contents and Read ticked.

Test it as Pau. runas opens a window that belongs to another user (it asks for Pau's password):

runas /user:pau cmd

Command in Pau's window	Result
`dir C:\Tramuntana\design`	Works
`type C:\Tramuntana\design\logo.txt`	Works: prints `logo`
`echo x > C:\Tramuntana\design\p.txt`	`Access is denied.`
`del C:\Tramuntana\design\logo.txt`	`Access is denied.`

On Linux, Pau could not open logo.txt until the file got its own line. Here he can at once, because the file inherited the folder's new entry. icacls C:\Tramuntana\design\logo.txt shows it with (I).

If runas says the user name or password is incorrect, the account has no password or must change it at first logon. Set one with net user pau *.

Ask Windows what a user can really do¶

A user can be in several groups, each with its own entries. Windows adds them up for you: Properties → Security → Advanced → Effective Access → Select a user → type the name → View effective access. For joan (in design) you see Modify and everything below it ticked, but not Full control. For aina: nothing.

Allow, Deny, and who wins¶

An ACE can say Allow or Deny. Allows from different groups add up; only a Deny takes something away. When they meet, the strongest wins, in this order:

flowchart LR
    A["<b>1. Explicit Deny</b><br>strongest"] --> B["<b>2. Explicit Allow</b>"]
    B --> C["<b>3. Inherited Deny</b>"]
    C --> D["<b>4. Inherited Allow</b><br>weakest"]

An explicit entry is one set on the file itself; an inherited one was copied from the parent. Try it: Joan is in design (Modify, allowed, inherited), but she must not read the budget.

echo 12000 > C:\Tramuntana\design\budget.txt
icacls C:\Tramuntana\design\budget.txt /deny "joan:R"
runas /user:joan "cmd /k type C:\Tramuntana\design\budget.txt"
icacls C:\Tramuntana\design\budget.txt /remove:d joan

With the Deny, Joan cannot open the file: an explicit Deny beats an inherited Allow. After /remove:d, she can read it again.

Careful: Deny does not always win

An explicit Allow beats an inherited Deny. The rule is: explicit before inherited, then Deny before Allow. And use Deny rarely: it is the exception that nobody remembers a year later.

Linux vs Windows¶

	Linux (ext4)	Windows (NTFS)
Basic model	Owner / group / others, three triplets	An ACL on every file and folder
Extra users and groups	Optional ACL: `setfacl`	Just one more line in the ACL
Deny	No: you can only not give	Yes, and it beats Allow
Children copy the parent	Only with setgid and a default ACL	Yes, by default (inheritance)
See it	`ls -l`, `getfacl`	Security tab, `icacls`
Change it	`chmod`, `chown`, `setfacl`	Security tab → Edit, `icacls`

Can administrators always open everything?

Not if the ACL has no entry for them. But they can take ownership of the file, and the owner may always rewrite the ACL. So in the end, nothing on the disk is safe from an administrator.

Key takeaways¶

NTFS (1993, Windows NT 3.1) stores an ACL on every file and folder; each line is an ACE: a name, a permission, Allow or Deny.
The basic permissions go from Read and Read & execute to Write, Modify and Full control. Employees get Modify: Full control lets them rewrite the ACL.
Inheritance copies the parent's entries to new children, marked (I). That is why a new folder is not private.
icacls shows and changes ACLs: /grant, /deny, /inheritance:r, /remove:d; (OI)(CI) make an entry travel to files and subfolders.
Allows add up. Order of strength: explicit Deny, explicit Allow, inherited Deny, inherited Allow.
Test as the user (runas /user:pau cmd) or with Effective Access, never just by reading the list.

Quick check¶

1. Which permission do you give the members of a department on their own folder?

Modify
Read
Write
Full control

Modify lets them read, write, run and delete: everything a worker needs. Full control also lets them change the ACL itself, so they could lock everybody else out.

2. In the output of icacls, an entry shows (I). What does it mean?

It was inherited from the parent folder
It is an invalid entry
It applies only to files
It was created by an administrator

(I) marks an inherited entry: copied from the parent folder. Entries without it are explicit, set on that file or folder itself.

3. Joan's group has Modify (allowed, inherited) on a file. Joan herself has an explicit Deny for Read. Can she open it?

No, the explicit Deny wins
Yes, Modify is higher than Read
Yes, groups are checked first
Only from the command line

An explicit Deny is the strongest entry of all. It beats any Allow, explicit or inherited, whatever group it comes from.

4. What does icacls C:\Tramuntana\dev /inheritance:r do?

Removes the entries inherited from the parent
Deletes every entry of the ACL
Copies the ACL to all subfolders
Resets the folder to the defaults

/inheritance:r cuts the link with the parent and removes the inherited (I) entries. The explicit entries you granted stay, which is why you grant first and cut second.

5. You create C:\Tramuntana\admin and run icacls on it before changing anything. Why can Pau already read it?

It inherited an entry for the group Users from C:\
Every new folder on Windows is open to everybody
Pau is a member of the group Administrators
NTFS has no permissions on new folders

By inheritance, the new folder copied the ACL of C:\, which includes Users, and Pau is a member of Users. To make it private you grant the right entries and then switch inheritance off.

6. Why does PowerShell fail on icacls C:\Tramuntana\design /grant design:(OI)(CI)M?

Without quotes, PowerShell tries to run (OI) as a command
icacls does not exist inside PowerShell
The letter for Modify is W, not M
Groups cannot be given permissions on folders

In PowerShell, parentheses group commands. Writing "design:(OI)(CI)M" in quotes passes the whole text to icacls untouched.

7. Pau has RX on the design folder, with (OI)(CI). A colleague then creates icons.txt inside it. Select the two that are true.

Pau can read icons.txt straight away
Pau cannot delete icons.txt
Pau needs his own entry on icons.txt first
Pau can change the permissions of icons.txt

(OI) makes Pau's entry travel to every new file, so icons.txt inherits Read & execute. That allows reading but not deleting (which needs Modify) or changing the ACL (which needs Full control). On Linux you needed a default ACL for the same effect.

You can now decide who touches every file on both systems. Next: a service that is alive but slow, and no log line says why — Monitoring performance.