Why umask subtracts instead of setting permissions directly

A umask never grants permissions — it only removes bits from a fixed starting point, which is exactly why new files default to a maximum of 666 (never executable, since a program creating a plain file has no way of knowing it should be executable) while new directories default to 777 (directories need the execute bit set to be traversable at all). The umask is bitwise ANDed against the complement of the base, stripping out whichever bits it specifies. This subtraction-only design is precisely why "umask my way to adding execute on a new file" has no answer — there's no execute bit in the 666 file base to begin with, so no umask value can produce it; the execute bit on an executable script has to be set afterward with a separate chmod.

Why 022 became the near-universal default

umask 022 strips the group-write and other-write bits while leaving everything else from the 666/777 base intact, which produces 644 for new files (owner can read/write, everyone else read-only) and 755 for new directories (owner has full access, everyone else can read and traverse but not write). That specific balance — the file's owner can freely edit their own new files, but nobody else can modify them by default — is exactly the sane default for a general-purpose multi-user system, which is why 022 has been the standard default umask across most Unix and Linux distributions for decades, distinct from the more restrictive 077 sometimes used on systems where even other local users shouldn't see new files by default.