Windows Permissions Binary

NTFS Access Mask Architecture

Windows NTFS permissions are fundamentally different from Linux chmod permissions in one critical way: the permission mask is much larger. While Linux uses a 9-bit mask (12-bit with special bits), Windows uses a 32-bit access mask. I have worked with both systems extensively, and the Windows approach is more granular but also more complex.

The NTFS access mask is a 32-bit integer where different ranges of bits control different categories of permissions:

After migrating a file share from an old Windows Server 2008 box, I saw firsthand how NTFS ACE entries accumulate over time. Knowing the bit layout of access masks helped me consolidate over 200 rules into 12 clean entries.

Each permission level in Windows — Full Control, Modify, Read & Execute, Read, Write — is a predefined combination of these individual bit positions. When you look at a permission through the Windows security dialog, you are seeing a human-readable label for a specific bitmask value.

Let me be clear about the structure: the high 8 bits (24-31) are used for generic access rights that map to lower bits, the standard access rights occupy bits 16-23, and the object-specific rights occupy bits 0-15 for files and directories. The complete mask for Full Control is 2032127 decimal, or 0x1F01FF in hex.

Standard Permission Bit Positions

The lower 16 bits of the NTFS access mask define the file-specific and standard permissions. Here are the individual bit positions I have found most important in my daily administration work.

Notice the pattern: the standard permissions use bit positions that are powers of 2, exactly like Linux bits. Bit 0 = 1, bit 1 = 2, bit 2 = 4, bit 3 = 8, and so on. This is the same binary encoding principle — each bit position corresponds to a specific permission flag.

Special Permission Bits

Beyond the standard permissions, Windows defines several special permission bits that interact with the access checking system in unique ways. These are the bits that separate Modify from Full Control.

One thing I learned debugging security descriptors on Windows Server: the Synchronize bit (0x100000, bit 20) is critical for proper synchronization behavior. Without it, applications that use WaitForSingleObject on file handles may fail. Full Control includes Synchronize, but Modify does not — this is a real difference that can cause subtle bugs in multithreaded applications.

Full Control Binary: 2032127 (0x1F01FF)

Full Control is the most permissive NTFS permission. In my experience, it is as overused as Linux chmod 777, and for the same reasons — administrators use it as a shortcut when they cannot figure out the exact permission set needed.

The key bits that make Full Control special compared to Modify:

• WRITE_DAC (bit 18, value 262144) — Ability to change the file's permissions. This is the bit that lets an administrator grant themselves any permission in the future.
• WRITE_OWNER (bit 19, value 524288) — Ability to take ownership of the file. This effectively gives an administrator permanent control.
• Synchronize (bit 20, value 1048576) — Ability to synchronize on the handle.
• GENERIC_ALL (bit 27, value 134217728) — The generic mapping for all access. When this is set, the system expands it to all lower bits.

In practice, I reserve Full Control for administrators and service accounts that need to manage permissions. Regular users and application pools should never get Full Control — they should get Modify at most. The binary difference is clear: Full Control sets bit 18 (WRITE_DAC) and bit 19 (WRITE_OWNER), while Modify does not.

Modify Permission Binary: 0x01BF

The Modify permission is the Windows equivalent of Linux chmod 755 — it is the standard all-purpose permission for users who need to read, write, modify, and delete files, but do not need to change permissions or take ownership.

Modify does not include the DELETE standard right (bit 16, 0x10000). While you can modify the file contents, delete subdirectories, and delete files within directories (that is the DeleteChild bit for directories), you cannot delete the file object itself if the parent directory denies deletion. This is a subtle but important distinction I have seen catch many Windows administrators off guard.

A practical tip from my work: when setting up IIS application pools, always use Modify, not Full Control. The worker process does not need to change ACLs or take ownership. If a security breach occurs, limiting the process token to Modify prevents the attacker from escalating through DACL manipulation. The binary bit difference — missing bits 18 and 19 — is your security boundary.