Skip to main content
Phase 2 gave us the map. Now we go one layer down: what filesystem is under those directories, and how Windows decides who may touch a file. Coming from ext4 and Unix permissions, some of this maps cleanly and some of it does not.

​
The filesystems, mapped

Windows knows five filesystem families: FAT12, FAT16, FAT32, NTFS, and exFAT. The first two are effectively museum pieces on modern Windows (floppies and tiny disks), so in practice we care about three.
  • FAT32: the universal, lowest-common-denominator filesystem.
  • exFAT: FAT for the modern era, built to carry files larger than FAT32 can.
  • NTFS: the real Windows filesystem, and the default for many years now.
The mapping is straightforward: FAT32/exFAT are the vfat/exfat I already mount on USB sticks, and NTFS is the equivalent of ext4/xfs — the one with real metadata.

​
FAT32: no owner, no journal, no secrets

FAT32 (File Allocation Table) is built for reach, not for safety. It uses 32-bit entries in its allocation table to address the clusters that hold file data, and it shows up on USB sticks, SD cards, and external drives because almost everything speaks it. Pros:
  • Compatibility, exactly as said above — it is the format I reach for when a drive must move between machines.
  • It is readable and writable across Windows, macOS, and Linux.
Cons, and this is where it feels just like a vfat mount:
  • A single file must be ≤ 4 GB.
  • No data protection — there is no permission model attached to the files.
  • No native encryption.
A FAT32 stick on Linux behaves the same way: ownership and mode bits are faked by the mount, not stored on disk. So when I see FAT32, I assume the filesystem itself enforces nothing about who can read a file.

​
NTFS: the filesystem that actually has opinions

NTFS (NT File System) is what Windows runs on, and it is the one that behaves like a grown-up Linux filesystem.
  • Granular security permissions, per user and per group, attached to each file.
  • Very large partition support.
  • Journaling — it records modifications, which is what gives it built-in recovery after a crash. This is the same idea as the ext4 journal.
The trade-off is reach: many cameras and older media devices do not understand NTFS, which is exactly why removable media still leans on FAT32 and exFAT.

​
Permissions: a list of entries, not nine mode bits

Here the familiar model only partly transfers. A Unix file’s core permissions are nine rwx bits across owner, group, and other, and I reach for POSIX ACLs when nine bits are not enough. NTFS starts from the ACL: every file carries a list of entries, each saying what a specific user or group may do. The basic NTFS permissions are:
  • Full Control: everything, including changing permissions and taking ownership.
  • Modify: read, write, and delete the item.
  • Read & Execute: read and run.
  • List Folder Contents: the folder-only form of read-and-execute.
  • Read: read content and attributes.
  • Write: create and add content.
Two distinctions from the notes are worth keeping:
  • Modify versus Read & Execute is really about whether you can change the files and folders, not just see and run them.
  • List Folder Contents versus Read & Execute is the same right pointed at folders versus files.

​
The traverse bit is the Unix x on a directory

This is the cleanest mapping in the whole series, and it took me a second to see it. On Linux, a directory’s r bit lets me ls it, and its x bit lets me traverse it — enter it to reach a known path inside, even if I cannot list it. chmod 711 dir gives the classic result: I cannot ls dir, but I can still cat dir/known_file. NTFS has exactly this, called Traverse Folder / Execute File. The note captures it perfectly:
  • the folder ...\home\cardis cannot be listed or written, but
  • the file ...\home\cardis\a.zip can still be read, if I already know the path.
So the instinct holds: read on a directory means “list it”, traverse/execute on a directory means “pass through it to something I already know is there”. This is the trick behind directories you can use but not enumerate.

​
icacls: getfacl and setfacl, not chmod

To read and edit these permissions from the command line, Windows gives us icacls (Integrity Control Access Control List). It reports and edits NTFS permissions at the granularity of a single file, which makes it the counterpart of getfacl/setfacl, not the coarser chmod. Reading permissions is just the directory on its own:
The output lists each user and group with their access level, plus inheritance flags in parentheses:
  • (CI) Container Inherit — applies to subfolders.
  • (OI) Object Inherit — applies to files.
  • (IO) Inherit Only — the entry does not apply to this item, only to its children.
  • (NP) Do Not Propagate — inherit to the immediate children, then stop.
  • (I) Inherited — this entry was inherited from the parent container, not set here.
Those flags are NTFS’s version of POSIX default ACLs. On Linux I set a default: ACL on a directory so new children inherit it; here (CI)/(OI) decide how an entry rains down onto folders and files. The access levels show up as short codes:
  • (F) Full access
  • (M) Modify access
  • (RX) Read & execute access
  • (R) Read-only access
  • (W) Write-only access
  • (D) Delete access
  • (N) No access
Editing is the setfacl move:
For a security researcher this is the first audit command on any path that matters. icacls on a service’s binary or its folder tells me who can write it, and a writable binary that runs as SYSTEM is a privilege-escalation finding. The ACL is where that mistake hides.
With permissions understood, the last phase finally crosses into the kernel, where the “everything is an object” idea from Phase 1 becomes concrete.