Symbolic umask, and why 000 is dangerous
◈ 8 cardsReading umask -S output and symbolic mask strings without inverting them by accident, and arguing why umask 000 is unsafe.
The same mask, printed two opposite ways
This is the single most confusing thing about umask, and the assignment exploits it deliberately:
$ umask
0022
$ umask -S
u=rwx,g=rx,o=rx
Both lines describe the identical mask. The numeric form, 0022, says what is taken away: group-write and other-write. The -S form says what is left: the owner keeps everything, the group and others keep read and search. They are complements of each other, and the shell will happily accept either form as an argument.
So when you read umask 022, think withhold. When you read umask u=rwx,g=rx,o=rx, think allow. Both set the same thing.
Symbolic mask strings
A symbolic argument uses the same <who><operator><privilege> grammar as chmod, but every clause is talking about the permissions that will be left available:
umask u=rw,go=— the owner is left read and write; the group and others are left nothing. Numerically that is 177, and a new text file comes out600.umask a=rwx— everyone is left everything. Numerically 000.umask a=— nobody is left anything. Numerically 777, and every new file and directory arrives at mode000.
+ and - work too, and they are relative to the mask already in force. Starting from the usual umask 022 (which leaves 755), umask u-x,g=r,o+w takes execute away from what the owner is left, sets the group to read only, and adds write to what others are left: left becomes 647, so the numeric mask becomes 777 AND NOT 647 = 130. A new text file is then 666 AND NOT 130 = 646 (rw-r--rw-) and a new directory 777 AND NOT 130 = 647 (rw-r--rwx). Note in passing how bad that is — every user on the system may rewrite your new files.
Why umask 000 is a real problem, not a theoretical one
umask 000 withholds nothing, so every object arrives at its base: 666 for every plain file, 777 for every directory and executable. Four consequences, and the exam wants them argued rather than asserted:
- Every local user can modify your files from the instant they exist. You do not have to share anything, misconfigure anything, or run any command; the exposure is the default.
- A world-writable directory is worse than a world-writable file. Anyone with
wandxon a directory can delete or rename anything inside it — including files whose own modes are restrictive — because deletion is governed by the directory. Without the sticky bit there is nothing to stop it. - It defeats any
chmodyou run afterwards. Even a carefulchmod 600a second later leaves a window between creation and repair in which the file was writable by everyone, and an attacker who is watching does not need a large window. - Combined with the set-user-ID bit it becomes privilege escalation. A world-writable SUID program can be overwritten by anyone, and the replacement then runs with the owner’s privileges.
The safe choices are 022 (the usual system default), 027 (the group can read, others get nothing) and 077 (full protection, open up per file with chmod). None of them costs you anything you cannot grant back deliberately.