> ## Documentation Index > Fetch the complete documentation index at: https://siriusbar.net/llms.txt > Use this file to discover all available pages before exploring further. # Phase 3 — Filesystems and NTFS Permissions > FAT32 vs NTFS, the traverse bit, and reading and editing ACLs with icacls. 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: ```powershell theme={null} icacls C:\Users\cardis ``` 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: ```powershell theme={null} icacls C:\path\to\dir /grant cardis:(M) # add Modify for user cardis icacls C:\path\to\dir /remove cardis # drop cardis's entries ``` > 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.