umask: How the Default Mode of a New File Is Decided

A process asks the kernel for a mode when it creates a file, and the kernel removes whatever bits the umask names before writing it to disk. The mask is subtractive only: a umask can never grant a permission that the creating program did not ask for, which is why a umask of 000 still does not produce executable files.

That last point catches people. Programs that create ordinary files request 666, not 777, so the execute bits are never in play and a new file arrives without them regardless of the mask. Directories are created with a request of 777, which is why the same umask of 022 yields 755 for a directory and 644 for a file.

The value is inherited by every child process, which is what makes it a useful default and a poor security control. Setting it in a shell profile affects that shell and everything launched from it, but a service started by the init system uses whatever the service manager sets, so tightening your own shell does nothing for a daemon writing files at three in the morning.

022 is the usual system default and gives group and world read access to everything you create. 077 is the right choice on a shared machine where nothing you write should be visible to other accounts. 002 goes with the private group scheme, where every user has a personal primary group so the group write bit is harmless until a file is deliberately given a shared group.

It applies only at creation. Copying a file with cp creates a new file, so the umask applies and the original mode is lost unless you pass -p. Restoring from an archive that stores permissions replays the stored modes instead. This is the mechanism behind most cases of a secret file arriving in production at 644.