Historically why is umask the way it is?

Question

umask has always tripped me up. Logically I would prefer to have a 'setmask' instead that takes chmod-style arguments. Anyone know why it is the way it is?

score 6 · Answer 1 · answered Sep 17 '15 at 19:29

I believe this stems from 2 idea's, though I could be wrong.

Initially in unix development permissions were wide open. Before the age of security, the idea of making a file only readable/writable/executable by certain individuals wasn't necessary. As such the natural progression from that stand point would be to take the idea of permissions, and restrict them. Rather than to take a 0 value of permissions and add to them.
The other reason would be the idea that a specific deny yields more accurate results in most cases then a specified allow. Different situations call for different needs. For example default directory permissions are: 755 where as default file permissions are 644

If you specifically allowed execute for example, that would then have to translate to both directories and files. You would then be faced with the choice of either directories don't come with execute enabled, or files do. However directories need execute enabled in order to function. as such, instead you make the choice to strip away extra permissions, rather than specifically add permissions.

With a umask of 0000, you still end up without execute permissions on a normal file, if you did things the reverse, it would be harder to engineer it that way.

Related, you can find Dennis Ritchie and Bell Lab's patent for improving file permissions in [USP 4135240, Protection of data file contents](https://www.google.com/patents/US4135240). Its dated from 1973. Here's part of the Abstract: *"An improved arrangement for controlling access to data files by computer users. Access permission bits are used in the prior art to separately indicate permissions for the file owner and nonowners to read, write and execute the file contents..."* — , Nov 01 '17 at 10:21

score 3 · Answer 2 · answered Sep 17 '15 at 19:41

umask doesn’t specify permissions on files made by creat(2) and open(2). It only specified which bits should be forcibly turned off, in order to deter security-neglecting programs from making holes.

A usual IT convention refers to “default” and “don’t change” options with the number 0. Here, umask = 0 states that modes after creat(2) shouldn’t be changed at all, and programs will produce files with exactly the same permissions as specified by creat(name, mode). When umask  has a bit set, it clears respective permission bit for files created (i.e. effects some change against the program’s logic). That’s why this negative logic.

score 1 · Answer 3 · answered Sep 17 '15 at 20:05

setmask was a command available in UNOS (since 1980).

Since a longer time, the umask command gives you similar features.

Call:

umask -S to get the inverted mask as a chmod like symbolic mode.

umask u=rwx,g=rx,o=rx to get the equivalent of uask 022.

So your wish has been implemented already.

Historically why is umask the way it is?

3 Answers3